Использование особенностей GCC для повышения комфорта

[arkhnchul]

YS писал(а):

желание использовать SDCC у меня отпало когда я дочитал документацию по нему примерно до половины

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

[ARV]

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

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

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

[YS]

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

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

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

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

чего уж говорить о любителях генерировать код визардами?!

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

[arkhnchul]

YS писал(а):

А еще у меня возникло ощущение, что STM8 туда прикручивали по остаточному принципу

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

[oleg110592]

YS писал(а):

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

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

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

[ARV]

GCC нынче "расширился" значительно

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

[pokk]

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

Код:

#if defined(__DEBUG__)
   void debuf_func(void);
   #define log_i(x)   printf_P(PSTR("\nLOG> " __FILE__ "\%s:%04d " # x "=%d\n"), __FUNCTION__, __LINE__, x)
#else
#define debug_func()
#define log_i(x)
#endif

[ARV]

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

[pokk]

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

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


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

[ARV]

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