So BASIC Stamp, was a dream... I know that was popular to do some automatization on industrial machines.
> It will be much more ahead of interpreters running on MCUs (overhead of parsing alone is enough to disqualify them for production use,) but still hopelessly far behind native code.
To be clear, this is also interpreted, so it doesn't have an advantage there.
> There were MCU that were naively running Java long time ago, but all failed on the market. The idea proved non feasible
Not sure they failed for technical reasons, embedded CPUs just got fast enough and typical memory big enough to run a JIT.
To begin with, why to run JIT if you can run optimised to the limit native code?
Really no value there. The positive connotation of "web native" label is not so positive in the world of dour and severe people which "hardcore embedded developers" are.
The main limiting factor for embedded is cost. If you start from the position that you want to run something that was written in Java then there will be a selection of ways to do that. Most Java applications will require external RAM to the CPU, the lowest cost DRAM chips will be whatever is used at that time in high-volume consumer electronics, when ARM chips with Jazelle were introduced the DRAM capacity that represented this optimal price had increased by a lot from when those ARM chips were designed, increased to the point that the increased memory requirements of a JIT were no longer a problem.
WASM was made with running on regular desktop CPUs in mind. Wasm is not a truly a state machine, nor stack machine, but a horrible hybrid in between them thanks to design by committee.
Changeable locals, accessible undefineds, use of stack pointer protection technique that kills both pipelining and speculative execution. Yes, that's combined downsides of both stack and register VMs.
There were MCU that were naively running Java long time ago, but all failed on the market. The idea proved non feasible