Народ, такая проблема. Необходимо при компиляции определить сколько раз вызывается функция (foo), а так же передать переменную из препроцессора(скрипта) в код программы.

Ну а дальше, делаете foo_call_count.h зависимым от всех с-файлов и генерируете его при помощи этого скрипта.

UPD. Улучшенная версия с предварительной обработкой препроцессором (препроцессор убирает комментарии).

Спасибо за совет, будем посмотреть

Не совсем понятно как формируется выражение
CURR=`cpp -E ${FILE} | grep -vv "^#" | grep "foo(" | grep -vv -c "void foo("`
Как я понял, последние два оператора проверяют синтаксис на наличие foo, но вот что делают первые два?

Первый обрабатывает препроцессором файл, второй отбрасывает служебную инфу препроцессора (может не надо), 3 - выделяет все упоминания функции, 4 - исключает прототипы функции и подсчитывает оставшиеся.
Строчку "echo -e "${FILE}\t:${CURR}\t:${COUNT}"" можно удалить (исключительно для отладочных целей), ещё желательно натравливать препроцессор на файл с полным комплектом ключей компиляции.

Спасибо, прояснилось. Как я понимаю этот скрипт надо вписать в makefile?. И еще, давно хотел спросить, запись типа #define _FOO_CALL_COUNT_H определяет файл FOO_CALL_COUNT.H, но как препроцессор знает что перед H надо ставить точку. Почему просто не написать #include <FOO_CALL_COUNT.H>

p.s отвечаю не сразу. т.к дома нет инета.

Препроцессор ничего не знает и не ставит. Определяется символ _FOO_CALL_COUNT_H и дальше идет проверка именно этого символа. Это программист сам для себя решает, что _FOO_CALL_COUNT_H относится к файлу foo_call_count.h. Кстати, имена, начинающиеся с подчеркивания зарезервированы за компилятором и стандартной библиотекой, во избежание неприятностей свои имена с подчеркивания лучше не начинать.

Скрипт лучше поместить в отдельный sh-файл и запускать при необходимости (из мейкфайла) (не уверен но может и из makefile-а работать).
Разберем конструкцию по строчкам:
1. #ifndef _FOO_CALL_COUNT_H
проверяем не объявлен ли _FOO_CALL_COUNT_H, если не объявлен - п.2. Если обьявлен - значит этот заголовочный файл включен не в первый раз и значит его содержимое можно не обрабатывать.
2. #define _FOO_CALL_COUNT_H
Это является стандартным обрамлением для заголовочных файлов.
Спасибо за замечание, учту.

То есть, компилятор у себя в "уме" держит некую таблицу в которой, допустим, строке _FOO_CALL_COUNT_H соответствует include <FOO_CALL_COUNT.H>?


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

Нет никакой таблицы. Нет никакого соответствия. вот смотрите:
Что происходит при компиляции abc.c?
1)удаляются все комментарии.
2)весь текст foo.h вставляется в те места, где был #include "foo.h". Все, #include исчезли, на их месте появился текст.
3) Теперь препроцессор проходит весь файл от начала до конца. В месте, где файл foo.h вставлен первый раз, он встречает строку #ifndef FOO_H_INCLUDED__.
4)Он ищет в своих списках символ FOO_H_INCLUDED__ и не находит его. Символ не определен. Условие выполнилось, препроцессор просматривает текст внутри условия.
5) тут он встречает строку #define FOO_H_INCLUDED__. Он вносит такой символ в свои списки - все, символ определен.
6) он просматривает файл дальше и доходит до места, где был второй #include "foo.h". Тут он снова встречает строку #ifndef FOO_H_INCLUDED__.
7) Он снова смотрит в своих списках и теперь уже находит там символ FOO_H_INCLUDED__. Условие не выполнилось, препроцессор выкидывает весь текст до #endif .

Все, содержимое foo.h попало компилятору только один раз. Как мы обозвали этот символ - FOO_H_INCLUDED__ или FOO_H_ или SKIP_THIS_FILE или TIPA_TEST - препроцессору все равно. Это наша забота, чтобы в каждом заголовочном файле был определен уникальный символ. И проще всего это сделать, связав имя символа с именем файла.

Чтобы понять смысл выражения "определен символ" - лучше всего прочитать документацию на препроцессор (не компилятор, а именно препроцессор - до компилятора эти символы не доходят).

Я правильно понал, об'явление уникального символа предохраняет от повторной компиляции?
А вроде бы у препроцессора есть функции на этот счет?


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

