|Bytecode Compiler email@example.com (2004-04-21)|
|Re: Bytecode Compiler firstname.lastname@example.org (2004-04-28)|
|Re: Bytecode Compiler email@example.com (Nils M Holm) (2004-04-28)|
|Re: Bytecode Compiler firstname.lastname@example.org (=?ISO-8859-1?Q?Cass=E9_Hugues?=) (2004-04-28)|
|Re: Bytecode Compiler RLake@oxfam.org.pe (2004-04-28)|
|Re: Bytecode Compiler email@example.com (2004-04-29)|
|Re: Bytecode Compiler firstname.lastname@example.org (A Pietu Pohjalainen) (2004-05-02)|
|Re: Bytecode Compiler Postmaster@paul.washington.dc.us (Paul Robinson) (2004-05-24)|
|From:||email@example.com (Lars Duening)|
|Date:||29 Apr 2004 11:58:58 -0400|
|Posted-Date:||29 Apr 2004 11:58:58 EDT|
Chris Cranford <firstname.lastname@example.org> 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:
int type; // 0: integer, 1: string, 2: generic object type
char * str;
void * genObject;
and your VM opcodes could act on this level of abstract datatypes
instead of twiddling bits by hand.
Return to the
Search the comp.compilers archives again.