Re: Bytecode Compiler

lars@bearnip.com (Lars Duening)
29 Apr 2004 11:58:58 -0400

          From comp.compilers

Related articles
Bytecode Compiler chris.cranford@tkdsoftware.com (2004-04-21)
Re: Bytecode Compiler dido@imperium.ph (2004-04-28)
Re: Bytecode Compiler nmh@t3x.org (Nils M Holm) (2004-04-28)
Re: Bytecode Compiler casse@netcourrier.fr (=?ISO-8859-1?Q?Cass=E9_Hugues?=) (2004-04-28)
Re: Bytecode Compiler RLake@oxfam.org.pe (2004-04-28)
Re: Bytecode Compiler lars@bearnip.com (2004-04-29)
Re: Bytecode Compiler pohjalai@cc.helsinki.fi (A Pietu Pohjalainen) (2004-05-02)
Re: Bytecode Compiler Postmaster@paul.washington.dc.us (Paul Robinson) (2004-05-24)
| List of all articles for this month |

From: lars@bearnip.com (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 <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.


Post a followup to this message

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