если не секрет - что там было такого страшного, кроме туповатого линкера?

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

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

Я, кстати, тоже по возможности использую GCC, и коллег, работающих со мной наиболее тесно, на него почти перетянул.

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



У него странная система вызовов, диковинные форматы файлов, неполная поддержка стандарта - это то, что помнится навскидку. А еще у меня возникло ощущение, что STM8 туда прикручивали по остаточному принципу.



Я скажу по секрету, что у нас среди разработчиков тоже есть любители генерировать код визардами. Это создает отдельные проблемы.

вообще да) сначала он был под mcs-51, потом прикрутили z80, затем pic-и, еще чего-то. Порт stm8 емнип пилят полтора землекопа.

попробуйте последний snapshot. Недавно делал проектик SDCC STM8 - код без правок копипастил для сравнения в ИАР, ИАР на ~100 байт меньше размер сделал. Оба варианта одинаково в железе работают. Никаких негативных ощущений не возникло, единственное SDCC при работе с битами периферии чудит (4 команды вместо bset/bres), решается проблема дополнительным peep файликом.

А по теме - GCC нынче "расширился" значительно, что иногда проще не переносить чужой код в другой компилятор. А GCC для микроконтроллеров сейчас делает вполне компактный выхлоп.
https://habrahabr.ru/post/315676/

жалко, что до сих пор для AVR не сделали пространство имен __eeprom аналогично тому, как сделали __flash.

ARV, по поводу трасировки, так как у вас дефайн log_i из кода, убираеться ?
Если он находится в debug.h то в релизной версии убирается и начинается ругань компилятора на неизвестную конструкцию. Как то так?

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

Так так а вот про это по подробнее, как она автоматически убирается?
Допустим я использовал макрос log_i(x) где-то в майне, так вот после того как
выключаем макрос __DEBUG__ определение макроса log_i(x) убирается, при этом на пустую заглушку не изменяться.

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


PS:GCC не пользовался ни разу.

все макросы log_xxx продефайнены именно в обертке #if defined(__DEBUG__), поэтому при отсутствии этого макроса должны подставляться пустышки.