Too bad ROM was expensive those days. If a language with a nice balance between expressiveness and performance (say Lisp, Forth, Pascal, maybe Lua or even Java) had been embedded in the machine's ROM, then many programs could contain just their core functionality. While having all the machine's capabilities easily accessible (and maybe some standard library of often-used functions).
As opposed to containing implementations of various interpreters, VMs etc, as described here (and functions that 100s of other programs implemented as well).
Or even better: a selection of languages, letting programmers pick or even mix & match for various parts of the program.
Even today "big ROM, small RAM" is common (eg. in uC's). With flash offering extra flexibility for the 'ROM' part.
But the limitations of the day made many (system) ROMs little more than a glorified boatloader + some low level I/O code. If you were lucky, with an easy to learn but slow language like (interpreted!) BASIC.
There's an interesting design point in high wattage processors. If your bytecode interpreter fits comfortably in the L1 cache, and the bytecode is denser than machine code, and the program doesn't fit in the caches, then there's potential for interpreted bytecode to outperform native code. Quirk of really fast compute paired with moderately fast memory. I can see that working particularly well if one interpreter instance executes code for multiple processes.
I'd actually argue that ROM is still expensive unless you are making a lot of units, and it's been pretty much replaced everywhere by flash which can be commoditised leading to better economies of scale as well as having the advantage that your "ROM" can be upgraded without wasting a lot of old stock.
Where hardcoded ROMs do exist in designs now, it's usually still as a glorified stage 1 bootloader, albeit now usually with signature checking as well.
As opposed to containing implementations of various interpreters, VMs etc, as described here (and functions that 100s of other programs implemented as well).
Or even better: a selection of languages, letting programmers pick or even mix & match for various parts of the program.
Even today "big ROM, small RAM" is common (eg. in uC's). With flash offering extra flexibility for the 'ROM' part.
But the limitations of the day made many (system) ROMs little more than a glorified boatloader + some low level I/O code. If you were lucky, with an easy to learn but slow language like (interpreted!) BASIC.