Re: Bytecode Compiler

Chris Cranford <chris.cranford@tkdsoftware.com> 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
variables.


> 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.

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