100 байт не хватает Опции

[Огурцов]

В общем, называется "приплыли", допрограммировались - бутлодырь перестал вмещаться в размер бутсекции, т.е. в 2k. Последним делом добавлено нечто такое:

Код

void Bus_transmit_packet(uint8 aStatus)
{
    uint16 vCrc;

    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_sysdev_program | Slp_response_mask);
//    vCrc = vxl_get_crc16(Vxl_crc_ccitt_initial_value, Slp_sysdev_program | Slp_response_mask);
    Bus_staff_n_transmit_byte(aStatus);
    vCrc = vxl_get_crc16(0x7976, aStatus);
    Bus_staff_n_transmit_byte(vCrc >> 8);
    Bus_staff_n_transmit_byte(vCrc & 0xFF);
    Bus_transmit_byte(Slp_packet_end);
}

Что занимает примерно 60 байт. Предварительное заполнение массива и передача массива хоть и напрашивалась явно, но почти ничего не изменила или даже хуже.
Однако, где бы наскрести еще сотню байт ? (таблица векторов еще не затронута, как и секции инициализации/финализации) Поделитесь, pls, примером оптимизации - сам я боюсь все порушить и грохнуть что-либо нужное.

M88, GCC(WinAVR-20060421), cкрипты линкера от WinAVR-20081205

Сообщение отредактировал Огурцов - Dec 25 2008, 20:26

[rezident]

Хоть и , но нелишне напомнить История одного байта.

[Огурцов]

Помню.
Фишка еще в том, что простое увеличение памяти ничего не дает и для более толстой m168 проблема еще более усугубляется - там для того же самого дополнительно нужно около 700 байт.

[ReAl]

Фишка еще в том, что простое увеличение памяти ничего не дает и для более толстой m168 проблема еще более усугубляется - там для того же самого дополнительно нужно около 700 байт.

А почему? Размер-то бут-секции меньше 8К и в пределах лоадера можно обходиться rcall-ами/rjmp-ами, в результате для меги168 вырастет только таблица векторов.

[SasaVitebsk]

Недавно в IAR выдушил 400 байт. Возможно мои рекомендации немного помогут.
1) Проверь какие регистры реально использует компилятор. Попробуй выключить несколько регистров и посмотри насколько увеличился объём кода.
2) посмотри какие процедуры используются тобой чаще всего. Обрати внимание как скомпилировал их компилятор. И вообще к этим процедурам необходимо пристальное внимание. Всё дальнейшее теперь по ним.
3) Посмотри какие параметры туда передаются и как они возвращаются. В частности по CRC. Попробуй объявить её глобальной на весь файл либо наоборот локальной в main, а в других местах передавать аргументом. Смотри как меняется объём файла.

Далее исходя из всех экспериментов я сделал следующее. (у вас может быть вплоть до наоборот)
1) выделил несколько регистров (у меня их резервирование практически не влияло на размер выходного файла)
2) Расположил там переменные, к которым максимально часто обращаюсь и объявил их глобальными расположенными в регистрах.
3) Переписал пару процедур на асме.

Учтите ещё три момента.
1) В кристалле м8 объём занимаемый будет меньше.
2) Кое что возможно расположить в свободном месте между веаторами прерываний. (насколько я понял вы прерывания задействовали).
3) Я пробовал вариант с прерываниями и без них. Без них объём проги получился значительно меньший.

[ReAl]

Тьху, у меги88 и 168 одинаковые размеры бут-секции.

1) выделил несколько регистров (у меня их резервирование практически не влияло на размер выходного файла)
2) Расположил там переменные, к которым максимально часто обращаюсь и объявил их глобальными расположенными в регистрах.

2а) В GPIOR0 можно разместить восемь битовых флагов с коротким доступом на установку/сброс/проверку.
2б) В GPIOR1, GPIOR2 можно разместить две байтовых переменных с доступом in/out, более коротким, чем lds/sts
2в) Гулять так гулять - в EEARL/EEDR а то и в неиспользуемых лоадером таймерных регистрах OCR0A/OCR0B/TCNT0 тоже можно что-то поскладывать.

[Огурцов]

А почему? Размер-то бут-секции меньше 8К и в пределах лоадера можно обходиться rcall-ами/rjmp-ами, в результате для меги168 вырастет только таблица векторов.

Да, таблица векторов вырастает (ровно?) в два раза. У m8 она чуть-чуть поменьше, но их вроде бы уже сняли с производства. Бут-секция 2k у всех троих, больше не сделать. Выносить часть лодыря в секцию приложения - как-то совсем не красиво.

[aesok]

Bus_transmit_byte и Bus_staff_n_transmit_byte это функции или макросы? Если функции то в зависимости от их размера добавте им атрибуты noinline или always_inline.

Код

    Bus_staff_n_transmit_byte(vCrc >> 8);
    Bus_staff_n_transmit_byte(vCrc & 0xFF);

avr-gcc генерирует плохой код для операций сдвига, используйте union-ны для выделения байтов из int и long.

Код

    union
    {
        uint16_t word;
        struct
        {
            uint8_t lo;
            uint8_t hi;
        } byte;
    } x;

    x.byte.lo = ...;
    x.byte.hi = ...;
    return x.word;

Анатолий.

[Огурцов]

2а) В GPIOR0 можно разместить восемь битовых флагов с коротким доступом на установку/сброс/проверку.
2б) В GPIOR1, GPIOR2 можно разместить две байтовых переменных с доступом in/out, более коротким, чем lds/sts
2в) Гулять так гулять - в EEARL/EEDR а то и в неиспользуемых лоадером таймерных регистрах OCR0A/OCR0B/TCNT0 тоже можно что-то поскладывать.

Вообще-то мысль интересная.
Сейчас нужны еще 18 байт плюс две фичи - проверка взведенных лок битов и проверку CRC бут-секции. Теоретически таблицы векторов для этого могло бы и хватить, т.к. прерывания принципиально не используются. Как ее отключить, оставив один или два вектора ? Это ресет, плюс точка входа из секции приложения.

[aesok]

Как ее отключить, оставив один или два вектора ? Это ресет, плюс точка входа из секции приложения.

Для этого нужно перекомпилировать под свой проект crtXXXX.o. Код стандартного здесь:
http://cvs.savannah.gnu.org/viewvc/avr-lib.../?root=avr-libc

Ботлоадер использует прерывания? Если нет то добавте ключик "-mno-interrupts". Таблицу векторов он не уберет но код немного сократить может.

Анатолий.

Сообщение отредактировал aesok - Dec 26 2008, 07:14

[Огурцов]

avr-gcc генерирует плохой код для операций сдвига, используйте union-ны для выделения байтов из int и long.

10x, -2 байта на каждую переменную.

[Огурцов]

Добавил фичи, теперь не хватает 98 байт. Почти угадал )

[_Pasha]

История одного байта.

Будете смеяться. Мне тоже когда-то для pic16f84 не хватило одного слова. Искал о-о-очень долго, но утоптал софт на одну команду.

и в пределах лоадера можно обходиться rcall-ами/rjmp-ами

Опция --relax в командной строке линкера ?

Добавил фичи, теперь не хватает 98 байт. Почти угадал )

1. В листинге можно найти много смешного, байт эдак на 100. В основном это jmp вместо rjmp, и интенсивное использование lds/sts.
2. Для бута ассемблер уже не модно ?

[zltigo]

Хоть и , но нелишне напомнить История одного байта.

Да не тот случай Тут наверняка просто нечто писанное левой ногой и на 2K нахождение 100 байт не требует сверхестественных потуг.

[Diz]

Посмотрите, есть ли у в строке для компилятора ключики
-ffunction-sections и -fdata-sections, а для линкера --gc-sections.
Если их нет, линкер не будет выбрасывать неиспользуемое.

[ReAl]

Опция --relax в командной строке линкера ?

Можно так (и в любом случае не вредно, так как оно сделает ещё и замену rcall/ret на rjmp), но можно и ключик -mshort-calls компилятору.

1. В листинге можно найти много смешного, байт эдак на 100. В основном это jmp вместо rjmp, ...

Ну это явные кандидаты на
-mshort-calls, чтобы сразу компилятор не ставил, а --relax линкеру полировку наведёт.

[Огурцов]

Да не тот случай

Совершенно согласен, тут проза жизни, а там какая-то сказка, и если отбросить кудрявые фантазии афтара, от сказки останется абсолютный ноль.

