Сильное заявление Плевать на стандарты, мягко говоря, не рекомендуется. Особенно осестроителям.

Когда будут хотя бы 10 приложений для ОСи тогда будет не наплевать на АПИ
А когда будет загрузчик и две три либы тогда будет не наплевать на АБИ

А сейчас... кхм кхм.... начхать на них мона.

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

Даааа? Я буду рад если вы мне покажите нормальный стандарт под такую ОСь. POSIX не предлагать слишком монструозно для таких осей. miTRON -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

Сначала придется уяснить, о чем мы говорим:
Application Binary Interface

Многие признают, что scmRTOS для микропроцессоров очень неплоха, но при этом останавливает, что она написана на C++ (хотя я лично в этом не вижу никаких проблем). Так вот для понимания что к чему, напишите ее на чистом С.

Хм, а какое отношение имена функций имеют к идеологии?



Имхо, в "плюсах" очень много возможностей для генерации неявного кода, чтобы грамотно пользовать C++ в embedded надо знать язык _очень_ хорошо. Вот здравое сомнение в своем уровне владения языком и останавливает.

Насчет много, это вы погорячились. Основной генератор неявного кода - шаблоны, исключения и RTTI. В embedded реально используются только шаблоны, вот с ними надо быть внимательным, но сюрпризов там нет - все достаточно легко прогнозируется. Остальное: неявная передача this в функции-члены при вызове, все эти vtpr/vtbl и прочее - это, во-первых, мелочи, во-вторых, это не оверхед, а реализация необходимой функциональности, которую в противном случае (например, на С) пришлось бы писать руками.

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

Обратно никогда не хочется!
Став все время работать на C++ вы забываете постепенно паттерны программирования на C и вам затруднительно использовать фреймворк который нынче весь исключительно на C написан. Или сидите на двух стульях и пишите медленнее обычного и делаете больше багов.
Либо вы вообще узкий специалист и это не ваша игра.

Освоение С++ меньше всего сводится к синтаксису и объектной модели, надо иметь экосистему, как модно нынче говорить, для использования этого языка.
C++ в embedded просто неконкурентоспособен.
Т.е. написав ось на C++ вам придется писать и фреймворк и прикладные стеки на C++
А это абсолютная утопия еще в ближайшие десятилетия.
Сделать заново целиком весь embedded фреймворк способны только гиганты типа Microsoft.
Но они уже сделали ставку на C# и .NET.
А нишу малых RTOS они занимают micro framework у которого HAL уровень на том же C написан.

Ну, это смотря насколько в C++ углубиться. Идеи в ++ есть, немало, и среди них есть даже полезные. Я, например, довольно часто использую сам объектный подход - неважно, что функции обычные С-шные и изолирование методов и данных производится примитивно вручную на уровне файлов и операторов static. Да, нет перегрузки, наследования и прочего, но проект в целом видится яснее.

Имхо, при желании вполне можно подружить C++ приложение и C-framework. Придется поработать, не без этого, но - возможно. Меня скорее напрягает вероятная проблема с компиляторами - спектр применяемых архитектур широкий - ARM/XScale, PowerPC, X86, возможно скоро будет MIPS, маячит Nios/CortexM1. На "чистом C" как-то все пока получалось переносить без особых проблем. Но - все равно тема интересная, думаю надо таки ++ попробовать - на каком-то ограниченном проекте (и, кстати, на сишном фреймворке), только бы вот время на это все найти . Паттерны вряд ли забудутся - я любитель частенько смотреть в ассемблерный листинг.

IMXO, у С++ наиболее полезные вещи -это наследование и возможность создания полнофункциональных собственных типов-расширений языка (перегрузка операторов и т.д.).
В моей практике для embedded эти возможности требовались очень редко и поэтому С++ я использую только для программирования на PС под Windows, a для embedded - только С (по принципу KISS)

Кстати, при переходе от С к С++ и наоборот бывает весьма трудно переключиться с одного стиля программирования на
другой

В таких ОСях думаю, что вводить специальный формат вызова не целесообразно. То есть как передавать параметры из функции в функцию из приложения в ядро, должен решать компилятор.

Никаких int 80h как в Menuet или Linux с регистрами и прочее -> ведёт к сильной привязке к архитектуре, да и зачаем оно? лишняя головная боль.

И ещё о Си ++. Незнаю почему но даже в Windows системные вызовы и прочее оно основано на Си (хотя создатели позиционируют свою систему как Объектно-Ориентированнцю, где есть про крайней мерее графические объекты, которые должны быть подчинены логике ООП)

Так вот, из всего что я знаю, так говорят, что BeOS -- объектно ориентирована и scrmRTOS. BeOs не видел, а вот последняя надо сказать очень элегантна сделана.


Жаль что это единственное исключение из правил.

Компилятор все решить не может, некоторые вещи придется сделать самому в соответствии с ABI.

Простой прнимер: стандарт ARM ATPCS требует выравнивать стек при вызове функции по границе двух слов. Автор FreeRTOS на это требование забил, в результате мы имеем глючащие библиотеки плавучки на некоторых компиляторах.

Хм, а что ему мешает это выравнивать, что нельзя в файле port.c забить проверку стека при инициализации (если не делиться адрес на 8 то убавлять ещё 4 байта в стек поинтере?)?
А далее уже дело компилятора!

Или что? тут не поможет данное решение????????

Или далее компилятор уже не выравнивает?

"некоторые вещи придется сделать самому в соответствии с ABI."
Ну конечно к ним относиться стековые веши, согласен!!! Ясень пень что стек инициализировать надо в соотвесвии с ABI, но что тут определяться то?
Сама то ОС, главная часть то бишь! она каким тут боком?

Почему надо думать об ABI, зачем создавать какой то свой интерфейс вызовов, почему тупо не следовать уже написанному и то только в портируемой части? вот что я не пойму?Как? простите инициализация стека корреным образом влияет на ОС?

Поможет, конечно, хотя лажа на самом деле в tasks.c:

Помимо направления роста стека (portSTACK_GROWTH) должен быть еще один параметр, определяющий пре- или постдекремент при стековых операциях.


Да кто Вас призывает придумывать свой интерфейс вызовов? Как раз и нужно следовать существующему. Просто при создании ОС нужно учитывать все многообразие архитектур, а не забивать жестко направление того же стека.