Re: virtual machine efficiency

"ed_davis2" <ed_davis2@yahoo.com> 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.
>
> But I've run into one of those situations where I can't figure out how
> to have both.


one is limited really.


<snip>description of problems of mixing addresses/literals with opcodes
</snip>


I once started running into this issue, along with the occurance that
mixing addresses in with bytecode is just imo bad. also, there was
the issue that 256 just seems a bit small for an opcode space, and
typical chaining approaches are imo ugly.


So, how I did it was to define the bytecode as an array of unsigned
shorts. each opcode has a layout, namely the lower 12 bits give the
opcode number and the upper 4 give the length. this is followed by
any oprands or such (up to about 30 bytes).


Now, I did not embed values directly into most opcodes, instead, I
defined another structure as a kind of out of band index table.


Keeping the table out of band has a few uses: I can put whatever in it
and not worry about type; I am a lot more free of the
compiletime/runtime issue wrt immediates; it avoids unnesessary
duplication of literals; it makes operations that can recieve
different literal types a lot more straightforward; it makes gc or
storing/transmitting code more straightforward; ...


So, pretty much all the literals in bytecode are shorts (though some
are signed, but this is a seperate issue). I divide up my bytecode
code at the function level, and more or less assumes that no single
function will exceed about 64kB (yes, jumps are short aligned, but are
limited to +-32k shorts).


similarly, my opcodes are often fairly high-level and abstract as
well, but this depends a lot on the opcode.


or such...

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