Тут наверняка просто нечто писанное левой ногой и на 2K нахождение 100 байт не требует сверхестественных потуг.

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

Ну это явные кандидаты на
-mshort-calls, чтобы сразу компилятор не ставил, а --relax линкеру полировку наведёт.

--relax не помогает, -mshort-calls выжимает 110 байт, но только для m168, для m88 без изменений.

Посмотрите, есть ли у в строке для компилятора ключики
-ffunction-sections и -fdata-sections, а для линкера --gc-sections.

Есть. На всякий случай

Код

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -std=gnu99 -DA40520101 -ffunction-sections -fdata-sections  -mshort-calls  -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -Wl,--verbose -Wl,--gc-sections  -Wl,--relax  -Wl,-Map=bootloader.map
LDFLAGS += -Wl,-section-start=.text=0x1800

[zltigo]

Ну зачем так голословно...

Ну не менее голословно, тем более с учетом некторых ранее изложенных на форуме взглядов на программирование, чем Ваше утверждение

...уже заоптимизировано реальным профи.

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

[singlskv]

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

+1
Да, автор, выкладывайте, в конце концов, бутлодырь не очень комерческая вещь..
А мы посмотрим - пооптимизируем...

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

[Огурцов]

Вообще, меня не уполномачивали публиковать исходники, так что для текущей версии (+98 байт) это исключено. Но если гарантированно найдутся желающие с этой версией посоревноваться, что делать, я наверно напрягусь и соберу изначальный вариант (кажется байт 500-700 плюсом). В этом случае вопросов с авторскими правами не возникнет.

Ну не менее голословно, [skipped] чем Ваше утверждение

уже заоптимизировано реальным профи.

Смиялсо. Значит вы готовы ?

постфактум указаниях компилятору в духе "ну сделай, хоть что-нибудь еще".

В общем, да. Но высказанные идеи, в определенном смысле, были полезны.

[zltigo]

Смиялсо.

И опять без всякой на то причины .

Значит вы готовы ?

Сегодня скоротать часок-другой и освежить AVR? На том, что Вы нагородили - да. На каком нибудь взятом из интернету нескольсотбайтовом загрузчике и заброшенном сюда - нет.

[Огурцов]

И опять без всякой на то причины .

Почему без ? Над тем, что вы в слепую, совершенно не зная расклада, называете одного уважаемого человека "левой ногой".

Сегодня? На том, что Вы нагородили - да. На каком нибудь взятом из интернету нескольсотбайтовом загрузчике и заброшенном сюда - нет.

Сегодня, завтра, в выходные. Можно до нового года. Можно и в праздники, если вам там нечем будет занятся. Последний вариант хоть и прикольный, но мне уже не очень интересен.
Исходники таки взяты из интернета, ужмете их до размера "левой ноги", после чего я добавлю "свою нагородили", а потом вы ужмете их еще раз. Размер не должен превышать 2k. Или хотя бы 2k+98 байт. GCC/WinAVR.

[zltigo]

Почему без ? Над тем, что вы в слепую, совершенно не зная расклада, называете одного уважаемого человека "левой ногой".

Ну так вываливайте СВОИ выпирающие за 2K исходники, посмотрю на какую степень моего уважения они могут претендовать.

Сегодня, завтра, в выходные. Можно до нового года.

Не можно. Завтра еду в Питер по делам.

Можно и в праздники, если вам там нечем будет занятся.

Мне будет и чем и с кем.

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

Не наводите тень на плетень сначала, потом, а потом, а после, если, только WinAVR... Либо смотрим то, о чем СЕЙЧАС идет речь, либо нет.

[Огурцов]

Либо смотрим то, о чем СЕЙЧАС идет речь, либо нет.

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

зы: WinAVR - это без вариантов. IAR не подходит по медико-этическим соображениям.

Сообщение отредактировал Огурцов - Dec 26 2008, 18:30

[zltigo]

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

Ну могли-бы и в 22 раза постфактум условие написать, однако вынужден напомнить, речь шла и идет о комплексном ужимании всего проекта с 2K+100 до 2K. И это тоже "однозначно".

[aesok]

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

Я не понимаю Ваш гонор. Как видно из названия темы, это Вы не можете оптимизировать свою программу. Если нужна помощь то показавайте свой проект. Если Вы сомневаетесь что мы можем Вам помочь, то зачем чтото от нас требуете?

Анатолий.

Сообщение отредактировал aesok - Dec 26 2008, 18:48

[singlskv]

Вообще, меня не уполномачивали публиковать исходники, так что для текущей версии (+98 байт) это исключено. Но если гарантированно найдутся желающие с этой версией посоревноваться, что делать, я наверно напрягусь и соберу изначальный вариант (кажется байт 500-700 плюсом). В этом случае вопросов с авторскими правами не возникнет.

Ну публикуйте уже....
А там посмотрим... думаю что без попыток оптимизации другими будет даже проще...
развлечемся под новый год...

[Огурцов]

http://www.atmel.com/dyn/resources/prod_documents/AVR231.zip


Я вот еще что подумал. Таблица векторов имеет опцию weak. Так может быть какой-нибудь подходящей по размеру функции задать определенный адрес, лежащий в области таблицы векторов, и последние, по идее, должны быть ей вытеснены. Может быть даже и предупреждения не будет. Как заставить gcc разместить функцию по определенному адресу ?

[zltigo]

http://www.atmel.com/dyn/resources/prod_documents/AVR231.zip

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

[Огурцов]

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

[zltigo]

Дада, сделайте из этого 1.5-1.7 килобайта, чтобы осталось байт триста для моих фич, и защитаем. Пока я вижу от вас только пустой треп, про разные ARM, в т.ч.

Треп это, простите, по вашей части. И не только в этой теме

Вообще, я вас за язык не тянул...

Разумеется нет, но мимо безответственного трепа я обычно стараюсь не проходить.
Теперь к делу, извините, пришлось отвлечься - встречал жену из Праги.
Весь этот бред писанный китайским студентом вычитывать не стал, а только AES.c поправил. Именно поправил явное, радикальной переделкой заниматься не стал, ибо только на этом сэкономил
172 байта, что поболе желаемых 100 будет. Бинарник 1732, что тоже уже меньше озвученных Вами 1,7 K
Все это при том, что я чувствую AVR хуже, чем ARM и вообще почти год для AVR вообще ничего не писал, посему ориентировался на просто 'C'.
Было:

Код

1 046 bytes in segment CODE
     6 bytes in segment INITTAB
    36 bytes in segment NEAR_F
   522 bytes in segment NEAR_Z

1 082 bytes of CODE memory (+ 6 bytes shared)
   522 bytes of DATA memory

Стало:

Код

874 bytes in segment CODE
   6 bytes in segment INITTAB
  36 bytes in segment NEAR_F
522 bytes in segment NEAR_Z

910 bytes of CODE memory (+ 6 bytes shared)
522 bytes of DATA memory

Листинги обеих AES.c и моего AES.zlt.c вариантов и бинарник в приложении. Вот так.

P.S.
Извиниться не хотите? Смешливый Вы наш....

Прикрепленные файлы

 aes.rar ( 7 килобайт ) Кол-во скачиваний: 67

 

[SasaVitebsk]

Спасибо. Поизучаем.

[zltigo]

Спасибо. Поизучаем.

Да в том и дело, что там нет ничего особенного, и 172байта сняты буквально мимоходом, если мне память не изменяет по оптимизации этого загрузчика пару лет назад на форуме была более обширная дискуссия c заточками и под конкретные AVR компиляторы. То что здесь это практически просто обратный порт с ARM c откатами на строго 8bit переменные.

[Огурцов]

Треп это, простите, по вашей части. И не только в этой теме

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

Именно поправил явное, радикальной переделкой заниматься не стал, ибо только на этом сэкономил
172 байта, что поболе желаемых 100 будет. Бинарник 1732, что тоже уже меньше озвученных Вами 1,7 K

Я правильно понял первую строку листинга: IAR Atmel AVR C/C++ Compile - это IAR ? Так вот IAR, если вы хоть чуть-чуть читали, ничуть не устраивает, и, кроме того, он вполне справляется и без ваших потуг. На GCC, если я еще не забыл, это же самое примерно 2.7k. Деразайте.

Извиниться не хотите? Смешливый Вы наш....

Будет решение - извинюсь. Пока от вас только флудотреп.

