That's some solid trash talk for Wikipedia.
And the rant continue...
"allows some ARM processors to execute Java bytecode in hardware"!
It’s a really fascinating chip that reflects AT&T’s tech ambitions of the time—which flopped, hard, almost immediately after they shut down the chip’s production. If the EO situation played out differently, who knows how much bigger the Hobbit would've been.
This is an unfortunate dead end for this technology.
Couldn't the same be said of any modern CPU short of the Java processors that have mostly failed?
I distinctly remember the STRCPY opcode, which did exactly what you expected it to do.
I have fond memories of that instruction set, but looking back now it's like looking at a loaded weapon.
Coming from an embedded background, I'm wondering, could you not, for example, do a machine where you offload bulk memory operations to the memory controller itself? Copying memory, zeroing memory, moving memory around, all these things could happen at the memory controller level and you'd never need to put them on the actual bus. Perhaps there is something like this for some exotic architectures?
I'm wondering now how these processors/MCU's handle bus access since you have so many peripherals that probably want to access it as well as the CPU acceses that need to happen. Certainly you have to have a priority settling mechanism and some way of arbitrating the resource. The CPU probably doesn't use it all the time, but if you have a pipeline, it probably uses it in the background anyway.