Re: [DotGNU]Register based bytecode stuff...

[Rhys Weatherley]

I've just inhaled the Parrot documentation to get a better picture
of just what it is.

It is important to distinguish between two kinds of VM's: static
and dynamic.  Here are some examples:

CLI
   - Static stack-based VM.
JVM
   - Static stack-based VM.
Internet C++ (ivm.sourceforge.net)
   - Static register-based VM.
Parrot
   - Dynamic register-based VM.

Static VM's typically use a compiler to generate the bytecode,
which is then run separately later.  They may have some ability
to generate code on the fly (e.g. Reflection.Emit), but the usual
way to use them is "compile, then run".

Dynamic VM's typically use an integrated approach where the
compiler, interpreter, and library are all part of the one system.
Source code is fed into the system, which compiles it to some
intermediate form which is then interpreted, JIT'ed, or whatever.
External bytecode files may be loadable (e.g. Python's .pyc files),
but it isn't the primary execution model.

It isn't really correct to say "for register-based stuff, we will
use Parrot".  Parrot would be highly unsuitable for doing what
Internet C++ can do, for example.  And that's a register machine.
It is more correct to say "for languages requiring a dynamic VM,
we will use Parrot".

In the context of pnet, adding a new static VM would involve
hacking into the C parts of the pnet engine and adding the new
bytecode format directly.  e.g. what Gopal has been investigating
for the JVM.  Internet C++ would be similar.

Adding a new dynamic VM would involve writing a library of
C# classes that load the input code and dynamically translate
it into IL using Reflection.Emit.  Then the underlying static
VM would take over to JIT and execute it.