[virtmach] Test, Hello

[David Rush]

thaddaeus.frogley@creaturelabs.com writes:
> I'm Thad, and I'm working on an alife based game engine for a well know
> developer, and I'm about to start work on the virtual machine ...
> this will be my first VM.  I have 1 week to come up with a design
> / schedule proposal, based on an initial estimate of a 2 months development
> cycle.

I didn't want to rain on your parade, but seeing as how no one else has...

I think that you have a difficult task. 

> Potential target platforms include PSX2, and intel PC (windows), and XBox.
> The VM should be fast, and the bytecode compact.  
> The VM must be robust, even when the scripts running on it are not.  
> It should provide hooks for a debugger, profile scripts when needed, and
> give good error messages when things go wrong.  

I think that you have an impossible task, unless your initial two
months is *really* initial; like proof-of-concept and you get to throw
it out and start over from scratch. Do you also have to design the
programming language in which scripts will be written? Do you have a
clear specificatio of the semantic requirements of the scripting
language or is it a pile of marketing hot air? Are you building the
bytecode compiler?

Depending on the complexity of the source language I would suggest
that you take at least two weeks for your instruction set/basic
architecture, and be prepared to run over budget. If you've got to
worry about things like extensibility, that will cost you
more. Do you want to dynamically link bytecode modules? Anyway,
there's a number of quick and dirty solutions that I've used to
solve a lot of these problems, but they're not terribly efficient in
terms of anything except coding time.

As far as compact bytecode goes, you're not *actually* obligated to
restrict yourself to 256 opcodes, you can huffman code you
instructions so that frequently used combinations (e.g. adding
smallint or small 2^N constants) have their own opcodes, using
multi-byte opcodes for infrequently-used (but otherwise essential)
primitives. Of course to make these estimations you're going to have
to be able to do analysis of compiled bytecodes for real programs that
will be run on your VM.

All of this takes time. Time to develop the tools and to instrument your
VM. Tell your manager you need more of it. If he doesn't believe you,
don't work *any* unpaid overtime without a quid pro quo on how you'll
be compensated for your efforts.

> All in all an interesting challenge.

I love developing languages, compilers and VMs. It's great fun, but it
is time consuming, especially when you're working out 'quantum bugs'
where you have to decide which is wrong, the language semantics, the
compiler or the VM. It also takes a fair amount of discipline to avoid
continually shoving the same shit under the different rugs that are
available.

david rush
-- 
I repeat myself when under stress. I repeat myself when under
stress. I repeat myself when under stress. I repeat myself when
under stress. I repeat myself when under stress. I repeat myself
when under stress. I repeat myself when under stress. I repeat