Evgeny_CD, Архитектор (06.12.2009 13:30, просмотров: 136) ответил Cepгeй Бopщ на Вы бы для осознания, что такая тулза нереализуема, попытались написать анализатор точного потребного количества стека для любого МК. Если вам это удастся - мировое сообщество будет благодарно, может и Нобелевку выкатят. Задачи примерно одинаковые.
Урановые ломы в ртути - это хорошо. Но если серьезно, то противопоставление некорректно. Стек на имеет явного отражения в ЯВУ. Нет никаких явных команд для работы с ним. Так что по исходнику С стек подсчитать в натуре тяжело.
Также как и по ассемблерному листингу, но там причины другие.
API оси имеет четко оговоренные функции, макросы, тайпдефы, переменные и константы. Усе. И обращения к ним явные.
Конечно, средствами С каждый может организовать массив указателей на API, и обращться к нему только так. Это отловить сложно, главное, нафиг не нужно. Просто договариваемся, что такого не будет.
Каждой обращение к любой сущности ОСи в юзеровской программе - это макрос. Когда "OS-кодогенератор" анализирует код, она синтезирует исходник, оптимальный для юзания в данном случае, и хидер для раскрытия макросов под данный конкретный исходник.
Еще об извращениях. Массив указателей мы прибили. Но стаются условная компиляция и циклы.
Можно договориться, что сущности ОСи в выражениях условной компиляции не используются. Неприятно, но жить можно.
Теперь пусть кто-то в цикле решит создавать майл боксы и писать в них. На каждом обороте цикла работаем с неким своим подмножеством мейлбоксов.
Для упрощения можно признать, что все сущности ОСи статические. Созданные на этапе компиляции. Понимаю, что это самое спорное предположение.
Можно ввести псевдомакросы. Перед тем как юзать некое подмножество мейлбоксов, мы задаем ОСи - роди нам столько-то сущностей таких-то типов. Можно еще для удобства им ввести имена, которые будут использованы в пемеменных. Т.е. не просто mbox[1], а mbox_GSM_Status и т.д.
Для "автоматического обращения" к сущностям ОСи создаем структуру. Состоящую, как минимум, из именованной сущности ОСи. Тогда при обращениях класса mbox[i] все будет корректно, но, с другой стороны, накладные расходы могут и вырасти. Ибо ели mbox - это просто массив, то обращение к i элементу - это прибавление к базе i*sizeof(), а в варианте массива структур - загрузка адреса элемента структуры.
Итого, никаких фундаментальных препятствий на пути подхода "OS как кодогенератор" я не вижу, хотя, разуммется, все просто там тоже не будет.
P.S. Перечитал свой собственный пост - опять С++ изобретаю!!!