ЯП с компиляцией в Си для эмбебеда

Поэтому если тебе в 2021 нужно писать на С++/других языках то лучше и проще взять дешевую Расбпери/Орандж ПИ подобную плату с АРМом и писать туда на чем хочешь, не страдая херней с платформами которым больше 20 лет.

Лучше и проще для кого/чего? Вот допустим надо тебе сделать штуковину с датчиком температуры и реле, и чтоб реле размыкало цепь по достижению такой-то температуры, и замыкало при падении до такой-то температуры (температурный гистерезис). Зачем для такой задачи брать Расбпери/Орандж ПИ, если ее отлично и с запасом решает дохлый 8-битный контроллер? Если это единичная задача, это конечно плевать, можно хоть через комп это делать, а если тебе надо пару десятков тысяч таких штук заказать, будешь под каждую брать «дешевую Расбпери/Орандж ПИ подобную плату»?

Допустим у меня есть 8 битный МК. И для него производитель или сообщество выпустили только компилятор С. Причем древнего стандарта. Но я хочу писать с классами, генериками, лямбдами итд.

Для дохлых 8-битных контроллеров нет задач, которые б требовали чего-то более продвинутого обычной сишки.

Почему дохлые? С тем для чего они придуманы, они справляются на 5+, по поводу 20-летней давности тоже не согласен, взять хотя бы stm8.

Почему дохлые? С тем для чего они придуманы, они справляются на 5+

С этим не спорю. Но для задач, которые решаемы на каких-нибудь STM32, они дохловаты уже.

factor

?!

да блин.

например берёшь plainOldC

приправляешь Json-like инициализацией структур (ака literal struct) - оверхед ограничен - 1.потерей совместимости(ну да ну да все Clike языке полностью совместимы) - 2. добавлением на этапе компиляции парсинга сахара( по факту перенос рутины с кодера на автомат разбора инициализации)

тоже самое с функциями литералами

т.е. берётся какай нибудь подСи и приправляется своими фичами.

как завещали 60-70 годов люди могущие в тюнинг компиляторов.

не все могут в arrays :(

Это потому что программисты разучились программировать. На дворе 21 век, а жирнющие МК еле ворочаются, т.к.выполняют пхп или жабку, или говнокод. А в 8ми битные вообще не могут ничо впихнуть - разучились, ЕГЭ поколение. :)

Vala - Этакий C# от гнома. Говорят прибита гвоздями к gtk.

На самом деле 4.2. Vala легко можно использовать не только без GTK, но даже без GLib и GObject. Например, вот так. Использовать Vala в embedded – это, конечно, интересное извращение, но мне интересно на это посмотреть. Genie — это та же Vala, отличается только синтаксисом.

Допустим у меня есть 8 битный МК. И для него производитель или сообщество выпустили только компилятор С. Причем древнего стандарта. Но я хочу писать с классами, генериками, лямбдами итд.

Интересно посмотреть, для чего ты там собрался всё это использовать.

есть 8 битный МК

классами, генериками, лямбдами

не должен тащить жирный рантайм, требовать malloc/free

есть осёл

должен тянуть многотонные составы с железной рудой

должен питаться придорожной травкой

Тут действительно никто не понимает что эти фичи ничего не стоят. Ладно. Я пруфану попозже.

есть 8 битный МК
классами, генериками, лямбдами
не должен тащить жирный рантайм, требовать malloc/free

есть осёл
должен тянуть многотонные составы с железной рудой
должен питаться придорожной травкой

В каком месте противаоречие? Какой-нибудь Caml или Lisp вполне бегали на таких вот комплюктерах. Или по-твоему любой современный язык для того, чтобы включить/потушить лампочку по программе, должен потреблять несколько Мб оперативы?

Тут действительно никто не понимает что эти фичи ничего не стоят. Ладно. Я пруфану попозже

Какие из «этих»? Классы в виде наследования действительно не нужны. Классы как RAII — очень даже нужны. Обобщения писать при написании самой программы не нужно, но использовать готовые библиотечные обобщения (STL, ни в коем случае не Boost) — нужно и ускоряет разработку. Недолямбды, как простой способ работы с итераторами, были даже в древнем паскале, и никаких ресурсов не занимали — вложенная функция просто получала ссылку на стэк родительской функции и расширяла его в конце своим стэком.

есть осёл
должен тянуть многотонные составы с железной рудой
должен питаться придорожной травкой

В каком месте противаоречие?

facepalm

Эмм… Это был сарказм, т.к. как по мне весь оный изврат на МК не стоит того, поэтому если есть возможность пользовать Си для МК, то большего и не надо, потенциальные риски и вред от упомянутых плюшек высоки, а выигрыш сомнителен.

