Про VM перетерли мы достаточно мощно, -> --> и новое понимание возникло у меня. http://caxapa.ru/420583.html
http://caxapa.ru/420932.html
Идея с многоядерностью
http://caxapa.ru/420583.html красива, но не везде они есть, эти "многоядра", и, как верно заметили, какова будет реальная скорость "этой гомосятины" - это ысче щупать на практике надо.
Рассмотрим детальнее.
Вот есть Lua, и она на каких-то задачах в 20 раз медленнее plain C.
http://caxapa.ru/420385.html
Пусть у нас будет 160 Мгц Cortex-M4. Пусть в "80 Мгц" уложатся низкоуровневые задачи, обработка прерывания и проч.
80 Мгц/20=4 Мгц оставим на высокоуровневые задачи. Не так и мало, заметим. Будет такая "простенькая AVRка", только 32 битная.
Теперь осталось разобраться с небольшим объемом ОЗУ на кристалле. Относительно запросов Linux :)
Вырисовываются требования к связке язык-VM:
* эффективный менеджмент памяти и GC в духе библиотеки Colibri
http://caxapa.ru/421104.html
* байт код
* сопрограммы
* VM по своей структуре должна подразумевать быстрое перключение между потоками байткода. Чтобы не надо было куда-то спасать тонны стека и проч. А просто по необходимости вышел не несколько уровней из вызова функций и готов выполнять другой кусок байткода
* шедулинг на основе данных. Чтобы все данные имели четкий указатель на следующий "обработчик в цепочке". Условно: пришло несколько IP пакетов - вызвали IP стек; если после IP стека у нас буфера данных сокетов превысили порог - вызвали "сопрограммы", которые эти буфера могут скушать.
По поводу эффективности. Пусть описанная VM будет не в 20, а в 30 раз медленее С - тоже терпимо, заметим. Если она будет при этом очень эффективно использовать память - оно того стоит. SDRAM "снаружи" без кеша сильно медленный.
По совокупности задач, как я понимаю, готовых VM нет. Т.е. надо рисечить заново.