Re: virtual machine efficiency

Calum Grant <calumg@no.onetel.spam.com>
30 Dec 2004 22:48:02 -0500

          From comp.compilers

Related articles
virtual machine efficiency ed_davis2@yahoo.com (ed_davis2) (2004-12-29)
Re: virtual machine efficiency dido@imperium.ph (Rafael 'Dido' Sevilla) (2004-12-30)
Re: virtual machine efficiency anton@mips.complang.tuwien.ac.at (2004-12-30)
Re: virtual machine efficiency vbdis@aol.com (2004-12-30)
Re: virtual machine efficiency cr88192@hotmail.com (cr88192) (2004-12-30)
Re: virtual machine efficiency cfc@shell01.TheWorld.com (Chris F Clark) (2004-12-30)
Re: virtual machine efficiency lars@bearnip.com (2004-12-30)
Re: virtual machine efficiency calumg@no.onetel.spam.com (Calum Grant) (2004-12-30)
Re: virtual machine efficiency cr88192@hotmail.com (cr88192) (2004-12-31)
Re: virtual machine efficiency cr88192@hotmail.com (cr88192) (2004-12-31)
Re: virtual machine efficiency strohm@airmail.net (John R. Strohm) (2005-01-01)
Re: virtual machine efficiency kers@hpl.hp.com (Chris Dollin) (2005-01-12)
Re: virtual machine efficiency cr88192@hotmail.com (cr88192) (2005-01-14)
Re: virtual machine efficiency kers@hpl.hp.com (Chris Dollin) (2005-01-15)
[1 later articles]
| List of all articles for this month |
From: Calum Grant <calumg@no.onetel.spam.com>
Newsgroups: comp.compilers,comp.lang.misc
Date: 30 Dec 2004 22:48:02 -0500
Organization: ntl Cablemodem News Service
References: 04-12-151
Keywords: VM
Posted-Date: 30 Dec 2004 22:48:02 EST

ed_davis2 wrote:
> I have developed a simple stack based virtual machine. I would like
> it to be as efficient as possible, in terms of both speed and object
> code size. Size, as in size of the object code the VM processes
> (byte-code), and not necessarily the size of the VM.


> Is there a way I can have both fast loading of operands, and small
> byte-code size?


1) You could inserts nops before the op-code to ensure that the value
was always word-aligned. However this would be too slow since your
interpreter would need to handle the nops.


2) You could still align your data on a word-boundary. The interpreter
would notice the alignment of the op-code, and implicitly skip 0-3
bytes. The compiler would need to insert appropriate padding to ensure
the correct alignment.


case OP_LD:
if(IP&3) IP = (IP&~3) + 4;
operand = *(int*)IP;


3) You could have variable-width op-codes. Have 4 load instructions
with widths 1,2,3 and 4 that align the data following the op-code. But
I don't see much advantage over 2).


case OP_LD0:
operand = *(int*)IP;
IP += 4;
...
break;
case OP_LD1:
IP ++;
operand = *(int*)IP;
IP += 4;
...
break;
case OP_LD2:
IP += 2;
operand = *(int*)IP;
IP += 4;
...
break;
case OP_LD3:
IP += 3;
operand = *(int*)IP;
IP += 4;
...
break;


4) You could store values out-of-stream. But this is slightly less
efficient.


5) (copied from Anton Ertl's post) reorder op-codes and move
word-aligned data away from its op-code.


I think in the cases of 2) and 3), although there is occasional
padding, the interpreter has much less to do than in the more complex
schemes.


Calum


Post a followup to this message

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