Перечитайте основы, начать лучше всего с K&R.

Ну а если повторное самообразование не поможет, то ждем от Вас
скомпилированных примеров по таким исходникам:



Хотелось бы от Вас услышать в каком варианте массив будет заполнен правильно...

В обоих неправильно Значение i не определено в обоих случаях, содержимое массивов будет одинаково-случайным. Ошибка проявится, если после заполнения массива вызвать какую-либо функцию. В этом случае при (naked) содержимое массива (и i) будет испорчено стеком вызванной функции.

Я надеюсь что Вы таки пошутили насчет неопределенности i
(оно там от 0 до 9 считается)
ну и это всего лишь был минимальный пример приведен, без копирования в память с постоянным
адресом...

Посыпаю голову окурками. Действительно, глаз замылился. Уже привык в плюсах объявлять переменную прямо в цикле. Тогда оба примера будут работать одинаково, ибо указатель стека проинициализирован, и нет ничего, что могло бы содержимое массива испортить. Но первый же вызов функции порушит все.
P.S. Я просто на это уже нарывался - тоже в погоне за кодом сделал main() naked и потом разбирался, почему же все перестало работать.


Для aesok: Наткнулся на такую особенность: если в программе активно используются inline - функции, некоторые из них не встраиваются, даже если просто содержат вызов другой функции (т.е. при встраивании должны соптимизироваться совсем). Добавив -Winline получаю сообщение, что достигнут лимит --param max-inline-insns-single. В документации на gcc сказано, что по умолчанию этот параметр устанавливается в 300 (600/2) "морковок" (неких внутренних единиц измерения). Установка его через командную строку равным хотя бы 30 приводит к встраиванию всех inline функций в моем проекте. Какое же значение этот параметр имеет по умолчанию в действительности? Понимаю, что вопрос скорее не к вам, ибо аналогичное поведение демонстрирует и arm-elf-gcc, но поскольку вы более глубоко "погружены" в это, может подскажете - это я что-то неправильно понял или ошибка в документации?

Хотелось бы получать от Вас хотя бы немного проверенный код.
avr-gcc 4.2.2 ( WinAVR 20071221) Ваш цикл массив и пролог полностью выкидываетА вообще-то, если бы мне захотелось объявить массив в main я сделал бы его static, пролог в этом случае не нужен. По прежнему жду аргументов в пользу локальных (не static) переменных в main (не в блоке).
А вооще-то если бы мне запонадобилось заполнить Ваш массив, я бы написалВ случае 4.2.2 naked (как и OS_main)не обязательно, компилер выкидывает пролог самостоятельно.

Не, не одинаково.
Правда я до сих пор пользуюсь 20060421.
Код с naked:

Код без naked:

на входе main r29:r28 содержит адрес стека.
Как видно из рисунка, код одинаков за исключением того, что в коде с
naked забыли отвести память под массив на стеке.
В результате код с naked будет пытаться заполнять несуществующую память.

Он проверен на 20060421.
На 20071221 добавьте какую-нить глобальную volatile переменную
volatile unsigned char a;
и перед while(1) напишите a=arr[5];

Вам уже сказали что static это глобальный массив с ограниченной видимостью.
А если Вам будет нужен временный массив для рассчетов, вы его тоже static объявите ?
Наверное в Ваших микроконтроллерах очень много лишней памяти...

Ну, объявление автоматических локальных переменных в любой функции - наиболее естественное действие. Это дает свободу компилятору размещать их в удобном для него месте - на стеке или в регистрах. Хотелось бы услышать от вас аргументы в пользу объявления локальных переменных статическими именно в main(). Основное отличие статических переменных от автоматических - сохранение их значения между вызовами функций. Но main() вызывается лишь однажды, поэтому сохранение значения _между_ вызовами теряет смысл. Так в чем же смысл делать локальные переменные main() статическими?


Какая оптимизация используется? Выкидывание кода вполне справедливо. А вы попробуйте в конце цикла суммировать элементы массива и заносить результат в глобальную переменную. И включите какое-нибудь прерывание, например от таймера. Тут-то уж точно глюк будет воспроизведен 100%.

Я не разбирался с inline подробно.

Анатолий.

Мы обсуждаем здесь конкретную версию 20071221 и её фишки и глюки, а не основы C.Вообще-то что-то подобное Вам стоило добавить в свой код.Так это мне и без того известно.Нет, но и прямо в main не стану.

Вот и я про то же, и те и другие используются одинаково.В 3.4.6 - избавится от не нужного пролога. Ну и вооще как правило приходится писать эфективный, а не наглядный код, не гигагерцный пень же.

-Os
Дык в 20060421 оно и так с naked глючит т.к. массив в такой ситуации в нем не выкидывается.



Атлична, вот Вам код написанный по Вашим правилам:
Массив вынес в глобальные и сделал volatile, т.к. он будет использоваться в прерывании...
Откомпилируйте его на 20071221 с опцией -Os и расскажите какой будет результат в
переменной "a" когда дойдем до бесконечного цикла.

Вы вместо 20060421 версию скажите - ('avr-gcc -v'), похоже у Вас вооще трёшка.

это 3.4.6
Жду результата проверки последнего примера на 2007...

Ааа, переменные не влазят. Однозначно признак плохого дизайна. В данном случае легко обходится простой перестановкой строкНо, да готов согласится - еще одна ситуация, где naked не допустим, кроме локальных переменных.

Вот минимальный нерабочий пример:

Перременая 'i' объявлена с модификатором "volatile", для того чтобы запретить оптимизатору разместить ее в регистах.

Вот код который генерируеться для этой функции:

Здесь происходит обращение к памяти по адресам [Y+1..Y+2] (это переменная 'i'), но регистр Y не инициализирован! Регистр Y это frame-pointer (указатель локального фрейма) , или указатель на область памяти где расположены локальные переменные. Выкинув пролог функции, вы выкинули и инициализацию frame-pointer-а.

Еще раз!!! если в вашей функции 'main', для нее задан атрибут 'naked' и в ней есть локальные переменные то она будет работать только в том случае, если оптимизатор разместит все эти перемене в регистрах, и не будет использовать для их хранения локальный фрейм. Деже если сегодня ваша функция 'main' сейчас работает, вы можете гарантировать соблюдения этих условий при развитии проекта и внесении изменений в 'main'? НЕТ!!!

Вы предлагаете объявлять все переменные в 'main' как static, но это тоже не дает вам 100% гарантий. Компилятор может сам создать локальные переменные для личных нужд.


Анатолий.

Ничего подобного я не предлагаю.
Я говорю о реальной практике, а не теоретических примерах. Переменная volatile может понадобится, чтобы в нее писали обработчики прерываний и т.п. Стало быть однозначно - глобальная. Мне трудно представить _реальную_ иную ситуацию.И что помешает мне поставить // ? Я говорю только, что naked - хорошая практика. На выше перечисленные ситуации не разу не натыкался - если завожу переменную в main, т.е. всё равно всегда существующую, хоть и локальную (теоретически) - static. Переполнять регистры и потом гонять данные в стек и обратно тоже никакого желания, про volatile уже сказал. Так что и дальше буду использовать naked.