От какого счастья Вы собрались освободить программиста таким способом?

Условия проверяться не будут, т.к кол-во комбинаций=n! очень велико уже при n=10, где n-кол-во условных операторов. Просто будет собираться статистика вызовов каждой функции, анализироваться есть ли вложенные функции.? По поводу циклов не понял, уточните, а лучше пример в коде. На счет железа, это если что то из порта приходит? В любом случае условия не проверяются см. выше.




Освободить от "счастья" самому руками задавать стек путем написания скрипта, результаты работы которого передавать в проект до компиляции.
P.S на связь выду только в Пндк.

Прошу прощения за молчание - я в отпуске, сюда заглядываю редко...
Можно смотреть сгенерированный компилятором ассемблерный текст, находить все манипуляции со стеком и считать. А потом пересчитывать при каждой модификации исходника... Муторно очень. Я такой "подвиг" совершаю только для коротеньких фрагментов (типа обработчика прерывания), изначально целиком написанных на ассемблере...
Есть,например, такой метод: изначально весь стек заполняется какой-то константой, затем процесс запускается на выполнение (в симуляторе или живом устройстве), причем по возможности стараются прогнать выполнение по всем возможным веткам программы. После прогона смотрят, какая часть области стека осталась заполнена константой, а какая была использована (переписана). По результатам такого измерения корректируется размер выделенной под стек области памяти (с некоторым запасом).

В терминах C99 есть понятия "объявление" (declaration), для функций также называемое прототипом, и "определение" (definition), где содержится собственно код тела функции. Прототип malloc находится в <stdlib.h>, а где находится ее определение, зависит от используемой Вами библиотеки.

Так для этого надо считать не указатели, а операции со стеком.

постом выше, рассказали как определить размер стека и почему этого не надо делать при каждой компиляции. А на этапе отладки всегда можно посмотреть вершину стека и определить похерил ее кто-нибудь или нет.

Пример конечно гипотетический, но

С одной стороны, если функция вызывается и возвращается обратно, то стек она освободит (допустим мы заведомо знаем сколько стека она отожрет), но в данном примере число вызовов malloc() и соответсвенно количество требуемой памяти будет определяться временем сохранения истинных условий, естественно количество вызовов может варьировться от 0 до MAX/2 раз.
Определить хватит ли памяти можно только прогоном программы иначе никак. Сомневаюсь что Ваш анализатор справится с задачей "просто заглянув исходник". Конечно данный пример не показывает как можно "перелезть" через вершину стека, однако я думаю что он показателен в смысле того что нельзя заранее определить сколько памяти требуется.
Можно также упомянуть вложенные прерывания (хотя перед использованием этого приема нужно крепко подумать), оценить частоту и количество вызовов, а также уровень вложенности, которых по C исходнику с помощью машины тоже вряд-ли реально.
Наконец стоит вспомнить о рекурсивных функциях - какая глубина рекурсии потребуется можно сказать только при полностью известных исходных данных, т. е. в том случае когда собственно программа обрабатывает заранее известную информацию, и результат ее (программы) работы в принципе тоже известен.
Например

Конечно приведенные примеры сильно утрированы, но они простые, а в реальности могут быть на порядки сложнее, поэтому в общем случае мое мнение таково - ни один анализатор не сможет оценить реальные потребности в памяти по C исходникам при сколько-либо сложной задаче (т. е. в том случае где это нужно).

То есть просто в рукопашную, один на один с исходником?



Вот именно этот процесс (прогон по всем веткам) я и хочу автоматизировать, и уже есть соображения как. В любом случае это бутет консоль (на Visual Studio 6.0) вызываемая из makefile которой будет передоваться в командной стролке имя и путь к файлу *.lss. Попутный вопрос, как в makefile считать код возврата компилятора дабы не вызывать лишний раз консоль, да и файла тогда еще нет?


Конечно, подсчет указателей нужен для определеня размера структуры в менеджере памяти. Это делается еще до компиляции, а для стека нужно учитывать след. команды: push, st,std,call... в *.lss. Можно правда избавиться от лишней компиляции (надо же получить *.lss) если анализировать файлы *.c & *.h, но огда придеться считаться с гораздо сложным синтаксисом.

Сообщение отредактировал antiwin - Jul 21 2009, 10:10

Можно, конечно, построить дерево вызова процедур. Но возникают вопросы:
- как будете учитывать рекурсивные вызовы?
- вызовы прерываний, особенно если у них разные приоритеты?

Что значит "считать"? make и так проверяет код возврата каждой выполняемой команды на равенство нулю дабы прекратить выполнение в случае ошибки. Если в зависимости от кода возврата компилятора требуется выполнить какое-то ветвление, делайте это срадствами шелла, а не make'а.

Да, именно это. Просто я в шелле пока не очень, не могли бы прислать примерчик?

Например вот так:

Конечно, приведенные примеры поставят в тупик анализатор, но если он истпользует уже скомпилированный файл
т.е асмовый текст. При использовании исходников подобные проблемы я думаю решаемы. Конечно, и в этом случае алгоритм анализа получится довольно сложным, а в более общих случаях достаточно приблизительным, помимо этого придется анализировать все include и определенные даные . По большому счету это уже компилятор (препроцессор). Но все же... От использования исходных файлов останавливает то, что не у всех функций можно получить описание, таких как: malloc, sin random ( т.е встроенных-библиотечных)....Я эту тему чуть выше поднимал, но честно пока так и не разобрался где лежит их описание.
P.S Буду очень благодарен за внесение ястности в этот вопрос.

Сообщение отредактировал antiwin - Jul 23 2009, 08:34

http://ftp.twaren.net/Unix/NonGNU/avr-libc/

PS: Учитесь пользоваться гуглем, это очень пригодиться Вам в жизни.

Анатолий.

Не вижу разници между асмовым текстом и сишным, ибо количество вызовов ни по одному ни по другому в тех примерах не определить, дальше обсуждать это бессмысленно.
Просто мне кажется, что написание того анализатора что Вы задумываете - гораздо более сложная задача, чем написание хорошего программного эмулятора (симулятора). Если решать ее в общем случае (например для семейства процессоров), то ресурсов (имеются ввиду "человеко-часы") уйдет очень много. С другой стороны решение этой задачи в частном случае - оценка потребляемого конкретным кодом стека, тоже потребует приличного времени, при том что в частном случае она может быть решена предлагаемыми в теме способами с меньшими потерями "человеко-часов".

Разница огромна, работать с асмовым текстом все равно что глядя на кучу кирпичей гадать что это было, в случае с исходниками ситуация более ясная. Так как "глядя" на синтаксис можно очень многое узнать о текущей операции и даже если нет конкретных данных (приходят из порта), все равно можно хотя бы узнать минимальное и максимальное значение переменной, анализируя формат данных (char, int, long int...) и тип арифметической или логической операции.

Анализируя С код вы ни когда не узнаете размер frame-буфура и сколько call-used регистров будут сохранено в стеке. Точнее узеаете , но только в одном случае когда Ваш скрипт будет работать точно также как компилятор.

Размер стека использованого библиотечными функциями, можно только проанализировав дизассемблированный код.

Анатоллий.