Средства и методы разработки

Я тоже так очень долго думал. А теперь понял, что это большое заблуждение! Какими сущностями оперирует ОСька? * процедура переключения контекста * управление контроллером прерываний * выбор среди задач, кому передать управление, в частности, семафоры и мютексы * управление памятью * работа со всяческими mail box, streams и пр. стаффом. Вопрос - а где нам АСМ нужен? Верно, по большому счету только на переключателе контекста. Во всех остальных кусках можно обойтись чистым С. Управление контроллером прерываний- геморная штука, но формализуемая. Понятно, что переключатель контекста нажно отлаживать на реальной платформе/симуляторе. Но честно скажем, это далеко не самая сложная работа. А вот все остальное - во власти чистого С! Т.е., конечно, для работы со всяческими струтурами данных ОСька может (и, вероятно, должна) включать asm вставки, но они optional. Так вот, отладка ОСи в синтетическом порту с его полной заморозкой и доступом ко всей памяти системы - это гораздо качественнее и правильнее. !!! Никто не мешает мне в соседнем потоке с симулируемой ОСькой запустить какой-нибудь скриптовый язык, типа lua, Python, TCL, чтобы он имел доступ ко всем адресному пространству embdeedd потока, и, например, по все точки входа в Оську и выхода из нее поставить хуки, чтобы управление передавалось моему скриптовому движку. Я буду видеть, с какими параметрами ОСька вошла, с какими передала управление (и кому)! К скриптовому языку написать простенький С модуль, чтобы он шарился по памяти соседнего потока не сложно. Если при компиляции включить debug информацию, то, вероятно, адреса всех сущностей embedded потока можно выловить. Получится полный анализатор системы при каждом ее чихе. Останется тонкость, связанная с размером стека задач. Поянтно, что в силу разности платформ, в синтетике данные будут другого размера. Кое-что можно отладить в синтетике, а кое-что придется на симуляторе. Но если к этому моменту все остальное будет гарантированно отлажено, то со стеками разобраться можно.