У вас такое бывало? Вероятнее всего - нет. Ибо ужать 2К программу на 128 байт обычно не составляет труда. Дальнейшая дискуссия неинтересна - вы спорите о вкусе устриц с теми, кто их ел.

У меня в ближайшем будущем стоит задача ужать хотябы на 100Б код для АТтини2313 ... Прога писана в Ассеблере, изначально уже оптимизирована и по обьему кода и по скорости. В случае написании на Си и оптимизации по обьему (Оs), код , я думаю , тоже будет ужат нормально, а этих 128Б может как раз не хватить

не понимаю я bootloader'ы в WinAVR, CV, ICC или еще какой-то байде, для бутсекций в 2kb. Если старая программа написана на asm'е да еще и соптимизирована, то на Си вы просто ни при каких обстоятельствах не сможете добиться такого функционала в том же объеме, не говоря уже о расширении оного.

Функционал который со скрипом влезет в самую большую бут секцию (2kb) с макс оптимизацией на WinAVR, - на асм поместится в самую маленькую бутсекцию из 256 байт. Достигается это за счет оптимальных прологов/эпилогов функций и исключительно регистровых переменных.
Реализция бутлоадера на Сях оправдана разве только "тайм ту маркетом" либо большим объемом флеш целевого МК. На С vs ASM, вы всегда потеряете или функциональность, или объем, или скорость, или всё сразу, какой бы ключик оптимизации не ставили.


У меня вот что есть сказать, - бутсекция 1кб - поддержка: modbus по 485-му, загрузка с внешней eeprom'ки, CRC апп секции, шифрование в обе стороны... Портирование между МК байты приходится искать вставляя код в неиспользуемые ячейки таблицы векторов, проект собирается ровно в 1024байт ни одной свободной ячейки флеш (портировать с m8 напр на m16 - занятие не особо веселое, и найти там не то что 128, 8 байт без урезания функционала - большая проблема). Зато освобождается целый 1кб под апликейшин, для 8/16кб флешевых чипов - очень актуально. Бутлоадер - это такой тип программы, где простота найти 128 байт - означает недодать эти 128 байт (чаще больше) аппликейшину, а там они явно нужнее.

Как человек неоднократно писавший загрузчики размером от 128байт до 16килобайт, как на ASM, так и на С для самых разных контроллеров, не могу не сказать, что соотношение 256 и 2048 есть абсолютный бред. Для получения такого "результата" нужно писать даже не левой ногой, а протезом левой ноги и после многократной лоботомии. На прикладных программах в десятки килобайт, ситуация с ASM становится еще печальнее, если программа создается за конечное время.

Голову на плечах иметь надо, а продуманные ключики оптимизации это дело абсолютно обязательное, но не они задают уровень качества полученного продукта.


Совершенно достаточный размер для более,чем многофункционального загрузчика. Все, что больше 1K редко способно выдержать конкуренцию с C. Ниша ASM загрузчиков заканчивается на уровне 128...256, максимум 512 байт. Дальше в 99% совершенно бессмысленно, даже при наличии хорошего опыта и больших шишек в ASM-описании. Результат-же большинства писателей на ASM (читай тех, кто только уровень ASM сумел понять и принять) вообще начинает не лезть в никакие ворота . Вышесказанное, естественно, совершенно не означает того, что любой освоивший copy-paste мусора из интернету и прочитавший книгу типа Редькинской способен вообще что-то вменяемое написать на C. Тут порог вхождения в качественное программирование повыше будет.

Достаточно одного неаккуратного оператора "*", "/" чтобы занять 2KB в 8-ми битнике.
Речь не о прикладных программах. Bootloader имеет самое постоянное и самое длительное время жизни. Требует высокой скорости работы, компактности и функционала.

То что там состряпает winavr и есть код писанный протезом левой ноги.


При условии что есть возможность поместить тот же функционал в 1KB, тратить 2KB неразумно.


загрузчик по TFTP через ethernet на asm укладывается в 2KB секцию.

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

Компактность и функционал должны быть достаточными, а не самоцелью.

То, что Вы назвали winavr, есть GCC. Не самый плохой компилятор. Делает то, что ему прикажут. Для AVR, правда, есть и получше.

Повторяю, cегодня, а не в середине 80x, на уровне программ размером 1-2K выигрыша в два раза между ASM и профессионально написанным C не бывает.
Двухкратным превосходством можете изредка себя тешить на кусочках программ с единицы-десятки байт.

TFTP/UDP/IP как раз тот случай когда смысл использования ASM равен ровно нулю. Проверено неоднократно. Та-же поддержка сети в на рубеже 80/90х писалась для своей операционки на 286 на ASM. На ASM тогда писалось все по причине того, что 12MHz 286 был отнюдь не гигант производительности и экономился каждый такт в системе жесткого реального времени с эмулятором виртуальной машины. Всякие фокусы, типа модифицируемого на лету кода тоже приходилось использовать. Доступные тогда C компиляторы были совершенно сырыми . Эта фигня, как ни странно, живет и немного сопровождается по сей день. Не переписана на C по двум причинам - там все-таки набежало более 120K кода, что по любому немалая работа, и в общем-то это уже лет 10 минимум развивать бессмысленно.