Re: virtual machine efficiency

"cr88192" <cr88192@hotmail.com>
14 Jan 2005 00:40:06 -0500

          From comp.compilers

Related articles
[6 earlier articles]
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)
Re: virtual machine efficiency hannah@schlund.de (2005-01-30)
| List of all articles for this month |

From: "cr88192" <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: 14 Jan 2005 00:40:06 -0500
Organization: Compilers Central
References: 04-12-151 05-01-038
Keywords: VM, performance

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


Post a followup to this message

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