soficer

На сколько я понимаю, frame-буфер это и есть стек для функции где хранятся все переменные и прочие данные. Почему же в таком случае анализируя С код нельзя определить эту величину(может стек формируется иначе чем я думаю)? Конечно такие сложности как рекурсия и не определенные данные я пока опускаю, хотя и в этом случае ,как мне кажется, есть решение. Как я понял все эти библиотеки устанавливаются nix-овым образом, как же их под маздай(WinAvr) установить? За ранее извиняюсь за возможно детский вопрос, просто всегда довольствовался тем, что качал с WinAvr. B)

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

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

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

То есть просто в рукопашную, один на один с исходником? Вот именно этот процесс (прогон по всем веткам) я и хочу автоматизировать, и уже есть соображения как. В любом случае это бутет консоль (на Visual Studio 6.0) вызываемая из makefile которой будет передоваться в командной стролке имя и путь к файлу *.lss. Попутный вопрос, как в makefile считать код возврата компилятора дабы не вызывать лишний раз консоль, да и файла тогда еще нет? :smile3046: Конечно, подсчет указателей нужен для определеня размера структуры в менеджере памяти. Это делается еще до компиляции, а для стека нужно учитывать след. команды: push, st,std,call... в *.lss. Можно правда избавиться от лишней компиляции (надо же получить *.lss) если анализировать файлы *.c & *.h, но огда придеться считаться с гораздо сложным синтаксисом.

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

Не во время компиляции, а как бы перед ней, т.е скриптом (или иначе) анализируется каждый файл (*.с) проекта где и подсчитывается сколько раз вызывается функция. Потом это число записывается в файл и далее идет сама компиляция. Просто весь процесс я обозвал компиляцией. Под описанием я имел ввиду не описание в человеческом смысле, а в рамках С99, т.е тело функции. А в предложенных ссылках (за них спасибо) описанние именно в первом смысле. Смысл задуманного как раз в том чтобы освободить программиста от такого "счастья".

Кол-во указателей (размер массива) определяется на этапе компиляции, путем подсчета вызовов определенной функции, отвечающей за выделение памяти. А почему бы это не делать в функции? Ведь так гораздо проще контролировать для чего выделяется память. Но даже если придется, то просто в дело вступает еще один указатель указываеющий на "исходный" а тот-на массив (его начало). Поправте, если ошибаюсь. Гуглился битый час, может не тот гугль, но так или иначе отсылает к avr-libc. А там ничего. Дайте нужную ссылку пожалуйста.

Просто, в ячейку указателя записывается новый адрес и все. Адрес самого указателя то не меняется. Что бы видеть все указатели, в менеджере предусмотрена специальная структура в которой каждому указателю(его адресу) соответствует адрес блока данных. Эта вынужденая мера, так как при работе с указателем его значение меняется, а в этой структуре он постоянен. Когда же приходит время удалить блок начало этого бока берется в структуре. Ну тут ничего не сделаешь, как и в любом компиляторе рано или поздно приходиться самому контролировать. К тому же не вижу практического смысла таких действий, потенциальный источник ошибок. К стати, пытался найти описание malloc и других встроенных функций, но кроме определения не нашел. Где же они все таки описанны.?

Да в общем случае ненадо, можно ли найти данные(в файлах lst, map...) или где еще позволяющие расчитать вершину стека.? Вобщем все просто, хочется написать альтернативу malloc ибо представляется она мне очень "глупой", ну не видит она где heap, а где stack. Кроме простого выделения памяти хочеться организовать минимальный менеджер памяти, способный дефрагментировать память. Конечно, об универсальном проекте речь не идет, но хотябы для "mega" с ОЗУ>500 байт. :) В том и проблема, так как можно char* foo(), и int* foo(), и uin32_t* foo(), т.е заранее неизвестно какой тип указателя нужен.

жаль Ну я так подозреваю выход есть в написании скрипта, анализирующий синтаксис всех сишников. Но это уже делает компилятор, неужели никак нельзя.

Привет всем, такой вот проблем: как можно узнать адрес в ОЗУ выше которого стек не "перерастет"? Это нужно сделать на этапе компиляции. И еще, можно ли в теле функции узнать тип возвращаемого значения т.е допустим определена функция void *foo(...), далее где то вызывается int *ptr=foo(...), как в теле foo узнать что это указатель на int?

Привет всем, такой вот проблем: как можно узнать адрес в ОЗУ выше которого стек не "перерастет"? Это нужно сделать на этапе компиляции. И еще, можно ли в теле функции узнать тип возвращаемого значения т.е допустим определена функция void *foo(...), далее где то вызывается int *ptr=foo(...), как в теле foo узнать что это указатель на int?

Я правильно понал, об'явление уникального символа предохраняет от повторной компиляции? А вроде бы у препроцессора есть функции на этот счет? Значит, что то вроде таблицы все та ки есть... За ссылку спасибо, как почитаю отпишусь немного отвлеченный вопрос. AT (ADDR (.text) + SIZEOF (.text)) SIZEOF вроде понятно-это размер секции, тогда ADDR-это начало? и что это за оператор AT?. И еще, в WinAvr есть папка с man, как вот эти man прочесть? Я думаю, что масса вопросов сразу бы отпала.

То есть, компилятор у себя в "уме" держит некую таблицу в которой, допустим, строке _FOO_CALL_COUNT_H соответствует include <FOO_CALL_COUNT.H>? Т.е запуск скрипта с помощью команды sh (скрипт)? Хотел бы уточнить выражение (объявлен ли _FOO_CALL_COUNT_H), если следовать синтаксису С, то это запись (_FOO_CALL_COUNT_H FOO_CALL_COUNT.H ) или нет? Мне хотелось бы понять сам механизм. :)