[virtmach] parrot VM?

Anton Ertl anton@mips.complang.tuwien.ac.at
Sat, 13 Jul 2002 09:45:03 +0200 (MET DST)

Chris Lattner wrote:
> > > and (b) simpler compiler?
> > Yes.  I imagine register allocation (done right) would be a significant
> > complication in the bytecode compiler.
> Although the register allocator would give much better results than simple 
> tree based heuristics used for stack machines.

What kind of results do you mean?  The register allocator may reduce
the number of VM instructions executed (although even that is not
clear, given that it might produce explicit code for spilling, whereas
spilling is implicit in stack-based code), but

- in a VM interpreter this reduction has to make up for the increased
decoding overhead of register-based instructions before gaining any

- a VM-to-native compiler will reallocate the registers anyway for
best results, specific to the number of registers etc. on the target
machine, so an earlier register allocation effort is probably wasted.

> > > Is there some other obvious reason to use a stack VM?
> One very significant drawback of stack-based VMs is that they are almost 
> impossible to do meaningful optimizations on.

Well, for some reason the architects of the Amsterdam Compiler Kit,
the MIPS compilers, and the Garden Point compilers (Queensland) chose
stack-based intermediate representations for their compilers, and
optimized them, so it cannot be that bad.

I would not use a stack-based VM for most optimizations, though, and
neither would I use a register-based VM.  VMs are for direct execution
by an interpreter, or at least as a close-to-execution representation
of a program; for most optimizations I would use data-flow graphs, SSA
and such, and these can be created from stack-based code at least as
easily as from register-based code.

- anton