Re: Bytecode Compiler (Lars Duening)
29 Apr 2004 11:58:58 -0400

          From comp.compilers

Related articles
Bytecode Compiler (2004-04-21)
Re: Bytecode Compiler (2004-04-28)
Re: Bytecode Compiler (Nils M Holm) (2004-04-28)
Re: Bytecode Compiler (=?ISO-8859-1?Q?Cass=E9_Hugues?=) (2004-04-28)
Re: Bytecode Compiler (2004-04-28)
Re: Bytecode Compiler (2004-04-29)
Re: Bytecode Compiler (A Pietu Pohjalainen) (2004-05-02)
Re: Bytecode Compiler (Paul Robinson) (2004-05-24)
| List of all articles for this month |

From: (Lars Duening)
Newsgroups: comp.compilers
Date: 29 Apr 2004 11:58:58 -0400
Organization: Compilers Central
References: 04-04-064
Keywords: interpreter
Posted-Date: 29 Apr 2004 11:58:58 EDT

Chris Cranford <> wrote:

> But when we begin tossing in the concept of variables and strings, things
> begin to get complicated and hard to follow.

In your post you have already outlined the various basic variations on
how to implement these, so I will just add some comments.

One thing to keep in mind is that the design of a VM is influenced by
the language it is supposed to implement. A generic VM like Parrot
obviously has a design different from a more specialized VM like in DGD.

> Something has to tell the virtual machine to advance the
> stack pointer by the number of local variable storage slots that are
> needed. This again could just be a simple opcode like:
> 0000 advsp_2 // Advances the stack pointer by 2 slots. This
> // basically gives me two local variable slots.

The compiler could also determined the number of local variables needed
and annotate the bytecode program with this information out-of-line.
This can be done for a whole function at once: if at the deepest block
nesting the function needs n slots, then that is what the VM allocates -
there is no need to create/destroy variable slots just because one block
inside the function has been entered or left.

The ability to store meta-information outside the actual bytecode is a
great help in implementing a VM.

> Another option would be to assume a maximum number of slots for local
> vars like the java virtual machine does of 255.

Always allocating a fixed number of variable slots would be very
inefficient: most of the slots would go unused, and sometimes the number
wouldn't be enough.

And while I'm not an expert on the Java VM, I don't think that the Java
VM always allocates 255 variables slots - rather I think that this
number is an implementation restriction on the maximum number of local

> Then, I need to come up with a set of opcodes which permit working with memory
> pointers, right?

Depends. If the language you implement never deals with raw memory
directly (ie. its more like BASIC than like C), then your variable slots
could be structs of:

struct {
    int type; // 0: integer, 1: string, 2: generic object type
    union {
        int num;
        char * str;
        void * genObject;
    } val;

and your VM opcodes could act on this level of abstract datatypes
instead of twiddling bits by hand.

Post a followup to this message

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