[MUD-Dev] byte-code anyone?

[Jon Leonard]

On Mon, Feb 16, 1998 at 10:40:57AM +0000, Chris Gray wrote:
> [Jon Leonard:]
[stuff on byte codes and compiling to machine language for speed]
> :My recommendations would be more complete if I were done, but here's the
> :advice I'm giving myself:
> :
> :1) Test the virtual machine carefully starting early on, so fewer bugs need
> :  to be laboriously traced by single-stepping an interpreter.
>
> Hmm. I'd planned on testing by fire. My byte-code machine is going to be
> quite low level, so visual inspection is feasible. Also, it would be extra
> work to create an 'assembler' for it.

Maybe I should have said "test with tiny cases first".  Whenever I've
spent a long time tracking down a bug, it turns out that there's a simpler
test that would have shown me the bug if I'd been more careful.
Consequently, I test for correctness early and often.

> :2) Design so that no matter how perverse the byte codes you get fed are,
> :  you don't crash or violate security assumptions.  Going from an interpreted
> :  language to byte codes or machine code makes demonstrating correctness
> :  much harder.
>
> That would slow the system down too much. I've found, for example, that
> even having a 'default' in the byte-code case statement adds noticeable
> overhead. I have made a simple disassembler that lets me see the byte-
> code for functions. Since the only source of byte-code will be the simple
> compiler, my current view is that checking the byte-code is not needed.
> There will be some processing required to set it up for execution (linking
> to other bytecode), but I think that's about it.

That is the other option, controlling all the possible bytecode sources.
Since my design calls for (eventually) passing code between servers that
don't trust each other, I can't do that.

It's a matter of taste, efficiency, and paranoia.

I'm a little suprised that the default case slows it down a lot.  Maybe
the C compiler doesn't know to just translate it as an index into a
256-element jump table (I assume you switch() on a byte), and fill in
all the unspecified ones with the default.

> :4) Don't expect to be done soon.  A compiler can be a lot of work.
>
> Ah, but most of it is already done. I expect to be running some simple
> byte-code today. I haven't even specified all of the byte-codes yet, but
> doing things incrementally lets me cycle the design with little cost. As
> long as I have enough for at least function entry and exit, I can run things.

File that under "Jon's advice to himself", then.  This stuff is taking
me quite a while.  Maybe the fact that I keep working on other things
is at fault.

> Oh yes, AmigaOS has the 'load' and 'unload' calls, so the scheme of
> compiling via an external compiler could be made to work. The big issue
> would be resolution of references to the already-loaded code. You'd have
> to do that with a jump vector passed to the loaded code. (I did that on
> a game system on CP/M, and I also use it in my current AmigaMUD system.)

If the boundaries of your computation work out right, then you could
pass arguments through IO.  Done right, this would provide a migration
path to a distributed MUD.  One of the shared library techniques is needed
for a more typical compiled function.

Jon Leonard