ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
23 июля
103997 Топик полностью
Evgeny_CD, Архитектор (30.10.2007 23:46, просмотров: 253) ответил bialix на не знаю насчет Си и асма, но Оберон (творение незабвенного Вирта). такое умеет, Смолтолк -- тожа (там программа и данные -- это вообще база данных), Питон конечно же. не нативно, но умеет.
Да нет, совсем не глупость. Хороший интерпретируемый язык (Tcl, Lua, Python,...) умеет подключать сущности, написанные на С. Как мы уже выяснили, ошибки на низком уровне в простой RTOS исправить "на ходу" довольно проблематично (либо это будут какие-то очень специальные патчи, которые не пойдут в качестве универсального средства исправления). Это потребует неоправданного усложенния RTOS, и посему фтопку. С другой стороны, все высокоуровневые вещи, как правило, менее зависимы от RT. Отсюда и возникает достаточно простая идея - низкий уровень надо писать на С, а вот логику верхнего уровня - может, и на таком интерпретируемом языке. Это и потенциальные возможности для багов сократит (за счет высокого уровня языка, автоматической обработки ошибок и пр.), да и "перезагрузку на ходу", при сохранении низового уровня, вероятно, позволит сделать с разумными затратами. У меня нет опыта, я пока не запускал ту же Lua в реальных системах, но чует моя задница, что проигрыш по скорости там может и не на порядок будет (если не писать на Lua обработчик прерывания). А в терминах совокупной стоимости проекта (труд программеров + плата + память + быстрый проц) при средних тиражах точно бапка надвое сказала. Идеологически я понимаю, что нет никаких препятствий пустить Lua + LuaThreads под uCOS. Только надо исходники Lua чуток подправить. В общем, тема embedded интерпретируемых языков в моем понимании слабо раскрыта. Нет, есть, конечно, picBASIC для ценителей, но я говорю про взрослые языки.