[GetSmart]

Огурцов, из чистого любопытства спрашиваю, почему IAR не "катит"?

ЗЫ. Помогать не собираюсь Просто задело за "живое".

[Огурцов]

Огурцов, из чистого любопытства спрашиваю, почему IAR не "катит"?

Здесь уже писал - стоит денег, т.е. в соотношении качество/цена проигрывает любому из фришных. Из фришных (чисто по чужим отзывам) считаю только GCC преемлемым вариантом. И неплохим даже.

Сообщение отредактировал Огурцов - Dec 27 2008, 06:46

[zltigo]

он вполне справляется и без ваших потуг. На GCC, если я еще не забыл, это же самое примерно 2.7k.

Как всегда врете и глупо изворачиваетесь. GCC, коему по Вашему утверждению, не хватало 100 байтов для Ваших фич теперь вдруг и без Ваших фич стало не хватать более 700.... Кто-то хотел сэкономить 100 байтов? Результат я дал. При этом, GCC столь-же благосклонно, как и IAR отнесется к очевидным изменениям - поминаемые 100 байт Вы получите и от GCC. Кроме того, поскольку , как я и предполагал, действительно все в этом образчике от Atmel писано левой ногой.Это вызвало с Вашей стороны только

.....уже заоптимизировано реальным профи
Смиялсо.

То, потратив еще минут 15-20 можно сбросить еще 5-10% и это только в aes.c и это будет не предел, а просто результат потраченых нескольких десятков минут.
В Вашей, как я теперь, совершенно определенно могу утверждать, писанине нужно править и соответственно экономить можно много больше.

P.S.

Спасибо. Поизучаем.

Сейчас прошелся еще разок, бегло, в рамках просто 'C' без IAR/AVR наворотов но теперь

Код

790 bytes in segment CODE
  12 bytes in segment INITTAB
  32 bytes in segment NEAR_F
  10 bytes in segment NEAR_I
  10 bytes in segment NEAR_ID
512 bytes in segment NEAR_Z

832 bytes of CODE memory (+ 12 bytes shared)
522 bytes of DATA memory

На 250 байт похудел почти килобайтовый aes дешифратор.

Прикрепленные файлы

 aes_lst.rar ( 6.9 килобайт ) Кол-во скачиваний: 43

 

[Petka]

Сейчас прошелся еще разок, бегло, в рамках просто 'C' без IAR/AVR наворотов но теперь

Здесь уже писал - стоит денег, т.е. в соотношении качество/цена проигрывает любому из фришных. Из фришных (чисто по чужим отзывам) считаю только GCC преемлемым вариантом. И неплохим даже.

Оффтоп: Насколько я понимаю у топикстартера проблеммы с IAR по лицензионным причинам.
Однако есть "KickStart edition of IAR Embedded Workbench". Который можно использовать абсолютно бесплатно (и разумеется лицензионно) для приложений размер кода которых меньше 4К. Сразу скажу что не являюсь пользователем продукции IAR. Однако если топикстартеру действительно важен результат, то и мой совет может пригодиться

[zltigo]

Оффтоп: Насколько я понимаю у топикстартера проблеммы с IAR по лицензионным причинам.

и при этом нет проблем с ворованными борландовскими дельфями... Да проблемы у топикстартера совсем в другом

Однако есть "KickStart edition of IAR Embedded Workbench". Который можно использовать абсолютно бесплатно (и разумеется лицензионно) для приложений размер кода которых меньше 4К.

Кстати, действительно да! Если, вдруг, реально удастся ужать хоть процент-другой за счет использования IAR. Хотя и GCC совсем не плох и надо специально постараться , дабы заставить его сгенерить код сильно худший, по утверждению Огурцова, чем IAR - 2,7K вместо 1,7K .

[Огурцов]

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

Да, это ценное замечание, 10x.


Извиняюсь, что ответил не сразу - сделал на круг четыреста километров - раздал зарплату сотрудникам. Сотрудники довольны - я доволен. Я доволен - сотрудники довольны. Вот такая вот ПОС.

и при этом нет проблем с ворованными борландовскими дельфями... Да проблемы у топикстартера совсем в другом

Приведите, чтоли, ссылку, где я говорил, что у меня установлена ворованная дельфи. У меня установлена лицензионная MS Windows XP, лицензионная MS Visual Studio и много фришного софта, в том числе WinAVR.

Как всегда врете и глупо изворачиваетесь.

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

GCC, коему по Вашему утверждению, не хватало 100 байтов для Ваших фич теперь вдруг и без Ваших фич стало не хватать более 700....

Обычно (обычные), люди понимают уже со второго раза. Если с третьего все еще непонятно, то у человека явно проблемы со здоровьем, объяснять ему дальше - пустая трата времени. Сделать исключение ? Ок, на пальцах. Оригинальный код в GCC - это где-то 2,7. Оптимизированный тем, кого вы обозвали "левой ногой" - это где-то 1,9 (это не означает, что он не смог бы ужать дальше, просто у него не было необходимости). Далее я еще ужал до где-то 1,7. После чего переписал некоторые места по-своему, убрав ненужное и добавив нужное. Получилось где-то 2,0. После этого переписал протокол обмена для возможности работы на общей шине и в пакетном режиме. Получилось 2,1. После этого задал вопрос.

Кроме того, поскольку , как я и предполагал, действительно все в этом образчике от Atmel писано левой ногой.

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

В Вашей, как я теперь, совершенно определенно могу утверждать, писанине нужно править и соответственно экономить можно много больше.

Давайте, давайте. Условия задачи озвучены - вперед.

На 250 байт похудел почти килобайтовый aes дешифратор.

О, давайте еще байт четыреста... и можно будет продолжать с вами разговор про GCC и левые ноги.


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

Сейчас отключена проверка CRC лодыря, и запись в EEPROM. Первое - хотелось бы, второе - на практике и не нужно совсем, так, лишь для распальцовки. Итоговый размер - ровно 2k.

[SasaVitebsk]

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



Давайте вспомним, что до Нового Года остался совсем пустяк и простим друг другу свои мелкие недостатки.

Я, к сожалению, совсем что-то не чувствую приближения праздника в этом году. Может виноват в этом Step 7. Скорей бы его в топку и назад к компилятору С.

[defunct]

Огурцов:

A. Нет смысла переходить на инструмент, когда сразу известно, что новый иструмент даст результат хуже чем старый. А WinAVR соптимизирует хуже чем IAR, это факт.

B. В комплекте с STK500 идет CD от Atmel где куча всего фришного, в т.ч. и IAR Kick-start. Объем вашей программы 2K, ограничение фришного IAR'а, как отметил Petka - 4K.

C. Считаю, что бутлоадер на "C" для секции в 2K - это извращение. Бутлоадер - это программа, которая не нуждается в модификации и сопровождении.. Она пишется 1 раз и используется для всех проектов. Вот и подумайте своей головой, может нафиг этот Си, (тем более вы как-то доказывали, что Си - отстой, а паскаль и asm рулит). Почему ж решили применить С для задачи для которой он дает результат хуже чем ASM? Напишите бутлоадер один раз на ASM, ужмите всё по самые "немогу" конкретно для AVR и радуйтесь. Будет бесплатно и влезет возможно и в 1K.

[Огурцов]

asm рулит

Если ближе к оригиналу, то хороший _макро_асм "рулит". Но похоже нет его. А то, что идет от атмел, даже на нормальный не тянет, не то что на хороший. Поэтому вынужденно перешел на си. И на GCC - осознанно. Потому как думаю, что рано или позно у меня и с линухом что-нибудь да получится.

[defunct]

Если ближе к оригиналу, то хороший _макро_асм "рулит". Но похоже нет его. А то, что идет от атмел, даже на нормальный не тянет, не то что на хороший. Поэтому вынужденно перешел на си. И на GCC - осознанно.

Что есть в _макро_асм чего нельзя сделать в AVR-ASM? И препроцессор в нем есть, и макросы поддерживаются. Чего нехватает-то?

У меня все толстые бутлоадеры (всмысле не по объему, а по функциональности) написаны на ASM.
В 2K секцию у меня влазит:
1. TCP стек.
2. Шифрование.
3. Modbus протокол (over TCP и over 485).
4. Проверка целостности основной программы.
5. Загрузка программы из I2C eeprom'a.

в 1K секцию, то же самое за вычетом п.1 и п.5.

[Огурцов]

