Details of Optimisation Table VM -Reply
Thu, 8 May 97 03:27:15 UT
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
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
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
>> 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
>> (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
programs can execute, unless they are trusted. Trusted programs would get
access to the instruction that allows calls outside the sandbox -- others
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.