Re: Stack based-Register Based (Anton Ertl)
20 Jan 2001 16:13:22 -0500

          From comp.compilers

Related articles
Stack based-Register Based (Vinoth Kumar) (2001-01-19)
Re: Stack based-Register Based (2001-01-20)
Re: Stack based-Register Based (2001-01-20)
Re: Stack based-Register Based (Roedy Green) (2001-01-26)
Re: Stack based-Register Based (2001-01-26)
Re: Stack based-Register Based (Andrew Berg) (2001-01-28)
Re: Stack based-Register Based (2001-02-01)
Re: Stack based-Register Based (Jonathan Barker) (2001-02-01)
[9 later articles]
| List of all articles for this month |

From: (Anton Ertl)
Followup-To: comp.compilers
Date: 20 Jan 2001 16:13:22 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-01-124
Keywords: Java
Posted-Date: 20 Jan 2001 16:13:21 EST

  Vinoth Kumar <> 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

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.

Followups to comp.compilers.

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.