Что есть в _макро_асм чего нельзя сделать в AVR-ASM?

Вспомню - скажу. Что-то у меня не получилось. Что-то типа вложенных макрасов. Да и в целом, на pdp11 писалось как-то легче. Толи просто моложе тогда был.

2. Шифрование.

Какое ?
А в целом, все равно в асме смысла не вижу. Кусок переписать, если нужно - да. Полностью - нет.

[defunct]

Какое ?

DES с 56-битным ключем.

[zltigo]

раздал зарплату сотрудникам. Сотрудники довольны - я доволен. Я доволен - сотрудники довольны.

Так вот, оказывется в чем Ваше призвание! Не мучте себя - работайте кассиром и в Новом Году будете счастливы и Вы и окружающие Вас. Ну а долгими зммними вечерами можете набрасывать на дельфях зарплатные ведомости .

Кстати, если бы знали, про кого смели так нехорошо выссказться, покраснели бы в крапинку и полгода не появлялись на форуме. Фильтруй базар (с) На будущее.

Oй! Неуж-то Вы у Ричи кассиром устроились? Ну а если серьезно,то краснеть мне незачто и по этой причине на это

зы: утром хотел попросить вас удалить все ваши посты и мои,

Не соглашусь.

[Огурцов]

DES с 56-битным ключем.

В этом смысле тоже есть что пооптимизить. Сейчас включено:

KEY_COUNT == 3
#define KEYBITS 256 //!< Use AES256.
#define ROUNDS 14 //!< Number of rounds.
#define KEYLENGTH 32 //!< Key length in number of bytes.

Oй! Неуж-то Вы у Ричи кассиром устроились?

Это уже весь бред ? Или еще будет ?

[defunct]

#define KEYBITS 256 //!< Use AES256.

У AVRки всего 10K перезаписей. Поэтому 56-бит неломаемо.

[zltigo]

Давайте вспомним, что до Нового Года остался совсем пустяк и простим друг другу свои мелкие недостатки.

Согласен .

Это уже весь бред ? Или еще будет ?

А, так Вы это бредили ! То-то я смотрю что-то про красное в крапинку начали нести... Хорошо, что предупредили, не сразу понял .

[Petka]

Ещё как идея: Попробуйте вместо буржуевского AES использовать отечественный стандарт шифрования ГОСТ. Насколько я понимаю он тоже очень прост в реализации, да и стойкость у него примерно такая-же как и у AES. Он менее производителен, зато более компактный код должен получиться.

[zltigo]

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

Он отнюдь не проще и насквозь 32 битный, что вообще для AVR смерть. Параноей страдать не надо и для AVR просто надо пользовать относительно "простенькие" уровня DES и прочих середины 70x-80 годов.

[Огурцов]

А, так Вы это бредили ! То-то я смотрю что-то про красное в крапинку начали нести... Хорошо, что предупредили, не сразу понял .

Я так понимаю, судя по продолжающемуся хамству, оригинальный код вы уже разместили в ~1.7k на GCC или ~1.1 на IAR, да ? Так и где же он ?

Попробуйте вместо буржуевского AES использовать отечественный стандарт шифрования ГОСТ.

С тем же успехом можно было использовать любой другой. Но у задачи есть еще одно существенное ограничение - минимально количество телодвижений. Исходный вариант в этом смысле был очень неплох. Да в общем-то и сейчас альтернатив не вижу.

У AVRки всего 10K перезаписей. Поэтому 56-бит неломаемо.

С параметрами
#if KEY_COUNT == 1
#define KEYBITS 128 //!< Use AES128.
#define ROUNDS 10 //!< Number of rounds.
#define KEYLENGTH 16 //!< Key length in number of bytes.

у меня что-то не сложилось. Да и в общем-то весь выигрышь лишь в длинне ключа - 16 байт и, кажется, размере ОЗУ, которого и так вполне хватает. Алгоритм, заточенный под конкретно 56 бит, я еще и не искал. С ним, вероятно, могло бы быть гораздо лучше.

[Petka]

Он отнюдь не проще и насквозь 32 битный, что вообще для AVR смерть. Параноей страдать не надо и для AVR просто надо пользовать относительно "простенькие" уровня DES и прочих середины 70x-80 годов.

то, что он "насквозь" 32битный не делает его большим в плане реализации. Из 32бит операций там сдвиги, XORы которые для 8битника совсем не тяжелы. А так же сложение, которое тоже не представляет проблемы. Ранее я говорил что ГОСТ не быстр, но ОЧЕНЬ прост в реализации.

[zltigo]

Из 32бит операций там сдвиги, XORы которые для 8битника совсем не тяжелы.

Для восьмибика "тяжелы" и, что в случае загрузчика более существенно - громоздки любые не 8bit операци вне зависимости от XOR это или OR... При этом он однозначно проиграет и сильно проиграет своему одногрупнику DES по размеру. Что получаем в замен? Длинный ключ? А оно это надо? Кто будет ломать этот AVR - госслужбы USA? Клуб любителей создающих кластеры в интернете? Когда есть ресурсы (загрузчик (корее BIOS) 8K c массой наворотов среди которых дешифратор просто теряется), то можно, как и я в свое время поступил, запихнуть тот-же AES и не париться.

[Petka]

... При этом он однозначно проиграет и сильно проиграет своему одногрупнику DES по размеру....

Очень спорно. ИМХО ГОСТ компактнее получится. Если приведёте свою оптимальную реализацию (на Си, и лучше оптимизированную для winavr) DES . То попробую сделать аналогичную процедуру ГОСТ. Можно будет сравнить. Самому любопытно.

[zltigo]

Я так понимаю, судя по продолжающемуся хамству....

Судя по повышению требований со 100 байт прописанных в заголовке до 900 ничего другого, кроме огульного обвиненя, теперь уже в хамстве у Вас не осталось. Напомню историю вопроса
1. Пролетели на 100 байт. С кем не бывает.
2. Вы начали пустопорожние общие разговоры об оптимизации
3. Я совершенно справедливо предположив, что ничего умнее, чем взять каой-нибудь писанный левой ногой исходник из интернета не сделано, выразился в духе, что зажать его на 100 байт без проблем.
4. С Вашей стороны начались рассказы о крутых профессионалах, от одного только имени (что-то вроде истинного имени Будды) которых лично я должен если не рассыпаться в прах, то как мимимум, покрыться красными полосками и удалиться в монастырь на покаяние.
5. Вами был выложен, как и предполагалось, писанный левой ногой исходник из интернету.
6. Естественно, он (точнее даже один из его кусков - других не касался) был соверженно спокойно сокращен на 250 байт... Что даже с учетом какого-нибудь другого генерящего менее компактный код компилятора просимые первоначально 100 байт обеспечивает наверняка.
7. Тут Вы начали совсем уж глупые разговоры о том, что это был "не тот" исходник а "тот" исходник он такооой исходник, что просто всем исходникам исходник и что-бы только приблизится к "тому" шедевру нужно зажать "этот" исходник вдвое.
8. Потом, вообще, зачем-то рассказали нам всем, как Вам нравится работать кассиром....

Короче,если-бы Вы дейсвительно, как Вам говорили несколько человек, выложили свой не влезающий на тот момент в 2K исходник, то возможно и был-бы повод для обсуждения. А так, так . Хотя нет, небольшая польза есть, если у кого были иллюзии, что в Интернете, пусть даже у "профессионалов" именитой фирмы, можно найти реально приличные исходники , то, надеюсь, они хоть слегка развеялись.

Очень спорно. ИМХО ГОСТ компактнее получится. Если приведёте свою оптимальную реализацию (на Си, и лучше оптимизированную для winavr) DES .

Ну сишные DES более, чем доступны, а "своими" и уж тем боле под AVR не занимался, ГОСТ реализация как-то на глаза не попадалась, но явно должна где-нибудь лежать. Для начала можете сравнить их и не в оптимизированном виде. По идее, когда-то давно использовал некий более простой, нежели DES (но его уровня) алгоритм - могу,когда вернусь домой, поискать в своих архивах.

[Petka]

Ну сишные DES более, чем доступны, а "своими" не занимался.

для сравнения нужна не просто "реализация из интернета". Хотелось-бы иметь уже толковую версию DESа.

ГОСТ реализация как-то на глаза не попадалась, но явно должна где-нибудь лежать. Для начала можете сравнить их и не в оптимизированном виде.

