Cheap microcontroller for JavaScript or fast interpreter.

[westfw]

Hmm.  What processor architectural features lead to faster interpreter or emulator performance?

[brucehoult]

Hmm.  What processor architectural features lead to faster interpreter or emulator performance?

Not Jazelle, as it turned out :-)

[ejeffrey]

Hmm.  What processor architectural features lead to faster interpreter or emulator performance?

It should probably look as much as possible like either amd64 or aarch64.  That is, a platform with a JIT compiler tool chain with billions of dollars of development effort behind it.

[tggzzz]

Hmm.  What processor architectural features lead to faster interpreter or emulator performance?

It should probably look as much as possible like either amd64 or aarch64.  That is, a platform with a JIT compiler tool chain with billions of dollars of development effort behind it.

JIT is the starting point, but significantly more performance is possible if you can add HotSpot style performance improvements.

NRE charges dominate

[westfw]

a platform with a JIT compiler tool chain with billions of dollars of development effort behind it.

That is not an "architecture feature."  That's just capitalizing on "prior art"!
I want to know which CPU features make it easy to write better interpreters WITHOUT that much development effort.

(Sort of like "x86 chips prove that CISC is as good or better than RISC, if only because AMD and Intel put so much effort into making it so."  (observation is from about when Apple switched to x86 from PPC, and the MIPS desktop vendors went away.  Probably less valid now...))

[hans]

If what you care is correctness, you can abstract it with JS classes, int32, int64, etc.

However, there are currently no real alternatives that offer the same ease and portability for writing browser-based applications, so we often have to work within the limitations of what's available. This is precisely why tools like Emscripten have emerged - essentially implementing a virtual machine in JavaScript that allows code written in more robust, strongly typed languages to run in the browser while leveraging the GUI capabilities available through JavaScript.

Yes, or under the hood, basically WebASM.

Its basically a custom ISA that can be run in a web browser (which yes, would have to be loaded via javascript).
Here is the list of all opcodes: https://webassembly.github.io/spec/core/appendix/index-instructions.html

You can even spin up Wasm docker containers nowadays. I think you'll have to provide it some modules/interfaces on how it can talk to the outside world, but many server backends can do a ton once it can open TCP connections and/or HTTP+SQL.
I'm sure fancy desktop Wasm runtimes will JIT your code and make it run real fast. But here are also two libraries I found that do embedded (ESP32/Cortex-m7 level): https://github.com/bytecodealliance/wasm-micro-runtime
https://github.com/wasm3/wasm3
It does use a ton of RAM though.

But, I think for most applications this is still thinking backwards. Wasm allows you to write C/C++/LLVM code and run that in a webbrowser. This bypasses all the JS type bs while still leveraging browser environments for quick results. Then if you want to test test/visualize code, you could also use the browser with Wasm module that contains code under test. When debugging is done, you integrate it into your MCU project. There would be zero need for an embedded scripting engine, zero need for code porting, as <stdint.h> should be portable.

[ejeffrey]

a platform with a JIT compiler tool chain with billions of dollars of development effort behind it.

That is not an "architecture feature."  That's just capitalizing on "prior art"!
I want to know which CPU features make it easy to write better interpreters WITHOUT that much development effort.

I don't think there is a shortcut.  Dynamic recompilation with hotspot analysis is the way to get good performance out of an interpreted language.  It's not that architecture doesn't matter at all, just that as long as you have something reasonably sane and generally high performance you are going to be able to write the code generator for it.

Trying to have the processor directly execute the interprete code, as with Bruces' comment about jazelle, is the wrong way to do it.  Maybe there are techniques that would really help, but mostly JIT compilers are compilers.  Most of the things that make compiled programs fast make JITs fast.

(Sort of like "x86 chips prove that CISC is as good or better than RISC, if only because AMD and Intel put so much effort into making it so."  (observation is from about when Apple switched to x86 from PPC, and the MIPS desktop vendors went away.  Probably less valid now...))

