в случая няма голямо значение
аз обработвам ARM инструкциите със C ... а проблема е че ARM е яко мазало ... от миналото
надграждали, напасвали ... нещо станало, същото и с документацията
ARMv7M го избрах заради:

- GCC - мултипплатформен tool, намира се по път и на път... и няма да пиша компилатор за специфичен байткод
Като го обвържа с VSCode/PlatformIO става: Инстал, Нов Проект, Компиле, Ъплоад. Пишеш на C / C++(второто ако - абстракции)

- Cortex M4 е минималния ARM способен на -fpic

- Писане на Апликация - стандартно C/C++ (не му пречи да изпълнява Arduino код, заради Екосистемата) ... джави, питони, скриптове - има

Миро, ти говориш за приложения изпълнявани от хардуерното ядро
а на мен целта е да емулирам софтуерно ядро (и няколко може зависи от ресурса)
- един вид хардуерното ядро да е защитено от апликацията и да я контрлолира на максимум
емулирам без да интерпретирам "текст" <--- бави повече и иска повече ресурси

Реално, Апликацията е C/C++ (с почти цялата им сила) --> ELF --> BIN или "байткод"
Ся дали ще е байткод или машинен код е все тая, емулатора изпълнява квото декодира
Намери ли грешка - ай чупка и свети "червената ламба", но хардуера работи, не е забил ...
ако има мрежа вероятно може да се ъпдейтне лесно по въздуха

BIN-а / Апликацията е малка по размер, мога и да API-рам много stdlib функции, така или иначе ги има в кернела

Наистина в момента не мога да говоря за ползи докато не изтествам всички инструкции
Загубите са - скорост... но Java & Python вероятно ще са по-бавни от емулацията

Androida така работи ... някаква апликация, за която е безразличен процесора на който работи

Основната идея при мен е: Апликация да работи на всевъзможни MCU
в момента работи на PC, след малко време СЪЩАТА тази апликация ще работи на ESP32 & PIC32MZ
Написана на C/C++ .... и компилирана с GCC

Зависи от интерпретатор и от интерпретираното. Някои "интерпретатори" се държат като компилатори. Всъщност и ти може да направиш абсолютно същото. Демек вместо да декодираш всеки път всяка инструкция, просто да е заместваш с код.
Това се прави еднократно при зареждане и след това имаш практически само нейтив код.
Предимството на текста е:
1) Доста по-лесен за компилация и/или интерпретация. Ти ако искаш да компилираш ще изпаднеш в ужас да преизчисляваш преходи, офсети ала-бала. Ако не компилираш, пък има декодиране пак казвам на всяка инструкция и всяко нейно изпълнение.
2) Компилацията на текста не раздува размера. В общия случай в текста имаш командички, в компилирания имаш call-ве. При теб 2 байтова инструкция на АРМ, ако трябва да я заместиш с код на MIPS или друга архитектура и ако имаш всички проверки ще стане оле-мале. Ти предполагам не ползваш транс-компилация, а декодираш но пак казвам това забавя.
3) Текстът е на много, много по-високо ниво от една машинна инструкция. И даже и да го декодираш run time, след това изпълняваш нейтив код. Дори и прости неща като "if", "for()" и т.н. ги изпълняваш найтив. При теб ще са поредица от няколко инструкции, всяка от която декодираш и т.н. При по-сложни неща, както да кажем питона има обработки на матрици и тем подобни, там ще ти бие отвсякъде. Нямаш никакъв шанс.

Тъй де, казвам си просто мнението. Направи го, тествай... може пък и да не е толкова зле, колкото аз си мисля

GCC !!! се грижи за това ... и не само

Миро бря, използвам 90% готова, безплатна и мултиплатформена технология - C/C++, GCC, -fPIC
само въпрос на реализация - ARM емулатор - декодиране и изпълнение на машинен код ( aka байткод )

Интересното е, че никой до сега не се сетил за C2ME
( поне аз не знам )
жаби, змии, луа/муа... интерпретация - бавно и ресурс

кода на ТЕСТ Апликацията ( GCC компилирана до BIN )
която трябва да се изпълнява на различни архитектури MCU
( бинарния файл без никаква промяна )



заради софт флоат printf() бина е 15к и RAM стек 1к

