байткодът и машинният код са просто последователности от инструкции, които определен вид машина разбира.
Независимо дали машината е реална или виртуална
и двете са instruction sets предназначени за изпълнение.

Разликата е конвенционална, не абсолютна.

Ако създадем хардуер, който директно разбира Python байткод, тогава технически той става машинен код за тази машина
Java не е мислена да бъде "виртуална", а преносима на различни архитектури
а и много пъти са правени опити за хардуризирането на Java - CPU и ускорители(Jazelle)
вероятно и в Андроид джаджите има хардуерни ускорители

Но в аналогията ме разбра - искам приложението да се пише на С а не на Java/Python
и да използвам GCC като работеща инструментална база

PIC го използвам за да прехвана API функциите, защото GCC го прави автоматично
Ако махна PIC трябва SVC ... а и в момента подържа и двете
а и на Java компилаторите не може да кажеш - не компилирай така а те така
на Linux приложенията не можеш да махнеш fpic...

По твоята логика и Андроид ( Linux / Java(VM) ) не трябва да съществува
а дори J2ME все още съществува...

Обясних разликите в кодовете.Не знам къде видя в логиката ми, че едно или друго не трябва да съществува.
Аз твърдя, че вкарваш емулация там където такава не е необходима. С нищо не улесняваш правенето на плц, напротив усложняваш го.

последния месец съм малко ограничен откъм концентрация, но хвърлям по едно око на темата.

ако съм разбрал правилно:

- някой ти е поръчал яйца

- ти си решил, че ще е далеч по-ефективно и удобно, ако яйцата са с кубична форма

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

следващата дилема пред теб е формата на жълтъка - вписана окръжност в квадрат или по-естетичното квадрат в квадрат.
вероятно инспирирано от HORECA 'саламите' за хотели, от които се правят идеално еднакви слайсове на варени яйца.
но трябва да се има в предвид и психологическия момент - когато човек вземе вилицата и види в чинията си квадратчета вместо обичайните кръгчета, ще вдигне поне една вежда и колебливо ще пробва едно с висока доза скептицизъм. на подсъзнателно ниво няма да му дойде на ум, че яйцето е от тесарактова кокошка, а че по-скоро това в чинията е забъркано в колба от винервайс, лепило и боя.

има проблем и с черупката.
като ги редиш плътно в кашон без изолация, неминуемо ще се счупят всички яйца. и почваш да мислиш за полиетиленова 'черупка'. ама тогава в храната на кокошката трябва да добавиш и 'въглеводородни молекули', желателно демократични (GPL).

не на последно място, понеже това е нетипичен вид яйце, трябва да минеш одобрение от всички отговорни за това органи - ХЕИ, МЕИ, ДАЙ, НА, ДРЪЖ, и т.н.

в същност нямаме голяма част от заданието.
когато чуеш тропот на копита (PLC) за какво се оглеждаш - за коне или за зебри?
какво се очаква да прави това PLC във времево отношение - да пуска/спира помпа, да клати асансьор или да прави сферична интерполация?
ако е първата категория, времето за реакция е в десетките милисекунди, което обезсмисля свръх-бързото нейтив изпълнение (зебри).
ако е от втората - не му е мястото в PLC (жирафи на ивици с крилца).
не трябва и да се забравя, че оплождането на зебри от коне (и обратното) е (1) невъзможно; (2) има нетипични ефекти през поколение.

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

а ако клиента не е някакъв стартъп с авангардни безумни идеи и милиарден бюджет, и човека просто иска да си чукне две яйца в тигана сутрин?

Чак днес разбрах, на кое викат тесеракт.
И иначе темата е уж за PLC, но се чувствам като идиот, след като едва едва схващам какво се разработва и как се разработва. А защо се прави по този начин също исках да попитам, но не съм на нивото на другите питащи, поне не и в тези води.

Дедо - аз не споря на тема скорост на реакция на PLC
та и такива ( скриншота ) шестограмни яйца съществуват


колко пъти да обяснявам, че го компилирам за да махна интерпретация като обработка на текстов скрипт

В Сименс явно са в час, защото логото са го класифицирали "програмируемо реле", а не контролер. Тези времена за PLC трябва да са поне десетина пъти по-малки за над 50-60 входа/изхода, включително няколко аналогови, със съответната ариметика в програмата.

