Собственно, вопрос в теме топика.

Я бы по такому поводу чего-нибудь более нетрадиционного попробовал, навроде stm8 LLVM Backend
Жаль, не нужно пока..

Там последний коммит от 2011-07-10. Видимо, не вышло

С этим компилятором надо быть готовым к сюрпризам в самых неожиданных местах. Причем никак не связанным с конкретной целевой платформой. Помню, когда в 2007 использовал его для PIC18 он не умел правильно генерить константные массивы, путался в их размерах (если обьявлен один массив через [] с инициализацией 10 элементами, то и все объявленные в этом файле через [] будут иметь 10 элементов). Баг-репорт об этом провисел почти год. Баг-репорт о второй ошибке висит до сих пор - этим летом пришло уведомление, что его переместили в категорию PIC16. Месяц назад помогал коллеге с программой для x51 (казалось бы, он для них от рождения, многие программы столько вообще не живут) - там тоже поймал чудеса буквально в первый час: передача в функцию массива как массива и через указатель на первый элемент давали колоссальную разницу в коде и использовании ОЗУ. Размер переменных, объявленных с размещением по конкретному адресу, при линковке не учитывается. То есть использовать можно, но только в крайнем случае и быть готовым обходить баги.

Я с ним знаком по 51-м камням, так что в принципе к сюрпризам готов Но хотелось бы знать, работает ли в принципе с stm8. Вдруг кто-то пробовал и имеет опыт.
Эх, портировал бы кто-нибудь gcc...

Работа над ним в последнее время идёт, но фактически силами одного человека (Philipp Klaus Krause). Но он же занимается и Z80, и TLCS-900 тошибовскими... конца-краю что-то не видно.
Прикрутить к Code::Blocks с наскока не получилось, м.б. у кого-то есть опыт? (Имею в виду слепки, прошедшие regression tests).

Там от начала моего знакомства(2009 год) - automatic daily snapshots. Т.е только по логу видно, делал чувак что-либо или нет. Поэтому никакой кипучей деятельности там нету

По крайней мере, regression tests некоторые снапшоты проваливают, а некоторые - нет, следовательно, что-то меняется

А мне не лень CL посмотреть. В последние несколько месяцев работа оживилась.

Мигалка светодиодами на STM8 с помощью SDCC

а смысл ходить по граблям если есть 32F030 с бутлоадером и кошерным ARM-GCC ?
неужели экономия 0.2..0.3$ этого стоит ?

Спасибо, это радует.

Ну вот, как пример:
У 32F030 - только -40 .. +85 °; у STM8 - есть automotive исполнение.

После последних багфиксов sdcc вполне довели до более-менее нормального уровня. К сожалению, до gcc ему еще ой как далеко (производимый sdcc ассемблерный код тяжело назвать хоть немного оптимизированным), но больше никаких компиляторов под STM8 нет, увы.
Вот еще, правда, есть косяк с stm8flash: он не умеет писать EEPROM и стирать залоченные МК, приходится для этого заводить виртуалобкс с хрюнделем и стирать...
Если кому интересно, все мои велосипеды для STM8 на сосфорже компиляются sdcc и прошиваются при помощи stm8flash.

Отличная новость. Вы пользуетесь снапшотом?

Ебилд написал и установил. У меня сейчас версия 3.4.0 стоит. А в официальных репах только 2.5.0.
А вообще, надо ебилд обновить. Вроде бы в sdcc еще что-то интересное добавили...

А что именно там побагфиксили?
У меня снапшот двухмесячной давности и я как-то не вижу особых изменений в качестве выходного кода


основных претензий две:
- для того чтобы не выкидывал логику, приходится в некоторых ситуациях едва ли не половину переменных объявлять как volatile.
- в выходной hex попадают абсолютно все функции - вне зависимости используете вы их или нет, как пример - в файле filter.c две функции, реализующих фильтр: u8 Filter8(u8 *) и u16 Filter16(u16 *), так вот если использовать в проекте filter.с для вызова функции Filter8, то Filter16 так же попадёт в итоговый hex. проблема старая и давно известная, но в качестве workaround, увы, предлагается использовать дробление на файлы функций.