C для AVR -- пишем аккуратно.
Добавлено: Пт авг 24, 2012 13:35:36
Выделено из темы про ассемблер AVR. Начало тут.
Цитаты оттуда:
Ну вот и глянул.
Табличка результатов на разных версиях avr-gcc.
orig -- код по ссылке
patch -- то, что я с ним сделал.
Ключи компиляции везде одинаковые, взяты из стандартного проекта. Для 4.7.1 ещё добавлялся ключ -fno-ivopts, чтобы он менше чудил с оптимизацией induction variables в циклах. Они там что-то в «корневом» gcc похимичили, для процессоров с развитыми адресациями точно стало лучше, для AVR компилятор иногда слишком «мудрит» и сам себя перехитрить умудряется.
«MobileChessBoard» -- это такие сборки свежего avr-gcc для Windows.
Т.е. проигрыш у ассемблера уже не два, а полтора раза (675 / 450)
Но сейчас я не о том, насколько проигрывает C ассемблеру на проектах такого размера, а о том, что можно сделать с нормальным в принципе С-шным кодом для уменьшения размера прошивки байт так с 870-ти до байт так 670-ти (больше, чем на четверть).
Причём смотрел «обще-микроконтроллерно-С-шные» вещи, там осталась одна большая беда именно avr-gcc, IAR должен бы ещё короче сделать на несколько десятков байт, но мне лень проверять.
Пришиваю новый исходник, надеюсь, оно будет работать
Немного позже (сейчас гости пришли) напишу немного по принципы — «общие» и что там осталось специфического для avr-gcc
Цитаты оттуда:
shads писал(а):Сообразил тут декодер радиоканала на тиньке 13-й, в двух вариантах, на С и на асме, так вот мож кому интересно будет узнать, разница в весе кода - больше чем в 2 раза, на С - 870 байт, а на асме тоже самое - 420 байт.....
Помоему асма остается актуальной для таких мелкашек как tiny13
http://asis-kbr.ru/forum/viewtopic.php?f=9&t=122
avreal писал(а):Я даже больше скажу -- если написать на асме программу размером байт десять, то С-шный вариант проиграет раз в пять-восемь, так как С (по крайней мере WinAVR) и всю таблицу прерываний заполняет переходом на ловушку необработанных прерываний, и прочие «общеподготовительные» вещи могут место занять. Т.е. у С-шной программы даже без желания автора обычно несколько другой функционал.
...
Увидел всё по линку, гляну по свободе. На носу куча выходных
Ну вот и глянул.
Табличка результатов на разных версиях avr-gcc.
orig -- код по ссылке
patch -- то, что я с ним сделал.
Ключи компиляции везде одинаковые, взяты из стандартного проекта. Для 4.7.1 ещё добавлялся ключ -fno-ivopts, чтобы он менше чудил с оптимизацией induction variables в циклах. Они там что-то в «корневом» gcc похимичили, для процессоров с развитыми адресациями точно стало лучше, для AVR компилятор иногда слишком «мудрит» и сам себя перехитрить умудряется.
Код: Выделить всё
version orig patch avr-gcc build
3.4.6 884 702 WinAVR-20060421
4.2.2 874 678 WinAVR-20071221
4.3.3 872 658 WinAVR-20100110
4.7.1 844 674 MobileChessBoard 4.7.1rc1 (-fno-ivopts -> 668)
4.3.4 894 680 Ubuntu-10.04
4.5.3 860 660 Ubuntu-12.04
Т.е. проигрыш у ассемблера уже не два, а полтора раза (675 / 450)
Но сейчас я не о том, насколько проигрывает C ассемблеру на проектах такого размера, а о том, что можно сделать с нормальным в принципе С-шным кодом для уменьшения размера прошивки байт так с 870-ти до байт так 670-ти (больше, чем на четверть).
Причём смотрел «обще-микроконтроллерно-С-шные» вещи, там осталась одна большая беда именно avr-gcc, IAR должен бы ещё короче сделать на несколько десятков байт, но мне лень проверять.
Пришиваю новый исходник, надеюсь, оно будет работать
Немного позже (сейчас гости пришли) напишу немного по принципы — «общие» и что там осталось специфического для avr-gcc