No that shows that when you reach a certain scale instruction decoding becomes a progressively smaller fraction of your processor.  There are still costs associated with e.g., tracking micro-ops through the pipeline so you can handle exceptions properly but once you have a super scalar processor with deep reorder buffers, register renaming, and multiple execution units, speculative execution, branch prediction and other internal caches, and so on that's where most of the effort goes.  RISC is clearly superior, but that doesn't save you all the hard work of making an actually high performance processor, at least not since the 90s.
 

[Doctorandus_P]

On a sidenote:
How good is AI these days to translate sourcecode form one computer language to another? It probably is not perfect, but I guess it will save you some time if it works reasonably well.

If the result doesn't have to work properly (i.e. only reasonably well), then I can generate it very quickly without LLMs.

The LLM thing can type a lot faster then you can. You'd still have to comb through the code and debug it, but you can skip the boring parts such as changing syntax for how a for loop looks like in that other language, sorting out where and how you declare variables and such.

[tggzzz]

On a sidenote:
How good is AI these days to translate sourcecode form one computer language to another? It probably is not perfect, but I guess it will save you some time if it works reasonably well.

If the result doesn't have to work properly (i.e. only reasonably well), then I can generate it very quickly without LLMs.

The LLM thing can type a lot faster then you can. You'd still have to comb through the code and debug it, but you can skip the boring parts such as changing syntax for how a for loop looks like in that other language, sorting out where and how you declare variables and such.

You are missing the point, in several ways.

[paulca]

Javascript is not a "thing".  It doesn't exist.  It's a "type" of thing.  There is no standard.

You can try for ECMA or TypeScript which have tighter standards, but overall "Javascript" is highly dependant on what your sandbox environment is and how exactly you choose to implement the language.

There are vast and total incompatibilities between the most common browsers.  Code for A will not run on B.  There are fundamental differents which are not code compatible.  Frame works like Angular/React et. al. include huge sections for cross compatible lower layers that are switched on a browser by browser basis.

If these didn't exist, NOBODY would be using Javascript in industry as it's a total waste of time to try and write it and expect it to run without doing your own testing across all combinations of browser and OS.

Best avoided.

Note.  On a modern "Windows" or "Linux" PC, javascript is NOT an interrupted script language.  Hasn't been for a decade or more.  It is a natively compiled and directly executed language.  Chrome, Edge etc. were subjected to the Spectre CPU cache exploit for example and you could use the exploit vector from JS.

Linux folks will have noticed Chrome and others shifting to a "jail" or "sandbox" model.  This is why.  When you visit that dodgy website their JS code is compiled and executed directly on your CPU, NOT in a VM.  So the browser itself is locked down to try and keep things sane and secure.

Do not expect the kind of speed you see on a modern desktop browser if you try and use JS on a lesser system without the native compilation.  Orders of magnitude slower.

[NorthGuy]

There are vast and total incompatibilities between the most common browsers.  Code for A will not run on B.  There are fundamental differents which are not code compatible.  Frame works like Angular/React et. al. include huge sections for cross compatible lower layers that are switched on a browser by browser basis.

It is much better now than it was 20 years ago. Of course, there are differences, but the level of compatibility in Javascript and HTML implementation is stunning. Even the browsers are running in phones. This is one of the things that really improved over the years.  Yet, the bran-dead Web developers (aka Full Stack specialists) manage to write code which works in some browsers and fail in others.

If these didn't exist, NOBODY would be using Javascript in industry as it's a total waste of time to try and write it and expect it to run without doing your own testing across all combinations of browser and OS.

Testing is mandatory anyway - you're not going to put untested code onto your site, would you? By using a subset of JavaScript/DHTML which is supported the same everywhere, you can do practically anything.

The JavaScript frameworks actually make compatibility issues worse. You may not have changed anything in your code, but the framework might have changed, or dropped support for older browser, or did something else of that sort, so now your code doesn't work, and you don't even know that. Your customers cannot watch your website any more, but this is only because your customers are bad. The bastards should've upgraded to Windows 11 with latest Chrome.