Re: virtual machine efficiency

"Chris Dollin" <kers@hpl.hp.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.
>
> (snips)
>
> The last VM I built didn't allow you to embed large values into the
> opcode stream. Instead each procedure had an associated constant
> table, and you referred to large values by their index in the table.


similar to mine.


> Normally for loading big constants there was an eight-bit index field
> (all instructions were 16 bits wide, with a 5+3 opcode, where the 3
> bits might be an additional immediate value, or a sub-opcode), but
> there was provision for handling the contextually-rare cases where
> there were more than 256 big constants.


my opcodes are based on words, though a little different:
6.10: length, opcode.
followed by any indices or addresses.


though in most cases optional, sometimes the length field has relevance...


> 16-bit instructions turned out to be an interesting and occasionally
> frustrating choice, as was the decision to try and combine stack-based
> and register-aka-local-variable instructions. That the machine had
> *two* stacks [1] - one for values, one for locals/return addresses - was
> an automatic consequence of umpteen years writing Pop11 (and similar)
> code.


mine also has two stacks:
the value stack;
and a kind of opaque meta-stack used for control.


locals were stored in their own space which is indirectly referenced by the
control stack (variables and similar are accessed with their own opcodes).




I like my approach personally (if albeit it uses a little extra space
sometimes).

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