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

ЯВУ -> байткод -> C код. Интересно, что за велосипед я сейчас изобрету. Навеяно -> http://caxapa.ru/369495.html
Пусть есть ЯВУ. Кошерный. Пусть есть компилер ЯВУ -> байткод. Пусть есть байткод. Пусть: • Компилер транслирует ЯВУ-> байткод изоморфно (с точки зрения решения задачи), и это формально доказано [помечтаем] • Байткод удобен для последующей машинной обработки. Удобство человека никго не волнует. Пусть есть VM для исполнения байткода. Интерпретатор. Умеренно быстрая, главное - надежная. Пусть дебагер, который менеджирует VM и позволяет натянуть исходник во все щели. + дополнительная инфраструктура. Например, полностью автоматический генератор тестов, гарантированно покрывающих весь код, в купе с профайлером. Пусть будет компилер байт-код -> С код. Опять же, пусть изоморфность такой трансляции будет формально доказана. Пусть будет ОСька – простая. uCOS или еще проще. Никаких TCP-IP, USB и прочее. Потоки, семафоры и прочая стандартная классика. POSIX по полной программе НЕ нужен. Пусть будет newlib – С либа, экономная по ресурсам и реентерабельная. Чтобы код зря не плодить. [хоть что-то есть их моих фантазий] Пусть будут какие-то вычислительно-специфические или железно-специфические куски C кода. Чтобы быстро считать и дрочить специфическое железо. Эти модули имеют специальный файлы-описания, который описывают, как их собирать, что они экспортируют и проч. И пусть будет система сборки, которая позволяет со всем этим взлететь. Она собирает OS, newlib, custom code, C code from byte-code и startup code. + еще что надо. Что мы имеем в итоге? Быстрое и железно-специфическое пишется на С традиционным образом. Никто не пишет на С IP, SSL, WEB сервер и проч. ОСей полно всяких разных, не обсуждаем и велосипед не изобретаем. Сложное пишется на правильном ЯВУ, тщательно отлаживается, и этот С код (сгенеренный как описано выше) либо весь работает, либо весь не работает. Никто его через JTAG не отлаживает. RT характеристики ОСи не ухудшаем. Сложнейший синтезированный С код для нее – просто одна из задач. С код из байткода не раскрывает know-how и его можно GPLить :) ЧТО ЗДЕСЬ НЕ ТАК??? Ибо я не верю, что это я только что придумал. Тогда почему так не делают? Или не говорят, что делают? Аппаратная релизация этого чуда – это новое поколение микроконтроллеров. 2M FLASH | 128k SRAM. Скоро будет 4M|512K, так что проблем с набортными ресурсами не будет – если только лялих не поднимать. За счет отказа от тяжеленных ОСей можно нехило сэкономить на ресурсах. + Своп в SDRAM – при правильном шедулинге позволит снять все ограничения по ОЗУ. ЧТО НЕ ТАК В ЭТОЙ ИДЕЕ? Что касается «переписать с нуля» тот же IP, то я так скажу. Берем четырех человек. 1) Берет RFC и форматирует их в некую удобную БД. Со ссылками проч. Т.е. если одна часть RFC заменена другой частью RFC – там это все видно. 2) Пишет код на ЯВУ в той же БД. И ставит ссылки – вот эта строка – к этому параграфу. + удобная АВТОМАТИЧЕСКАЯ рисовалка КА, блочных диаграмм и проч из кода на ЯВУ. 3) Пишет тоже самое, только код test suite. Пишет, генерит встроенными средствами IDE ЯВУ – сейчас не важно. 4) Прогоняет тесты, анализирует доки и результат. Пишет резюме для первых трех :) Конечно, если взять uIP, то первый сокет откроется гораздо быстрее. Но если пройти этот путь раз – то потом это можно будет неспеша докручивать до бесконечности, и адаптировать для любого проекта. ЧТО НЕ ТАК В ЭТОЙ ИДЕЕ?