казуса ( предизвикателството ) е:
Логиката / Апликацията на клиента да няма достъп до хардуера на устройството било то PLC / HMI / LTE ... etc
Да не може да забие хардуера ако има грешка в апликацията, да може да се update лесно ако се наложи
Да не е скриптов Интерпретатор, защото иска повече ресурси и е още по-бавен от Емулатор на байткод ... и др.

и общо взето това е цялата Клиентска част ( за Апликация ) - Компилатор + IDE
клик - Install / New Project / Compile
( липсва Upload / Debug ... за сега )

https://github.com/Wiz-IO/c2me

пример ( скриншот ):
https://github.com/Wiz-IO/c2me/blob/mai ... src/main.c

Зебрите ги подгониха Еднорозите...
или
Квадратните яйца започнаха да се търкалят по нанадолнището

и щото не повярвах на локумите на Миро и Дедо
разпитах няколко Изкуствени Идиота ( няколко, за повече статистическа достоверност )

Единствения проблем е производителността, която реално трябва да бъде по-висока от microPython, JavaScript и Lua
J2ME не съществува вече за сравнение, а Embedded JavaScript и Lua са само интерпретатори - демек още по-бавни
microPython няма JIT компилатор така, че си остава 90% интерпретатор + 10% емулатор на байткод
Може да ме бие с обектна абстрактност, но тя ще бъде достатъчно бавна аха и на кантар със С++ (ака Ардуино, чист С++ е труден на малко MCU)

Ся, байткода е оптимизиран за емулация - байт инструкция(просто декодиране) и байтове данни
обаче microPython се бави с интерпретацията и то много. Чист Python няма как да се реализира на малко MCU
а и дървовидни обекти със стек е тотално мазало за оптиизация на малко MCU и просто не съществува

За да стане "правилна" VM трябва "правилен" компилатор, но няма кой да напише С/С++ компилатор за виртуален байткод
а текушия ARM GCC е безплатен и осъвършенстван във времето,
"Икономиката" за клиентската част е загуба на половин работен ден за + IDE - клик клик compile

Машинния код (на ARM) е боза, за хардуерно декодиране е един такт, но за софтуерно декодиране - са няколко шифта и OR ... и бави
Тъй, байткодовите VM нямат PC - програмата върви линейно само надолу,
докато машинния код скача по адреси - но при емулация това не е проблем.

JIT ... ако Миро знае какво е това, не може да се реализира на малко MCU, демек microPython губи по точки и производителност
а при ARM емулатора фактически половината код е прекомпилиран сякаш JIT
и с малко трикове - много от стратегическите функции са API към хардуерното бързо ядро (пример: libc, перифеия, сокети... )

sandbox изолиране на хардуера от клиентската апликация да го обяснявам ли?
и още други, но ме мързи да пиша... (или да обяснявам)

Аааа естесвено, сега ще ревнат за приложение на идеята, но това не е мой проблем... а и в БГ няма производители на хардуер за идеята...
то и инвеститори няма ( освен за ТНТМ от Пловдив ) но това е друга "бира"
просто преместете темата в Безумни Идеи

PS: Дедо, стани си от топките, че си седнал на яйцата си

При PLC не гониш скорост/производителност а ПРОСТОТА, затова и всички производители на ПЛЦ освен техните си тулове за програмиране предлагат и графични редактори на Релейна Логика (ladder logic), защото и идеята на ПЛЦ е да замени големите релейни системи. Нещо много си ги омешал понятията с ембедед и ПЛЦ контрола.

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

BTW темата(идеята за емулация) от PLC я надградих до C2ME ( аналогия от J2ME )
или Апликация написана и компилирана от С/C++, изпълнявана от софтуерно ядро контролирано от хардуерното

не ми се мисли нов скриптов език за който да пиша компилатор за байткод
по лесно е да използвам GCC за ARM ( MIPS го изоставих по "икономически" причини )
а и нали ревете срещу Java/Python/Lua за ембеддед ... ето пишете на ANSI C

https://filebin.net/si9mmdzxukb0yh00

хаха - какво беше това
телевизия, радио, youtube?

Анализирана и обсъдена от ИИ тема под формата на подкаст

Уникално !!! Как точно го генерира това?