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


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

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

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

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

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

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

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

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

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


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

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

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



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



Анатолий.

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

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

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

Анатолий.

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

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

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


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


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

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

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

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


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

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


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



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




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

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

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

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

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

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



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


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

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

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

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


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

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

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

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

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

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

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

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

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

Анатолий.

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

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


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

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

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

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

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

Стало:


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

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

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

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

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


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


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

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

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

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

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

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

P.S.

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

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

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

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

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

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


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


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



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


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


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


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


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


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

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

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



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

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

Огурцов:

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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



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

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

Согласен .


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