[virtmach] Test, Hello

[David Rush]

thaddaeus.frogley@creaturelabs.com writes:
> Yes, I'm going to be doing that.  I'll have a think about the hufman
> encoding, but I don't think it would be fast enough.  My current plan is to
> have a look up table for the op-code implementations, something like this:

I don't mean huffman coding in the sense of bit-twiddling &cet. All
that means is that you code the frequent instructions in one byte and
less frequent instructions in multi-bytes. It's still *a* huffman
coding in that your making your re-encoding your N opcodes in order to
get a more optimal storage size.

But you still have to do the frequency analysis. You take your
compiler's generated code based on a flat encoding of opcodes and
perform the usual analysis. Then you re-code the compiler back-end
(hopefully it was done parametrically enough so that this isn't hard)
to emit new opcodes which will give you a smaller image file
footprint.

You can also optimize your instruction set by instrumenting your VM in
various ways to find frequently used instruction sequences. You need
to instrument the VM (rather than doing a static analysis of the
bytecode) because you don't know which instruction sequences will get
hit without real run-time data. I've seen this done in several
open-source VMs, but I've never done it myself so I can't give you a
lot of pointers on precisely *how* to instrument the VM, but it is
certainly a clever way to find non-obvious speedups in a VM based
language system.

david rush
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS d? s-: a C++$ ULSAH+++$ P+(---) L++ E+++ W+(--) N++ K w(---) O++@
PS+++(--) PE(++) Y+ PGP !tv b+++ DI++ D+(--) e*(+++>+++) h---- r+++
z++++
-----END GEEK CODE BLOCK-----