в неоптимизированном виде ГОСТ выигрывает.

По идее, когда-то давно использовал некий более простой, нежели DES (но его уровня) алгоритм - могу поискать в своих архивах.

Искать не надо. т.к. нужна доказательная база о "его уровня" защищённости. Либо классический DES (к классическими "ослаблениями"), либо ничего (в рамках данного исследования об размере кода).

[zltigo]

в неоптимизированном виде ГОСТ выигрывает.

Тогда, хотелось-бы взглянуть,что там для 8bit получилось. Ссылку на сишный исходник ГОСТ, пожалуйста. После Нового Года посмотрю.

Искать не надо. т.к. нужна доказательная база о "его уровня" защищённости.

Ну это тоже был не доморощенный - тех-же времен и с такой-же теоретической "подпоркой". Разница в основном в том, что официально принят штатами был DES.
P.S.
Вспомнил волшебные буквы TEA и XTEA. Там исходников дешифратора строк десять на C - думаю легко найдете.

[Petka]

Тогда, хотелось-бы взглянуть,что там для 8bit получилось. Ссылку на сишный исходник ГОСТ, пожалуйста. После Нового Года посмотрю.

ссылки нет. это моя реализация.

Ну это тоже был не доморощенный - тех-же времен и с такой-же теоретической "подпоркой". Разница в основном в том, что официально принят штатами был DES.

хотя-бы название?

[zltigo]

хотя-бы название?

Выше....

[Огурцов]

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

Нет, еще есть вариант - в глупости. 100 нехватало мне. А 900 нехватает вам, чтобы иметь право хотя бы встать в один ряд с тем профи. Насколько потребовалось бы ужать еще, чтобы сметь писать оскорбления в его адрес, я даже не говорю. Но вы ж этого все равно не понимаете. Так что одно из двух. Или и то и другое вместе.

2. Вы начали пустопорожние общие разговоры

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

8. Потом, вообще, зачем-то рассказали нам всем, как Вам нравится работать кассиром....

Резонно. Затем же, зачем и вы рассказали про свою жену, которая прилетела из риги.

[zltigo]

почистить за собой все ваши посты...

Уже один раз ответил.

в его адрес...

Раговор веду исключительно о Вас и оцениваю исключительно Вас по Вашим-же постам (за неимением сколь-нибудь внятного Вашего исходника - ну не считать-же право вот это

Код

void Bus_transmit_packet(uint8 aStatus)
{
    uint16 vCrc;

    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_sysdev_program | Slp_response_mask);
//    vCrc = vxl_get_crc16(Vxl_crc_ccitt_initial_value, Slp_sysdev_program | Slp_response_mask);
    Bus_staff_n_transmit_byte(aStatus);
    vCrc = vxl_get_crc16(0x7976, aStatus);
    Bus_staff_n_transmit_byte(vCrc >> 8);
    Bus_staff_n_transmit_byte(vCrc & 0xFF);
    Bus_transmit_byte(Slp_packet_end);
}

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

Резонно. Затем же, зачем и вы рассказали про свою жену, которая прилетела из риги.

Из Праги , но резонно. Признаю 8 пункт необоснованными наездом с моей стороны - прошу за него извинить , был не прав.

хотя-бы название?

Почти канонический исходник поминаемого XTEA из интернета

Код