Есть, но они не стандартизованы (насколько я помню) и обладают рядом недостатков. Вот на этом форуме второй ответ описывает их. А обертка из #ifndef #define #endif работает везде. Вот неплохое описаниеКак это устроено внутри - не знаю, да это и не принципиально. Важно, что никаких таблиц соответствия имени символа и имени файла нет.Дежа-вю

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

В общем случае это невозможно.
Что "это"? foo выполняется до присваивания, поэтому во время ее выполнения ptr еще не существует. Функция "знает" только то, что передается ей в качестве аргументов. Что потом произойдет с возвращаемым ей значением, она знать не может.
А позвольте полюбопытствовать, для чего нужно "знать" внутри функции, какому объекту будет потом присваиваться возвращаемое ей значение? Такое желание мне кажется довольно странным, и наводит на мысль, что на самом деле задача состоит в другом - обеспечении более строгой типизации. На C++ это решается множеством различных способов - например, вместо типа void* функция может возвращать экземпляр класса, содержащего методы преобразования указателя к нужному типу - но это никак не будет влиять на код функции. Или инстанцированием функции из шаблона - тут код функции будет сразу генериться с учетом нужного типа, но тип придется при каждом вызове указывать явно...

А для чего это надо?
И если уж работаете с указателями, то почему бы просто не выполнить явное преобразование типа

Да в общем случае ненадо, можно ли найти данные(в файлах lst, map...) или где еще позволяющие расчитать вершину стека.?



Вобщем все просто, хочется написать альтернативу malloc ибо представляется она мне очень "глупой", ну не видит она где heap, а где stack. Кроме простого выделения памяти хочеться организовать минимальный менеджер памяти, способный дефрагментировать память. Конечно, об универсальном проекте речь не идет, но хотябы для "mega" с ОЗУ>500 байт.



В том и проблема, так как можно char* foo(), и int* foo(), и uin32_t* foo(), т.е заранее неизвестно какой тип указателя нужен.

 

Так делайте явное преобразование типа по месту, как это сделано в malloc

Интересно, как вы собираетесь это реализовать? Выделил ваш менеджер участок с адреса, скажем, 110. Вернул указатель. Вы его запомнили. Потом он в процессе дефрагментации переместил этот участок на адрес, скажем, 100. Как он сообщит вашей программе, что старый указатель больше не действителен? А если вы его уже успели скопировать в три других указателя?

Наверное речь идёт о дефрагментации свободных участков. По крайней мере, я не слышал о менеджерах памяти, дефрагментирующих выделенные блоки.

Ну, если память состоит только их занятых и свободных блоков, то дефрагментация одних эквивалентна дефрагментации других. Или там ещё бывают участки в "третьем" состоянии? Просветите, я не в курсе

НЕТ.
Для хранения всех локальных переменных (переменных объявленных внутри функций) используется стек. Для дефрагментации занятых блоков все указатели (абсолютно все) должны быть видны вашему менеджеру памяти. См. пост №20.

Дефрагментация свободных блоков - это уже другая задача. На свободные участки указатели уже не хранят значения, а если такое и случается это уже ошибка программиста.
Менеджер памяти хранит списки свободных и занятых блоков и после некоторого количества операций по выделению/освобождению памяти получается, что два и более последовательных блока свободны и их можно объединить в один большой свободный блок. Это и есть дефрагментация свободной памяти.

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

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



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


К стати, пытался найти описание malloc и других встроенных функций, но кроме определения не нашел.
Где же они все таки описанны.?

А какой размер этого масива? Три? Десять? Сто? А.... Вы озадачите нас вопросом: Как во время компиляции узнать количество используемых указателей в работуещей программе?!


Вы никогда не слашали про такую вещь как Двусвязный список?



Не сочтите за рекламу: www.google.com

Анатолий.

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

Кол-во указателей (размер массива) определяется на этапе компиляции, путем подсчета вызовов определенной функции, отвечающей за выделение памяти.


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


Гуглился битый час, может не тот гугль, но так или иначе отсылает к avr-libc. А там ничего.
Дайте нужную ссылку пожалуйста.

объясните мне: как во время компиляции можно узнать сколько раз будет вызвана функция во время работы программы?



http://ru.wikipedia.org/wiki/Malloc
http://www.nongnu.org/avr-libc/user-manual...678e5251dfd3ebd
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf - начиная со стриницы 313

Анатолий.

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




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



Смысл задуманного как раз в том чтобы освободить программиста от такого "счастья".

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

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

Условия проверяться не будут, т.к кол-во комбинаций=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, но огда придеться считаться с гораздо сложным синтаксисом.

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

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

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

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

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

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

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

Анатолий.

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

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

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

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

Анатоллий.

call-used call-saved

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


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

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