Подумалось вдруг: а нельзя ли с помощью этих функций сделать нечто вреде кооперативной ОС?
Поискал в гугле, не нашёл подобного. Почему? Плохо искал или оно для этого не приспосабливаемо?
Спасибо.

гугли "cooperative multitasking longjump"
http://en.wikipedia.org/wiki/Setjmp.h#Coop...ve_multitasking
http://my.execpc.com/~geezer/code/setjmp.c
ссылок много

Для кооперативной - слишком шикарно выходит. Зачем там нужен полный контекст?
Вот для примочек а-ля "вытесняющая ось" на фоне общей кооперативной - это может быть.
Не всегда, правда - там, где разные указатели стеков для режимов юзер и прерывания, - не пойдет.
Но это не страшно - поскольку всё будет завязано на низкоуровневые операции, заботиться о переносимости контекстопереключателя на сабже нет смысла.

Чтобы передавать управление откуда-то из глубины вызова функций.
Для такой кооперативки стеков нужно практически как для вытеснялки.
У longjmp контекст таки немного меньше, чем полный контекст для вытеснялки, так что стеков и времени на переключение у такой коператвивки нужно меньше. Но несущественно на фоне использовани ястека самими процессами.
Поэтому я не сильно понимаю смысл таких кооперативок. Но они есть, именно на longjmp (надо таки найти в завалах у себя архив «мобильной реализации сопроцесов» из софтпанорамы года так 1993-95 — первое, что я на этом видел).

Но свелось жеж к некоей процедурке, с подавлением возможности рекурсивных вызовов? Понятно, что общий случай проигрывает, когда все вызваны ранее, а мы из последнего вызываем эту процедуру и пытаемся оттудава выкачать ну хоть одно событие. Но это маловероятно. Усилиями программистов

Что так много ОЗУ надо? и экономия невелика?




Есть ещё какие-то ограничения?

Чтоб но плодить темы спрошу тут.
Какие есть кооперативные OS для АВР и поддержкой С++?

Вы имели в виду кооперативные RTOS, реализованные на С++? Скорее всего таких нет. А поддержку С++ осуществляет не ОС, а рабочая среда (компилятор и остальное). Т.ч. ничего не мешает взять писанную на С кооперативу и писать свой код на плюсах. Если уж очень хочется, то можно и вокруг сервисов ОС понаделать плюсовых обёрток.

Не обязательно реализованные.


Да согласен


Поподались только оси, где прямо говорилось: С++ не поддерживается (например OSA).
А хотелось чтобы просто компилированись и работали с С++ .

Что мешает компилировать С код компилятором С++, учитывая, что С является подмножеством С++? Попробуйте взять рабочий пример из OSA и собрать его в С++ режиме.

Логично.
Отпугнули они меня этой фразой (может были у них какие-то основания для неё, не знаю):




Да, попытка не пытка. Попробую.



Боятся они ++:

Во, как! Директивка-то не иаровская, а авторами вставлена. Интересно, какие для этого основания? Попробуйте её закомментарить и собрать.

Точно:




Собрать пока не получается: другие ошибки лезут (поменял cpu на М128, чтоб наверняка С++ можно применять)

Да, интересно.


Может есть у них основания не согласится с фразой?

Посмотрел на ужас низкоуровневого подхода в портах осы. Подумалось - не проще ли такие микро-оси размещать в стартапах?

Строго говоря, С и С++ не 100% совместимы. Есть несколько моментов, где поведение отличается. Например, в отношении констант и перечислений - у С++ подход более здравый (это и понятно, он позже шёл, учёл недостатки), есть некоторые нюансы с объявлениями переменных, но в целом в С++ нет ничего такого, что требовало бы сборки кода строго по сишным правилам. Очень интересно узнать мотивы авторов на этот счёт.

Вообще, код ОС и пользовательский код почти ортогональны по языку. Например, можно взять ось, писанную на плюсах, и использовать со своим кодом, полностью написанным на С (конечно, придётся использовать выражения вроде object_name.function_name() при обращении к примитивам ОС, но я бы не назвал это использованием С++ в пользовательском коде). А можно наоборот взять написанную на С ось и лабать свой код на ++ вплоть до написания плюсовых обёрток над примитивами ОС. Единственным более-менее обоснованным аргументом для сознательного отказа/запрета С++ в этом случае является использование каких-то жизненно необходимых "плюшек", которые есть в С и которых нет в С++ - например, incomplete arrays.

Думаю не тот случай...
Попытался собрать проект примера в первоначальном виде (С99/AT90S4433 - эта древность ещё выпускается? Смысл делать пример на таком).
Тоже ошибки.

Так это линкер ругается на то, что не хватает библиотеки. Либо IAR надо поменять, либо МК на тот, для которого есть библиотека.

"Признаю свою вину..."
Второй раз пробовал дома, а там IAR поставлен частично (только АВР с флеш >128 кБ), так что osa тут не причём - слишком мелкий проц.

Ну, так собирается проект или нет?

Да проект собрался и под м128 тоже (но пока в С).
Сегодня-завтра попробую понять чего от неё ждать в плане быстродействия/потребления ресурсов/удобства спользования, или всёж остановится на вытесняющих (хотя для авр наверное тяжеловато) или вообще по-старинке делать без ОСей.