Ако това приложение можеш да го емулираш на N на брой платформи, то броят на платформите за които може да се компилира е N+M.
Демек няма платформа на която ще може да го емулираш, а няма да можеш да го компилираш. Обратното очевадно не е вярно.
Това, че емулацията ще забави поне 10 пъти изпълнението е без всякакво съмнение.
Аргументите, че ще постигнеш по-висока надеждност и сигурност са далеч от реалността. Сигурност не се постига така.

С две думи вкарваш една стъпка в процеса, която има сигурни недостатъци и нито едно предимство. Това е моето мнение, с което не искам да те разубеждавам. Може да пропускам нещо. И дори да не пропускам, всички ние често правим глупости по една или друга причина. Ето примерно последната глупост, която аз съчиних беше да модифицирам Лемпел-Зив алгоритъма да не ползва RAM. Голяма простотия. Идеята на алгоритъма е да работи с памет, а аз просто го скопих... Единственото ми оправдание е, че поне в тоя случай ме принудиха. Но има простотии, които съм правел и без някой да ме кара

Миро - по твоята логика Андроид / Java / Python / WebAssembly и подобни не трябва да съществуват
Първите две директно емулират байткод, Питона и той може
при мен машинния код се явява същия байткод като при горните само, че e писан и компилиран от C/С++
... които горните също са над 10 пъти по-бавни от хардуерното ядро, което ги контролира на "макс"

за платформите - достатъчно е да може апликацията да се компилира на Win/Lin/Mac ( GCC за М4 го може)
а емулатора, да се изпълнява на Win/Lin/Mac (за симулация) и STM32 / ESP32 / PIC32 / RISC-V - това е достатъчно

Ся, аз не гоня приложение управляващо ядрен реактор или варела на Мъск ...
и на 10 мипса да цъка ( при хардуер MCU на 200MHz ) има приложения и то много...

Не съм много вещ в материята, но от моята "камбанария" (която не е много висока) целта на новите езици и технологии за програмиране е да може всеки хванат от гората (а на последък и AI) да може да пише приложения, които да могат да вървят на всичко и под всякакви ОС-ове. Цената за всичко това е огромни по размер приложения, които вървят бавно или за да вървят бързо искат майка си и баща си като хардуер ... (За консумираната енергия от устройства с такъв софтуер въобще не отварям приказка)
За направата на такива развойни тулове и програмни езици и технологии поддържащи много видове хардуер и различни ОС-ове се изисква огромни усилия за разработване, тестване и поддръжка, при това от високо квалифициран персонал. Колкото по-сложно е едно нещо, толкова е по-ненадеждно, с повече проблеми и трудно за поддържане.

Каква всъщност е "ползата от файдата" от подобна "голяма" автоматизажия правена за да се използва от нискоквалифициран персонал и въобще ще има ли някакъв "келепир"?

Много такива големи проекти са започнати и зарязани като развитие и поддръжка, защото работата по тях в един момент става много и няма кой да я върши...

аз правя ТЕСТ ... някъде му казват R&D

Аз не съм като Миро и разни други тук - които като се почувстват "застрашени"
замръзнали в някакви теории и архаични разбирания
започват да разстягат локуми и "теореми": N+M ... демек - няма да стане !?!?

Аз не искам да става - Аз искам да се убедя, че не става...

Интересното е че никой не споменава - направи така - ще стане по-добре

- НЯМА ДА СТАНЕ !!! ... и седнал и пише - не мога да те разбера...
Какво разбирате изобщо ? Колите, Световната Икономика ... Курвите ?

Не се обиждай ... за какво да ти се обиждам бе Миро ... за "теоремите" и "локумите"

Очевидно аз разбирам от "разтягане на локуми". Разбирам, защото това съм учил и с това си изкарвам хляба последните 30-40 години. През това време съм срещал много като теб, които без теория се опитват да постигнат нещо, но никой не е успял. Всъщност има изключения, но не съм имал късмет да ги познавам лично. Например наскоро "аматьор" направи пробив при оптимизация на дърво с решения. Много интересна идея, буквално накъса шортите на много академици. Пожелавам ти да си следващия такъв самороден гений.

амии обясни ми като си учил какво точно не става от моята аматьорска идея
Ето, връщам те във времето когато си учил теорията
Това как работи

Java "текст" -> компилатор -> JAR(байткод) -> MCU -> VM(емулатор)
или
С/С++ "текст" -> GCC(ARMv7) -> ELF/BIN -> MCU -> Емулатор

или кое точно не разбра? PIC ( got / plt )?

