Inferno OS

lsub and octopus: http://lsub.org/ls/octopus.html

In any case, Java's stack-based bytecode is really a register machine in disguise. It isn't a general stack machine -- for instance, at a given "PC" the shape of the expression stack (i.e. the number and "basic" types of elements in it) needs to be constant.

The right way to look at Java's bytecode stream is opcodes for a register machine with _implicit_ input and output registers. Mapping it to a compiler IR would not be easy in the general case if that weren't true.

Edit: Michael Franz's research would seem to disagree, and I believe Mike Pall (of LuaJIT) would also disagree.

As I remember, the Dis bytecode used 64-bit instructions, with a 16 bit opcode, a 16-bit address and a 32-bit address. I've heard it described as a memory machine, and also as a machine with 65,536 registers.

In any case, it's easier and more efficient to perform register allocation from an intermediate language with a huge number of registers down to a small number of physical registers than it is to assign slot locations to registers. See Michael Franz's SafeTSA [1] project for an example of modifying a JVM to be able to mix and match both Java bytecode and an SSA-based bytecode in the same process. Granted SSA has some additional properties besides an infinite register set that make code generation nice. However, they found that it took less time to generate native code from SafeTSA and that the generated native code ran faster, even though the JIT backend was identical for the two bytecode formats. The disadvantage of SSA and memory machine bytecodes is they are more complicated to efficiently interpret if you're not generating native code from them.

[1] http://en.wikipedia.org/wiki/SafeTSA

That's a disingenuous - of course it makes a difference. Trying to infer an efficient allocation of registers from a chain of stack instructions involves a ton of tricks that bloat the compiler and make loading the bytecode slow and processor intensive. That's the problem Dalvik was designed to solve, and why Dalvik's successor ART is a regular compiler and not a JIT.

Sun even made Java cpu's / appliances

These days there's http://www.azulsystems.com/products/vega/overview

Bruce Ellis (one of the people who created Mark V Shaney) and one of the original Inferno developers until it was sold, has been working on a Verilog cpu to execute DIS natively but still no prototype.

One of the beauties of Inferno is it will run on a platform with no hardware MMU.

And the Styx protocol means it can do great things easily. It has even had servers running on Logo Mindstorm.