[virtmach] Your VM

[Thomas Fjellstrom]

Mickaël Pointier wrote:
> 
> > > > So, why do you think VM with it's own code was a better implementation
> > > > option for Creatures than say interpreter, or encoding behaviour of
> your
> > > > objects over some domain-specific library? ;-)
> > >
> > > Hum.
> > > What is the difference between a VM and an interpreter ? For me a VM
> > > is a "byte code interpreter", so I do not understand the distinction.
> >
> > Hmmm... In my mind a VM is is a much lower abstraction than an
> > interpreter.
> > like SNES9X is a VM and perl is an interpreter. If the VM/interpreter's
> > ops can be easily translated to silicon then its a VM, otherwise
> > its an interpreter...
> 
> Ok, looks reasonable.
> 
> I would like to have the oppinion of everybody around here about what
> would be the "ideal" design of this kind of system for a game.
> Typically, games run on a large kind of various hardwares (from PC that
> have powerfull processors and caches to some game consoles that have
> almost no cache and very slow random access memory (but have fast
> DMA and linear access)), on various operating systems, with variables
> number of registers, and so on...
> 
> A lot of people in the game industry think that doing most of the game
> logic using scripting of any kind is bad, because it's very slow at run
> time.
> 
> I personaly think that if the interpreter is well coded, if the design of
> the
> language is between CISC and RISC (to avoid having to much instructions
> that will trash the cache, or too few instructions that would result in the
> need to execute a lot of micro instructions), then it would be possible to
> have decent execution speed, thus having the advantage of having a data
> driven game => possible to update game logic without having to recompile
> the core engine code, and a light weight game engine due to the fact that
> the game logic is in the script, ...
> 
> I wonder what are the most often used methods to execute binarised code
> at run time: State machines, large switch case statement, memory alligned
> data, or byte packed informations... how the coupling between scripting and
> core engine functionality is done, how storing variables, communication
> between scripts, and so on.

My VM uses a large switch case statement and decodes 'byte packed'
binary code.

> I already have some experience with all that, but I would like to have other
> people view on that subject.
> 

I know you asked for every body elses ideas but the VM that
I made seems slow to me when thinking of the average number
of instructions per second that my VM does (600,000-800,000) but
after writing a small graphics demo (blits, putpixles,
textout, clear_to_color) it turns out that the VM is more
than fast enough to do what I need. It only has 46 instructions
(so far), 36 (32bit) general registers where each byte, and
short (16bit) can be individualy accessed, a stack pointer
register, a RET (return value, for functions) register,
native code can be called from the VM,
and VM code can be called by native code.
This VM is one that I'll be using in a game I've
been planning, it will also be running code generated
by a higher level language compiler that I'm close
to completing. I do belive It will be fast enough.

Now I have a question: does any one know for sure
if an array of function pointers is faster than
a switch case? I know threaded code is faster but
is an function pointer array? (will it help the
cpu cache enough to make a difference?)

-- 
"Computer programmers don't byte, they nybble a bit."
Thomas Fjellstrom
tfjellstrom@home.com
http://strangesoft.net/