може да обясниш на аматьорите как така Windows PC изпълни код от ARMv7-M ( Cortex M4 )

или как PIC32(в случая) изпълнява машинен код от 6502

Обясни ни как става тази магия

Смисълът да се изучават локумите е да знаеш какви локуми има, какви вкусове има и кой локум за кой вкус става.
Не случайно всяка научна статия започва с въведение, в което се посочва един или повече проблеми, какви решения съществуват до момента и какво ново решение се предлага. От там насетне се гледа само дали предложеното решение наистина решава посочените проблеми и дали е по-добро от алтернативните.
В случая джабата решава един кръг проблеми. Докато 8051 емулаторите решават коренно различни проблеми.
Между двете няма нищо общо. Фактатът че ги поставяш в една кошница означава, че не си наясно какво целиш и как ще го постигнеш.
Или поне не си го обяснил достатъчно добре тук...

Аз така и не разбрах какво не харесваш в една идея
( навярно не можеш да обясниш )

А тя идеята я предъвквам от години, просто сега дойде Музата за реализация и тестове
и щото се наложи да мисля едно PLC и възникна въпроса:
Как инджинера ще си напише Ладер логиката (нали знаеш какво е това, да не обяснявам)
и в търсене на универсален скрипт/компилатор/байткод реших да пробвам - емулация на машинен код
Ся дали ще е емулация на байткод или машинен код - то едно и също !!!
и решава същите "проблеми", които решават всички останали

1. Защо машинен код - защото GCC е безплатен, мултиплатформен и решава задачата (апликацията на инджинера) на 100%
За него има MAKE, CMAKE, SCONS ... мултиплатформени и безплатни IDE-та ... навярно и шарени графични ладери
или казано - работещи и достъпни TOOLS

2. Инжинера пише на C/C++ ( и RUST може ) ( не ти харесва С ? )
не на скриптов език - тях ги има вече !!! Жаби, Змии, Лули/Мули
Няма C виртуална машина за "малки" MCU

3. но ако емулирам ARMv7-M ( Cortex M4 ) каквото напишеш за него може да се емулира !!!
Не само Ладер логика ... софтуерно Ардуино !?! ( около 30 API calls ) - като пример за С++

4. Джигитайците много пъти ми казваха
- Не искаме нативно клиентско изпълнение на нашия хардуер. Не искаме клиента да ни бърника по хардуера
- Добре, но аз НЕ искам да пиша на Java, Python, Lua - искам С/С++
Има ли C2ME ? Open Source?

5. и тн... Разбра ли нещо?

До тука какво не ти харесва ИДЕЯТА ... от твоята "научна" гледна точка
Правил си го вече? Знаеш проблемите?
Кой от твоите локуми помогнаха в случая ?

По принцип нещата при Embedded вървят с няколко години, а понякога и повече след останалите родове програмиране по отношение на средствата и методите за разработка. При десктоп имаме Virtual Machines, QEMU, Containers (Docker, Podman, etc.) -- няма лошо да се пробва нещо подобно и за микроконтролер. Дали ще работи добре и дали ще има полза е друг въпрос. Факт е, че мегахерците и броя на ядрата дори в микроконтролерите, за добро или за лошо, постоянно расте.

Джабата като език е мислена да бъде виртуализирана. Ц/Ц++ като език е мислен да бъде компилиран.
Байткода е мислен за виртуална машина. Машинният код е правен за директно изпълнение на конкретна архитектура.
Изобщо не са едни и същи, напротив много различни са както на входа (ниво сорс код) така и на изхода (изходен код).
И не, не решават едни и същи проблеми. Ако решаваха, по-доброто решение щеше да остане, а другото да е изчезнало досега.

Относно PLC- та не разбирам с какво точно помагат емулациите или виртуализациите. Ако беше направил библиотека за ладер за Ардино или PlatformIO или за малинки или калинки или за боза или за лайнукс или джаба или Ц++, нямаше да видим тоя разговор. Защото щеше да има поне някаква връзка с PLC.
Това което правиш, обаче има толкова връзка с PLC, колкото и с CNC или произволно друго приложение. Демек няма никаква връзка, с нищо не помага за решаването на който да е проблем. Ти просто добавяш още един проблем във веригата.
То даже и като АРМ емулатор не става, защото не може да емулираш произволен АРМ код, трябва да е компилиран с PIC и т.н.