Details of Optimisation Table VM -Reply

[John Wood]

Before I start, a few more ideas...

Firstly, that the FIS has base object abilities.  For example, the ability to 
create and invoke objects.  This way, the various OTs can simply be objects 
(perhaps even COM or ORBs), and the p-code will simply describe optimised 
invocations on methods on individual interfaces and objects.

eg.  the p-code:

12 65 128

..could be interpreted in-context to mean:

pSystemDisplayObject->ShowChar ('A', BlueBK + GreenFG);

..the context would be encoded in the p-code as part of its reference to the 
OT, or maybe even dictated by the VM's p-coder mapping abstraction.

This way we get to build on existing technology, and perhaps even use some 
form of existing component-download technology for the non-resident OTs.

The OT object could also provide an interface, say " IFISImplementation", 
which provides a method's FIS base implementation. 

The only problem I see with this is how we produce "inline" native code, which 
is crucial to a JIT's efficient product.  It may require some extension to an 
object technology.. hmmm..   It would be nice if we could write OTs in any 
language too...

Now to continue...

>> Language Egalitarianism -- just what we need, another "ism". <g> <<

Write that down, it's a good marketing term. ;)

>> 2. The base VM instruction set and a JIT for same. This is a critical 
piece, as
translation from these codes to native are how this beast is supposed to
achieve cross-platform performance. There is an issue here, as we may need to
extend the set to have low-level support for various programming models -- we
have to decide what those extended instructions (if any) might be.  <<

I think this part is very crucial indeed.  Coming up with a set of commands 
which can model every programming model efficiently is not an easy task - it 
will need some very careful thought.  Especially when you consider languages 
such as Prolog, Smalltalk, Lisp, C++ etc.  It may even have to encapsulate 
attributes such as the linearity of program flow.

>> 3. The mapping for our first hosted language. For the sake of simplicity, I
would suggest Scheme -- it's small and useful. The Java mapping will hopefully
be salvaged from the Kaffe codebase. I'm sure a Lisp mapping would also be
among the first to be done. If someone wants to concurrently produce a VB
mapping, that's also just fine. <<

VB5.5 targets the JVM, so I don't think that both JVM AND VB are necessary.  I 
think to prove its diversity, we should attempt to implement something obscure 
too, such as Prolog.  If the VM has COM/CORBA roots, it would make a very nice 
selling point for those more obscure language gurus out there...

>> The more the merrier <<

Indeed.  Other ideas also come to mind - perhaps a TSQL VM?  Give the VM a DB 
object model and you're laughing... again, it's another diverse language 
model.

>> There are certain things we can't support and be a generic binary VM 
standard. Raw memory pointers come to mind.<<

A pointer can always be encapsulated into a templated object - then access to 
this object can be optimised via the OTVM.  That way, if the language features 
pointer arithmetic - it can have it, without compromising anything (and 
perhaps not even security - I refer you to Colusa's p-code spec - they found a 
way of using pointers in a VM without compromising security, we could do 
something similar).

>> (a safe-pointer version of C??). <<

Interesting idea, but doubt you'd find many useful projects that would compile 
with such a thing ;)

>> Perhaps the easiest way to enforce this is to restrict the VM instructions 
that
programs can execute, unless they are trusted.  Trusted programs would get
access to the instruction that allows calls outside the sandbox -- others 
would
get a runtime error for that. <<

Again, this can be a feature of the object model and the OTVM (trusted 
instructions sounds like a good idea - as long as Microsoft never write any, 
'cause nobody ever trusts what Microsoft come up with ;).

Another nice feature I kind-of mentioned previously is the implicit 
translation abilities of an OTVM.

Say you have a program written using SQL, which along with a native 
implementation has an implementation in terms of the FIS.  You can then take 
the OT for, say, Java - reverse lookup the FIS implementations of its OT - and 
using pattern matching could actually find instructions with the same 
intention that match the SQL instructions.  Thus, there is potential for 
translating from one language to another.  

This emphasises the fact that a rich and descriptive VM spec can also dual as 
a program intent encoder.  Imagine the day when you can load up someone's 
project so that it's displayed in *your* programming style, your naming 
convention, your syntax, your indenting - even your fave language.  Be nice 
wouldn't it?  Although we can theorize, I think this would be crossing too far 
over to the Intentional Programming side... but still, it will help us bring 
out the potential in our VM in many diverse ways.

Thanks,

John Wood