Vinoth Kumar <vinoth@india.ti.com> writes:> What is the motivation behind designing Java as a stack based,> when lots of processors around us are register based.

I was not involved in the design, so I can only guess:

The JVM was first implemented in an interpreter, and that has probably
influenced the design; for interpreters stack machines are a good
choice (see my posting in the "Interpreter design" thread in
comp.compilers).

Moreover, even in translation to native code for a register machine,
using a register-based virtual machine does not help: How many
registers should the virtual machine have? For most targets, you
would need to reallocate registers anyway, and you also have to
consider the interaction with instruction scheduling and other
optimizations (e.g., strength reduction and induction variable
elimination); this reallocation is just as hard as the allocation when
starting with a stack-based virtual machine.

Also, note that the JVM is a stack machine with locals, which is quite
different from a pure stack machine. The usual Java compilers use the
stack part only at the expression level, with an empty stack between
statements. A Java-compiler can allocate the most active variables
into the first locals slots, so the JVM-compiler can just map the
first locals slots to native registers (plus 2-3 native registers for
temporaries from the stack or within VM instructions). Of course,
instruction scheduling and other optimizations might make reallocation
necessary again.