void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long sum=0, delta=0x9E3779B9;
    for(i=0; i<num_rounds; i++) {
       v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
    for(i=0; i<num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

Кстати, в лоб скомпилированный 'cipher' под ARM/ARM Mode почти вдвое меньше, чем под AVR. Причем для заточенного под 8bit AES разницы практически нет, а если не подправить слегка хоть местами под 32bit, то на ARM толще но резонно. Признаю 8 пункт необоснованными с моей стороны.

хотя-бы название?

Почти канонический исходник поминаемого XTEA из интернета

Код

void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long sum=0, delta=0x9E3779B9;
    for(i=0; i<num_rounds; i++) {
       v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
    for(i=0; i<num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

Кстати, в лоб скомпилированный 'cipher' под ARM/ARM Mode почти вдвое меньше, чем под AVR. Причем для заточенного под 8bit AES разницы практически нет, а если не подправить слегка хоть местами под 32bit, то на ARM толще
Сколько у Вас Гостов
Сколько у Вас Гостовский 'движек' на AVR занял?

[Petka]

Сколько у Вас Гостовский 'движек' на AVR занял?

Никогда его ещё не пробовал на AVR. "В лоб" получилось:
ГОСТ 786 байта. (кодер+декодер)
XTEA 972 байта. (кодер+декодер)

Никаких оптимизаций не делал для 8ми бит.

[Огурцов]

Уже один раз ответил.

Контрольный - мало ли, вы опять не поняли.

Раговор веду исключительно о Вас

Опять ложь.

ну не считать-же право вот это достойным разговоров об оптимизации

Вы наконец-то решили вернуться к теме ? Тогда мне непонятно: "это" недостойно оптимизации, потому что вы можете написать в несколько раз лучше ? Так напишите. 10 строчек кода вместо 10 строчек болтовни - и всем все сразу понятно.
Или же напротив, "это" написано настолько хорошо, что ни о какой дальнейшей оптимизации не может идти разговор ?

Никаких мифических персонажей не обсуждаю

С чего вы вбили это себе в бошку ? Повторить еще раз, что реальный профи реальный ?

[zltigo]

XTEA 972 байта. (кодер+декодер)

Очень странно. Сейчас посмотреть не могу, но вышепреведенный исходник движка декодера откомпилировлся для AVR в немногим больше 200 байт. Кодер там практически такой-же...200 + 200 = 972????

[Petka]

Очень странно. Сейчас посмотреть не могу, но вышепреведенный исходник движка декодера откомпилировлся для AVR в немногим больше 200 байт. Кодер там практически такой-же...200 + 200 = 972????

за что купил, за то продаю:

CODE

00000388 <encipher>:



void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
388: 2f 92 push r2
38a: 3f 92 push r3
38c: 4f 92 push r4
38e: 5f 92 push r5
390: 6f 92 push r6
392: 7f 92 push r7
394: 8f 92 push r8
396: 9f 92 push r9
398: af 92 push r10
39a: bf 92 push r11
39c: cf 92 push r12
39e: df 92 push r13
3a0: ef 92 push r14
3a2: ff 92 push r15
3a4: 0f 93 push r16
3a6: 1f 93 push r17
3a8: df 93 push r29
3aa: cf 93 push r28
3ac: cd b7 in r28, 0x3d; 61
3ae: de b7 in r29, 0x3e; 62
3b0: 2a 97 sbiw r28, 0x0a; 10
3b2: 0f b6 in r0, 0x3f; 63
3b4: f8 94 cli
3b6: de bf out 0x3e, r29; 62
3b8: 0f be out 0x3f, r0; 63
3ba: cd bf out 0x3d, r28; 61
3bc: 7a 87 std Y+10, r23; 0x0a
3be: 69 87 std Y+9, r22; 0x09
3c0: ba 01 movw r22, r20
unsigned long v0=v[0], v1=v[1], i;
3c2: a9 85 ldd r26, Y+9; 0x09
3c4: ba 85 ldd r27, Y+10; 0x0a
3c6: 2d 90 ld r2, X+
3c8: 3d 90 ld r3, X+
3ca: 4d 90 ld r4, X+
3cc: 5c 90 ld r5, X
3ce: 13 97 sbiw r26, 0x03; 3
3d0: 14 96 adiw r26, 0x04; 4
3d2: 6d 90 ld r6, X+
3d4: 7d 90 ld r7, X+
3d6: 8d 90 ld r8, X+
3d8: 9c 90 ld r9, X
3da: 17 97 sbiw r26, 0x07; 7
3dc: 19 82 std Y+1, r1; 0x01
3de: 1a 82 std Y+2, r1; 0x02
3e0: 1b 82 std Y+3, r1; 0x03
3e2: 1c 82 std Y+4, r1; 0x04
3e4: aa 24 eor r10, r10
3e6: bb 24 eor r11, r11
3e8: 65 01 movw r12, r10
unsigned long sum=0, delta=0x9E3779B9;
for(i=0; i<num_rounds; i++) {
3ea: 9c 01 movw r18, r24
3ec: 40 e0 ldi r20, 0x00; 0
3ee: 50 e0 ldi r21, 0x00; 0
3f0: 2d 83 std Y+5, r18; 0x05
3f2: 3e 83 std Y+6, r19; 0x06
3f4: 4f 83 std Y+7, r20; 0x07
3f6: 58 87 std Y+8, r21; 0x08
3f8: 83 c0 rjmp .+262 ; 0x500 <encipher+0x178>
v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
3fa: f5 01 movw r30, r10
3fc: e3 70 andi r30, 0x03; 3
3fe: f0 70 andi r31, 0x00; 0
400: ee 0f add r30, r30
402: ff 1f adc r31, r31
404: ee 0f add r30, r30
406: ff 1f adc r31, r31
408: e6 0f add r30, r22
40a: f7 1f adc r31, r23
40c: e0 80 ld r14, Z
40e: f1 80 ldd r15, Z+1; 0x01
410: 02 81 ldd r16, Z+2; 0x02
412: 13 81 ldd r17, Z+3; 0x03
414: ea 0c add r14, r10
416: fb 1c adc r15, r11
418: 0c 1d adc r16, r12
41a: 1d 1d adc r17, r13
41c: d4 01 movw r26, r8
41e: c3 01 movw r24, r6
420: f5 e0 ldi r31, 0x05; 5
422: b6 95 lsr r27
424: a7 95 ror r26
426: 97 95 ror r25
428: 87 95 ror r24
42a: fa 95 dec r31
42c: d1 f7 brne .-12 ; 0x422 <encipher+0x9a>
42e: a4 01 movw r20, r8
430: 93 01 movw r18, r6
432: e4 e0 ldi r30, 0x04; 4
434: 22 0f add r18, r18
436: 33 1f adc r19, r19
438: 44 1f adc r20, r20
43a: 55 1f adc r21, r21
43c: ea 95 dec r30
43e: d1 f7 brne .-12 ; 0x434 <encipher+0xac>
440: 82 27 eor r24, r18
442: 93 27 eor r25, r19
444: a4 27 eor r26, r20
446: b5 27 eor r27, r21
448: 86 0d add r24, r6
44a: 97 1d adc r25, r7
44c: a8 1d adc r26, r8
44e: b9 1d adc r27, r9
450: e8 26 eor r14, r24
452: f9 26 eor r15, r25
454: 0a 27 eor r16, r26
456: 1b 27 eor r17, r27
458: 2e 0c add r2, r14
45a: 3f 1c adc r3, r15
45c: 40 1e adc r4, r16
45e: 51 1e adc r5, r17
sum += delta;
460: 89 eb ldi r24, 0xB9; 185
462: 99 e7 ldi r25, 0x79; 121
464: a7 e3 ldi r26, 0x37; 55
466: be e9 ldi r27, 0x9E; 158
468: a8 0e add r10, r24
46a: b9 1e adc r11, r25
46c: ca 1e adc r12, r26
46e: db 1e adc r13, r27
v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
470: a2 01 movw r20, r4
472: 91 01 movw r18, r2
474: 05 e0 ldi r16, 0x05; 5
476: 56 95 lsr r21
478: 47 95 ror r20
47a: 37 95 ror r19
47c: 27 95 ror r18
47e: 0a 95 dec r16
480: d1 f7 brne .-12 ; 0x476 <encipher+0xee>
482: d2 01 movw r26, r4
484: c1 01 movw r24, r2
486: 14 e0 ldi r17, 0x04; 4
488: 88 0f add r24, r24
48a: 99 1f adc r25, r25
48c: aa 1f adc r26, r26
48e: bb 1f adc r27, r27
490: 1a 95 dec r17
492: d1 f7 brne .-12 ; 0x488 <encipher+0x100>
494: 28 27 eor r18, r24
496: 39 27 eor r19, r25
498: 4a 27 eor r20, r26
49a: 5b 27 eor r21, r27
49c: 22 0d add r18, r2
49e: 33 1d adc r19, r3
4a0: 44 1d adc r20, r4
4a2: 55 1d adc r21, r5
4a4: d6 01 movw r26, r12
4a6: c5 01 movw r24, r10
4a8: fb e0 ldi r31, 0x0B; 11
4aa: b6 95 lsr r27
4ac: a7 95 ror r26
4ae: 97 95 ror r25
4b0: 87 95 ror r24
4b2: fa 95 dec r31
4b4: d1 f7 brne .-12 ; 0x4aa <encipher+0x122>
4b6: 83 70 andi r24, 0x03; 3
4b8: 90 70 andi r25, 0x00; 0
4ba: 88 0f add r24, r24
4bc: 99 1f adc r25, r25
4be: 88 0f add r24, r24
4c0: 99 1f adc r25, r25
4c2: 86 0f add r24, r22
4c4: 97 1f adc r25, r23
4c6: fc 01 movw r30, r24
4c8: 80 81 ld r24, Z
4ca: 91 81 ldd r25, Z+1; 0x01
4cc: a2 81 ldd r26, Z+2; 0x02
4ce: b3 81 ldd r27, Z+3; 0x03
4d0: 8a 0d add r24, r10
4d2: 9b 1d adc r25, r11
4d4: ac 1d adc r26, r12
4d6: bd 1d adc r27, r13
4d8: 28 27 eor r18, r24
4da: 39 27 eor r19, r25
4dc: 4a 27 eor r20, r26
4de: 5b 27 eor r21, r27
4e0: 62 0e add r6, r18
4e2: 73 1e adc r7, r19
4e4: 84 1e adc r8, r20
4e6: 95 1e adc r9, r21


void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
unsigned long v0=v[0], v1=v[1], i;
unsigned long sum=0, delta=0x9E3779B9;
for(i=0; i<num_rounds; i++) {
4e8: 29 81 ldd r18, Y+1; 0x01
4ea: 3a 81 ldd r19, Y+2; 0x02
4ec: 4b 81 ldd r20, Y+3; 0x03
4ee: 5c 81 ldd r21, Y+4; 0x04
4f0: 2f 5f subi r18, 0xFF; 255
4f2: 3f 4f sbci r19, 0xFF; 255
4f4: 4f 4f sbci r20, 0xFF; 255
4f6: 5f 4f sbci r21, 0xFF; 255
4f8: 29 83 std Y+1, r18; 0x01
4fa: 3a 83 std Y+2, r19; 0x02
4fc: 4b 83 std Y+3, r20; 0x03
4fe: 5c 83 std Y+4, r21; 0x04
500: 89 81 ldd r24, Y+1; 0x01
502: 9a 81 ldd r25, Y+2; 0x02
504: ab 81 ldd r26, Y+3; 0x03
506: bc 81 ldd r27, Y+4; 0x04
508: 2d 81 ldd r18, Y+5; 0x05
50a: 3e 81 ldd r19, Y+6; 0x06
50c: 4f 81 ldd r20, Y+7; 0x07
50e: 58 85 ldd r21, Y+8; 0x08
510: 82 17 cp r24, r18
512: 93 07 cpc r25, r19
514: a4 07 cpc r26, r20
516: b5 07 cpc r27, r21
518: 08 f4 brcc .+2 ; 0x51c <encipher+0x194>
51a: 6f cf rjmp .-290 ; 0x3fa <encipher+0x72>
v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
sum += delta;
v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
}
v[0]=v0; v[1]=v1;
51c: a9 85 ldd r26, Y+9; 0x09
51e: ba 85 ldd r27, Y+10; 0x0a
520: 2d 92 st X+, r2
522: 3d 92 st X+, r3
524: 4d 92 st X+, r4
526: 5c 92 st X, r5
528: 13 97 sbiw r26, 0x03; 3
52a: fd 01 movw r30, r26
52c: 64 82 std Z+4, r6; 0x04
52e: 75 82 std Z+5, r7; 0x05
530: 86 82 std Z+6, r8; 0x06
532: 97 82 std Z+7, r9; 0x07
}
534: 2a 96 adiw r28, 0x0a; 10
536: 0f b6 in r0, 0x3f; 63
538: f8 94 cli
53a: de bf out 0x3e, r29; 62
53c: 0f be out 0x3f, r0; 63
53e: cd bf out 0x3d, r28; 61
540: cf 91 pop r28
542: df 91 pop r29
544: 1f 91 pop r17
546: 0f 91 pop r16
548: ff 90 pop r15
54a: ef 90 pop r14
54c: df 90 pop r13
54e: cf 90 pop r12
550: bf 90 pop r11
552: af 90 pop r10
554: 9f 90 pop r9
556: 8f 90 pop r8
558: 7f 90 pop r7
55a: 6f 90 pop r6
55c: 5f 90 pop r5
55e: 4f 90 pop r4
560: 3f 90 pop r3
562: 2f 90 pop r2
564: 08 95 ret

00000566 <decipher>:

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
566: 2f 92 push r2
568: 3f 92 push r3
56a: 4f 92 push r4
56c: 5f 92 push r5
56e: 6f 92 push r6
570: 7f 92 push r7
572: 8f 92 push r8
574: 9f 92 push r9
576: af 92 push r10
578: bf 92 push r11
57a: cf 92 push r12
57c: df 92 push r13
57e: ef 92 push r14
580: ff 92 push r15
582: 0f 93 push r16
584: 1f 93 push r17
586: df 93 push r29
588: cf 93 push r28
58a: cd b7 in r28, 0x3d; 61
58c: de b7 in r29, 0x3e; 62
58e: 2c 97 sbiw r28, 0x0c; 12
590: 0f b6 in r0, 0x3f; 63
592: f8 94 cli
594: de bf out 0x3e, r29; 62
596: 0f be out 0x3f, r0; 63
598: cd bf out 0x3d, r28; 61
59a: 7c 87 std Y+12, r23; 0x0c
59c: 6b 87 std Y+11, r22; 0x0b
59e: 5a 87 std Y+10, r21; 0x0a
5a0: 49 87 std Y+9, r20; 0x09
unsigned long v0=v[0], v1=v[1], i;
5a2: db 01 movw r26, r22
5a4: 2d 90 ld r2, X+
5a6: 3d 90 ld r3, X+
5a8: 4d 90 ld r4, X+
5aa: 5c 90 ld r5, X
5ac: 13 97 sbiw r26, 0x03; 3
5ae: 14 96 adiw r26, 0x04; 4
5b0: 6d 90 ld r6, X+
5b2: 7d 90 ld r7, X+
5b4: 8d 90 ld r8, X+
5b6: 9c 90 ld r9, X
5b8: 17 97 sbiw r26, 0x07; 7
unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
5ba: 9c 01 movw r18, r24
5bc: 40 e0 ldi r20, 0x00; 0
5be: 50 e0 ldi r21, 0x00; 0
5c0: 2d 83 std Y+5, r18; 0x05
5c2: 3e 83 std Y+6, r19; 0x06
5c4: 4f 83 std Y+7, r20; 0x07
5c6: 58 87 std Y+8, r21; 0x08
5c8: ca 01 movw r24, r20
5ca: b9 01 movw r22, r18
5cc: 29 eb ldi r18, 0xB9; 185
5ce: 39 e7 ldi r19, 0x79; 121
5d0: 47 e3 ldi r20, 0x37; 55
5d2: 5e e9 ldi r21, 0x9E; 158
5d4: 1d d5 rcall .+2618 ; 0x1010 <__mulsi3>
5d6: 5b 01 movw r10, r22
5d8: 6c 01 movw r12, r24
5da: 19 82 std Y+1, r1; 0x01
5dc: 1a 82 std Y+2, r1; 0x02
5de: 1b 82 std Y+3, r1; 0x03
5e0: 1c 82 std Y+4, r1; 0x04
5e2: 87 c0 rjmp .+270 ; 0x6f2 <decipher+0x18c>
for(i=0; i<num_rounds; i++) {
v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
5e4: d6 01 movw r26, r12
5e6: c5 01 movw r24, r10
5e8: fb e0 ldi r31, 0x0B; 11
5ea: b6 95 lsr r27
5ec: a7 95 ror r26
5ee: 97 95 ror r25
5f0: 87 95 ror r24
5f2: fa 95 dec r31
5f4: d1 f7 brne .-12 ; 0x5ea <decipher+0x84>
5f6: 83 70 andi r24, 0x03; 3
5f8: 90 70 andi r25, 0x00; 0
5fa: 88 0f add r24, r24
5fc: 99 1f adc r25, r25
5fe: 88 0f add r24, r24
600: 99 1f adc r25, r25
602: 49 85 ldd r20, Y+9; 0x09
604: 5a 85 ldd r21, Y+10; 0x0a
606: 84 0f add r24, r20
608: 95 1f adc r25, r21
60a: dc 01 movw r26, r24
60c: ed 90 ld r14, X+
60e: fd 90 ld r15, X+
610: 0d 91 ld r16, X+
612: 1c 91 ld r17, X
614: ea 0c add r14, r10
616: fb 1c adc r15, r11
618: 0c 1d adc r16, r12
61a: 1d 1d adc r17, r13
61c: d2 01 movw r26, r4
61e: c1 01 movw r24, r2
620: 75 e0 ldi r23, 0x05; 5
622: b6 95 lsr r27
624: a7 95 ror r26
626: 97 95 ror r25
628: 87 95 ror r24
62a: 7a 95 dec r23
62c: d1 f7 brne .-12 ; 0x622 <decipher+0xbc>
62e: a2 01 movw r20, r4
630: 91 01 movw r18, r2
632: 64 e0 ldi r22, 0x04; 4
634: 22 0f add r18, r18
636: 33 1f adc r19, r19
638: 44 1f adc r20, r20
63a: 55 1f adc r21, r21
63c: 6a 95 dec r22
63e: d1 f7 brne .-12 ; 0x634 <decipher+0xce>
640: 82 27 eor r24, r18
642: 93 27 eor r25, r19
644: a4 27 eor r26, r20
646: b5 27 eor r27, r21
648: 82 0d add r24, r2
64a: 93 1d adc r25, r3
64c: a4 1d adc r26, r4
64e: b5 1d adc r27, r5
650: e8 26 eor r14, r24
652: f9 26 eor r15, r25
654: 0a 27 eor r16, r26
656: 1b 27 eor r17, r27
658: 6e 18 sub r6, r14
65a: 7f 08 sbc r7, r15
65c: 80 0a sbc r8, r16
65e: 91 0a sbc r9, r17
sum -= delta;
660: 27 e4 ldi r18, 0x47; 71
662: 36 e8 ldi r19, 0x86; 134
664: 48 ec ldi r20, 0xC8; 200
666: 51 e6 ldi r21, 0x61; 97
668: a2 0e add r10, r18
66a: b3 1e adc r11, r19
66c: c4 1e adc r12, r20
66e: d5 1e adc r13, r21
v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
670: a4 01 movw r20, r8
672: 93 01

[zltigo]

за что купил, за то продаю:

31 вернусь домой - повторю и выложу "двухсотбайтовый" из под IAR.

[Petka]

31 вернусь домой - повторю и выложу "двухсотбайтовый" из под IAR.

IARом не обладаю, так что может будем лучше сравнивать в доступном gcc? Я Вам верю что 200 с копейками байт получалось под IARом. С другой стороны тогда ГОСТ получится ещё более кучерявым чем 200 байт

[zltigo]

IARом не обладаю, так что может будем лучше сравнивать в доступном gcc?

Что-то мне не хочется GCC toolchain под AVR себе добавлять, тем более имеет быть проблема выбора...
Для AVR я пишу редко, под несерьезных (которых не волнует лицензионность) заказчиков, а для своих целей, мне на самом деле хватит самых мелких (которые конкурентноспособны) AVR и 4K.

Я Вам верю что 200 с копейками байт получалось под IARом.

А вот мне что-то кажется очень странным такой провал с GCC. Для того-же ARM, не говоря об 386 он весьма неплох. Какой версией/сборкой компилировали?

[Petka]

Что-то мне не хочется GCC toolchain под AVR себе добавлять, тем более имеет быть проблема выбора...

какая проблема выбора? последний winavr. Знаю, что более ранние версии генерят более компактный код. Но пока ещё никогда не упирался в размер флеша из-за неоптимальной компиляции.

Какой версией/сборкой компилировали?

WinAVR 20081205

[singlskv]

А вот мне что-то кажется очень странным такой провал с GCC.

Чего-то сдесь не то, 400 байт на кодер/декодер не должно хватать.
IAR вынес что-то еще кроме умножения sum=delta*num_rounds; в отдельное место ?

Не хочу ставить IAR на новый комп и проверять, тч ждем Ваш листинг из №63

P.S. На GCC нужно по крайней мере заменить:
unsigned long v0=v[0], v1=v[1], i;
на
unsigned long v0=v[0], v1=v[1];
unsigned int i;

это - ~160 байт на 2 функциях

ulong i никому там не нужен...

[_Pasha]

C vs ASM (AVR):
Вчера переписал на одном девайсе прерывание. Несколько обработчиков вызывают одну и ту же ф-цию с разными параметрами.
Асм левой ногой "сделал всех" на 200 байт. Почему так:
- необходимость вызова функции в обработчиках тянет за собой лишние сохранения регистров, в то время как вручную это все сводится к минимуму,
- манипуляции с битами через bld/bst иногда очень экономны, компилер такое ниасилит,
- получение результата сравнения в бите переноса и его использование при сдвиге,
- более экономное использование регистров, продиктованное нежеланием порождать лишние пары push/pop, и связанный с этим порядок чтения/записи переменных и некоторые ручные оптимизации алгоритма. Компилер же тем временем осуществляет "забеги в ширину", исходя из общей стратегии "прочитал - выполнил_регистровые_операции - записал".
Так что на вопрос, где искать исчезающие байты, ответ прост.

[singlskv]

C vs ASM (AVR):
...........................
Так что на вопрос, где искать исчезающие байты, ответ прост.

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

Как пример, умножение 16бит X 16бит = 32 бит ,
в С оверхед жуткий из-за приведения всего к 32бит.

[Rst7]

в С оверхед жуткий из-за приведения всего к 32бит.

Где?

Код

        RSEG CODE:CODE:NOROOT(1)
//    3 unsigned long mmm(unsigned int a, unsigned int b)
mmm:
//    4 {
//    5   return (unsigned long)a*b;
        CLR     R2
        MUL     R17, R19
        MOVW    R23:R22, R1:R0
        MUL     R16, R18
        MOVW    R21:R20, R1:R0
        MUL     R17, R18
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MUL     R19, R16
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MOVW    R17:R16, R21:R20
        MOVW    R19:R18, R23:R22
        RET
//    6 }

[singlskv]

Где?

IAR в таких случаях действительно оптимизирует,
gcc увы следует стандарту и умножает 32X32

Код

  6a:    0c d0           rcall    .+24     ; 0x84 <__mulsi3>
.................................
00000084 <__mulsi3>:
  84:    62 9f           mul    r22, r18
  86:    d0 01           movw    r26, r0
  88:    73 9f           mul    r23, r19
  8a:    f0 01           movw    r30, r0
  8c:    82 9f           mul    r24, r18
  8e:    e0 0d           add    r30, r0
  90:    f1 1d           adc    r31, r1
  92:    64 9f           mul    r22, r20
  94:    e0 0d           add    r30, r0
  96:    f1 1d           adc    r31, r1
  98:    92 9f           mul    r25, r18
  9a:    f0 0d           add    r31, r0
  9c:    83 9f           mul    r24, r19
  9e:    f0 0d           add    r31, r0
  a0:    74 9f           mul    r23, r20
  a2:    f0 0d           add    r31, r0
  a4:    65 9f           mul    r22, r21
  a6:    f0 0d           add    r31, r0
  a8:    99 27           eor    r25, r25
  aa:    72 9f           mul    r23, r18
  ac:    b0 0d           add    r27, r0
  ae:    e1 1d           adc    r30, r1
  b0:    f9 1f           adc    r31, r25
  b2:    63 9f           mul    r22, r19
  b4:    b0 0d           add    r27, r0
  b6:    e1 1d           adc    r30, r1
  b8:    f9 1f           adc    r31, r25
  ba:    bd 01           movw    r22, r26
  bc:    cf 01           movw    r24, r30
  be:    11 24           eor    r1, r1
  c0:    08 95           ret

[_Pasha]

Где?

Вы про IAR, а мы про GCC

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

[Rst7]

IAR в таких случаях действительно оптимизирует,gcc увы следует стандарту и умножает 32X32

Причем тут стандарт? Оба компилятора поступили по стандартую Только оптимизатор иара чутьнамного более умный и понимает, что если мы преобразовали short в long, то два старших байта будут равны 0. А следовательно, результат умножения с этими байтами можно заменить на 0, а затем, рассматривая сложение с 0, банально его (сложение) убирает. Все рады

А вообще, хотел ответить в духе "ну и пусть этот гнусь вместе со своими адептами подхода "жрите что дают" убъются апстену", ну будем считать, что сдержался

[aesok]

gcc увы следует стандарту и умножает 32X32

Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.

При их наличии может немного возрастать размер кода, но время выполнения уменьшиться.

Анатолий.

А вообще, хотел ответить в духе "ну и пусть этот гнусь вместе со своими адептами подхода "жрите что дают" убъются апстену", ну будем считать, что сдержался

Жрите что дают, не нравиться готовте сами, не умеете платите деньги... Не сдержался.....


Анатолий.

Сообщение отредактировал aesok - Dec 30 2008, 13:31

[singlskv]

Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.

про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.

На самом деле, ИМХО, стоило бы просто добавить в libc набор функций(частично инлайн)"
16x8=32
16x16=32
24x8=32
32/8=32
32/16=16
24/8=24
24/16=16
итд.

[aesok]

про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.

В GCC имеется полный набор шаблонов инструкций для описания 32 битных
операций умножения 'mulsi3', `ssmulsi3', `usmulsi3', где 'si' означеает
single integer (или 32-бит) mode 's' и 'u' signed/unsigned. Также есть набор
шаблонов для 16x16=32 бит умножения `mulhisi3', `umulhisi3', `usmulhisi3',
где 'hi' half integer (16-бит) mode размерность операндов и 'si" mode размерность
результата.

Так как последние не реализованы для avr платформы, то компилятор всегда
использует 32-битное умножение для 16- и 32-битных операндов, если необходим
32-битный результат.

Добавить эти инструкции несложно, при этом добаляются функции __mulhisi3,
__ssmulhisi3 __sumulhisi3, Но может оказаться так что в результирующем коде
вместо 4 вызовов функции __mulsi3, будет по одному вызову __mulsi3,
__mulhisi3, __ssmulhisi3 __sumulhisi3 при этом размер кода возрастет. Но все
равно в большинстве случаях должен быть выигрыш и в размере кода тоже, не
только в скорости.

Анатолий.

Сообщение отредактировал aesok - Dec 30 2008, 14:36

[singlskv]

Так как последние не реализованы для avr платформы, то компилятор всегда
использует 32-битное умножение для 16- и 32-битных операндов, если необходим
32-битный результат.

дык это все понятно, просто ИМХО, если нет реализации для avr платформы,
то можно было бы их просто в libc прописать...
ну и добавить типа 24/8=16 итд, что бывает очень актуально для авр...

усилий то для этого минимум, а в результате не нужно самописные модули организовывать.

[Огурцов]

Для этого нужно перекомпилировать под свой проект crtXXXX.o.

Пытался добавить в проект разные crt*.S компилит с ошибками типа

"stdint.h:116: Error: unknown opcode `typedef'"

В файле stdint.h такая строка:

typedef int int8_t __attribute__((__mode__(__QI__)));

Если не включать avr/io.h тогда в принципе собирается, но нужно либо самому все дефайнить, либо убирать большую часть crt*.S, ни то и ни другое не подходит. Так как правильно скомпилить crt*.S ?

[ReAl]

Пытался добавить в проект разные crt*.S компилит с ошибками типа

"stdint.h:116: Error: unknown opcode `typedef'"
...
Так как правильно скомпилить crt*.S ?

Да должно быть так же, как и остальные .S файлы:

Код

AS    := avr-gcc -x assembler-with-cpp

И по разбросанным по .h- файлам #ifndef __ASSEMBLER__ лишнее изымается (не из всех, в wdt.h, кажется, остаются лишние чисто С-шные вещи, но для crt должно хватать)

[_Pasha]

Если не включать avr/io.h тогда в принципе собирается

С оригинальным avr/io.h такого нету - он за собой stdint.h не цепляет при вызове из асма. Переставьте WinAVR

[Огурцов]

Цепляет, он там косвенно, через полдюжины #include цепляет. Пришлось сделать две вещи - включить common.h в gcrt1.S (после! #include "macros.inc") и добавить -D__ASSEMBLER__ к gcrt1.S.

gcrt1.o: ../Avr-libc/gcrt1.S
$(CC) $(INCLUDES) $(ASMFLAGS) -c -D__ASSEMBLER__ $<

хотя -x assembler-with-cpp были уже добавлены:

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

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