Re: virtual machine efficiency

"Calum Grant" <calumg@no.onetel.spam.com> wrote in message
> 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.


yes.
maybe useful for hw, I doubt so for interpreters...


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


yes.


I typically realign slightly differently, eg:
IP=(IP+3)&(~3);
the check seems like a slight timewaster, it is imo better just to realign
and not worry about it than check and realign, as presumably the realign
would be needed in 75% of the calls anyways.


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


yes, I don't see an advantage either.


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


not sure why really.
I would guess this depends on the implementation of the interpreter, and
mine typically being unoptimized enough to where it shouldn't matter (of all
things the interpreter looks up binding dynamically).


to me though this still seems like a "splitting hairs case":
p=table[ip[1]];
vs, eg:
i=*(int *)(ip+1);


or:
ip1=(byte *)(((long)ip+4)&(~3));
i=*(int *)ip;


I personally see other strong reasons for keeping values out of
stream, with the only main detractor I can think of being that one has
to keep tract of the out of band values table...


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


imo this idea is cool, but I can imagine it being difficult to work with.
it would likely make a lot more sense, eg, if one could "packet" opcodes,
but imo this doesn't make much sense in an interpreter (it being serial and
all).


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


personally I chose something like 4, imo it makes the most sense, eg,
in the dynamicly typed and dynamically compiled case, and the case
where opcodes don't really have associated types.




I think an important point is whether one views it as more sensible to have
a generic "load" operator, or "load.i2", "load.i4", "load.f8", ...




but whatever, I may just be stupid.

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