МНОГОТОЧИЕ я зачем оставил ? Сарказму уже ни не читают.

эти фичи как минимум стоят NIH

или ты вкорячиваешь подмножество с++ с их хвалённым zero-фича-кост - и не паришься с документированием

или вкорячиваешь свой СсТвоимиПлюшками с нулевой ценой в рантайме и большой(в бесконечной) ценной в совместимость ибо никто кроме тебя и твоих листьев вот так сразу не могут в твой локальный СсТвоимиПлюшками

тебе ли париться в байтоэкономию? ты акционер шоли?

атд да

наследования на мк(да и ваще в целом) провалилось как реализация общедоступной практики повторного использования кода

ибо змеиное молоко/

Vala легко можно использовать не только без GTK, но даже без GLib и GObject.

И без GC, классов и библиотек. Использовать то можно - но зачем?

[quote]Впихнуть туда что-то, приличней USB-релюшки или клавиатурки/джойстика, будет проблематично.[/quote]

Ну я туда не так давно USB-to-1wire конвертер впихнул :)

Классы, дженерики и лямбды легко могут быть zero cost. То есть превращаться статически в тот же самый код, что и решение на си.

В крестах так и есть. Но живого c++ в си компилятора нету. Только через llvm

огрызок тини13

Что может быть скромнее тиньки13? Резистор?)

хотя бы gcc

Нифига себе «хотя бы» а чем он тебе плох?

не смог в эти ваши ООП и прочее

И правильно сделал: они все кукухой поехали со своими обьектами

Это я троллил автора, а то уже возмущаются.

Ну он не плох, но и не самый хороший для встроенных железок. IAR по размеру оптимизирует лучше.

Вот как раз сейчас пишу. IAR при всей своей крутости все равно надо подсказывать. Дописывать inline функциям. Еще большая в размере кода если обращается к регистрам как volatile или без него. Ирл без volatile отрицательного эффекта на код нет. Зато код прилично меньше.
Старый проект avr gcc для тиньки 13 вчера ковырял. Без указания inline gcc на 300 байт больше.
Короче нужно постоянно следить. Листинги асм кода проверять.
На stm8 с этим проще. Тупо больше флеша. И не надо софто костыли для умножения и особенно софто деления.
Видел один проект от школьника где он на тиньке использовал ... float. А потом жаловался что 1к ничего не сделаешь. Ну ну.

Видел один проект от школьника где он на тиньке использовал ... float. А потом жаловался что 1к ничего не сделаешь

Проблема даже не в 1к, а в том, что у Atmel охреневшие цены, потому она контроллеры с достаточным числом килобайт памяти продает за несколько долларов в розницу, хотя у ядра AVR 12 тыс транзисторов (а то и все 20), а это значит, что всунуть хотя бы 2 кБ флеша не составляет никакой проблемы. По-хорошему, за такие деньги я жду не меньше 4 кБ флеша.

Ну так потому я с них и ушел. Периферия слабая. Умножение не везде. Деление вообще по моему нету. Отладки нормальной нигде нету. Купил в терре 8 ногих soic и 20 ногих tssop stm8s и stm8l и собираюсь на них сделать датчики для умного дома. + покупаю вольт ампер метры и термостаты на али. Тоже на stm8. Удобно. Практически ничего паять не надо. Покажите мне еще такой мк где все готовое.
Еще гарвардская архитектура супер. Можно работать с eeprom без костылей. Я прямо экземпляры классов держу в eeprom.

Ну так потому я с них и ушел. Периферия слабая. Умножение не везде. Деление вообще по моему нету. Отладки нормальной нигде нету

Веселые истории. Ну деление мало смысла делать хардварно, потому что оно в любых раскладах будет рекурсивно-итеративно. А вот с какого перепуга она вырезали умножение — вообще не выкупаю. Это же единицы тысяч транзисторов. У ARM в девяностых не было аппаратного умножения, потому что ARM всегда был 32-битной платформой, а тут 8 бит.

Купил в терре 8 ногих soic и 20 ногих tssop stm8s и stm8l и собираюсь на них сделать датчики для умного дома. + покупаю вольт ампер метры и термостаты на али. Тоже на stm8. Удобно. Практически ничего паять не надо

STM32 стоит практически те же деньги, при этом будет пожирнее.

Еще гарвардская архитектура супер. Можно работать с eeprom без костылей. Я прямо экземпляры классов держу в eeprom

А сейчас везде Гарвард. Фон Нейман остался только у школьных училок, которые преподают MS DOS и турбо паскаль школьникам.

Про жирность рантайма не знаю.

Там нет рантайма. Там самодостаточный си код генерируется. Один бинарник только с системными зависимостями типа glibc, pthread.