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

По мотивам HLA High Level Assembly -> Впервые у нас упомянут --> Мануал вложен. Можно ли эту идею обобщить до уровня iASM - intermediate ASM (термин мой!) http://caxapa.ru/715480.html
https://en.wikipedia.org/wiki/High_Level_Assembly
Отчасти повторяет идеи LLVM, IR в частности https://idea.popco …-better-than-assembly/ http://www.aosabook.org/en/llvm.html Алгоритмическая оптимизация происходит в голове программиста (и в листочках на столе, а также вокруг стола, на стенах, etc). А вот низкоуровневую оптимизацию (соответствия имена-адреса, распределение регистров и проч) лучше отдать оптимизатору. Синтаксис iASM по возможности не ассемблерный, без изобилия знаков препинания - что нибудь такое гладко-приятное. К iASM прилагается некий стандарт описания аппаратуры. Чтобы единым образом описывать структуры данных, битовые поля и события (прерывания, эксепшены). Также описываются возможности MMU, MPU платформы. Если постараться, и сделать язык описания аппаратуры достаточно гибкий, ООП и все такое, то можно сделать обобщенные описания на каждый тип аппаратного устройства, которые позволят писать обобщенные дрова. Например, USB контроллер все равно базируется на базовых понятия стандарта USB. Набор регистров, битовые поля в них, логика работы встроенного DMA контроллера уникальны, но для внешней программы (за пределами драйвера) это пофиг. И привести обобщенную модель USB контроллера (несколько таких моделей - USB Device простой, USB Device продвинутый, USB Host, OTG) к конкретике чипа - это не такая уж и сложная задача. В конце iASM транслируется в асм конкретной платформы. И здесь происходит только достаточно простая оптимизация * раскладка по регистрам * учет растактовки конвейера * раскладка по особым областям памяти. Если хорошо подумать, то можно сделать трансляцию в любой ASM - от 51 до 64 битников. Зачем это надо. Я много постил, что нарисовался громадный пласт микроконтроллеров в диапазоне оптовых цен $0.3 - $1, которые имеют немного FLASH и SRAM, но при этом достаточно мощную периферию. Споры об идеальном контроллере бессмысленны, для большинства применений выбирают по соответствию периферии и задачи, при удовлетворении бюджету и требованиям по выч. мощности ядра. И было бы здорово, чтобы при наличии наработанных библиотек и заготовок на iASM можно было бы легко перескакивать с одного семейства на другое без переписывания всего заново. Относительно "так есть же С". MINI51FDE $0.76 20 TSSOP 4 FLASH 2 SRAM. LPC822M101JDH20J 16KB FLASH 4 SRAM 20TSSOP 2,500 - $0.6993 - тут ваще полный фарш - DMA, компараторы, куча интерфейсов Еще есть STM8, куча вполне интересных 51х и прочие AVR с PIC1xxx http://caxapa.ru/769558.html Ресурсов для С там хватит, но только без библиотек. Никаких сложных коммуникационных протоколов там не будет, файловых систем тоже. Будет только целевой код, который живет в голове разработчика. А этот код пофиг на чем писать, если освободить разраба от совсем уж рутины. И будет жесткий RT, который лучше кодить в ассемблерном стиле мышления, а не в С. Еще раз, я не возвращаюсь к временам холивара С <-> asm, я говорю что при 2к ОЗУ и 4к FLASH скорости разработки не так и сильно зависит от языка программирования... И в варианте мифического пока iASM были бы достигнуты все преимущества С при экономии ресурсов и 100% RT * переносимость * достаточно высокий уровень мышления * всякие симуляторы, виртуальные среды для разработки - это все ок. Критика?