Quirks UVM
(Universal Virtual Machine)

Goals

1. It should allow me to send some procedure or an objects to another system and execute it there.

2. The speed of execution after JIT should be no less fast than a native code execution can be.

3. It should allow me to use different languages for writing such code, and more, not just different languages but different paradigms. It should allow me to use:

   1. A classical procedure and type approach (Ada).

   2. A logical approach, as in Mercury and Prolog.

   3. A functional approach, as in Lisp.

   4. A mathematical data types approach, as in Octave, for example.

   5. An object approach (SmallTalk + Java + Ada-95 + C++).

   6. An event approach (event-driven systems).

   7. A generic procedures ( STL (C++), SGL (Ada) ).

   8. Type less interpreters approach.

   9. Even more.

   Each of this approaches can be realized by another, but it is no good way because of the goal with number 2.

   I am sure, that we may not demand from anybody to use only one language and all languages and approaches have strong and weak sides. So, I am interesting in a common execution model, not a language.

   There is one more reason. Various systems may be written on different languages. Now we have CORBA and IDL as a tools which allow multi-architecture/multi-language systems to work, but it doesn't allow to transmit a behavior (procedures) together with a data.

   Let's name this goal as "first democratic goal".

4. It should allow interpretation of a code, not just a JIT. Any system should be suitable for a code execution - not just those for which a JIT is written ("second democratic goal").

5. The processor design is changing. The most VMs are oriented on the stack approach, but today we already have post RISC architecture and a few people may predict what we will have tomorrow. For me, it is more practical to describe operations and relations in some general terms rather then in terms of some artificial anachronistic machines especially in a case when it works as an emulator.

6. The UVM should operate on types with a complex structure. The way of Java is not suitable for me because of 2 and 3. On the other hand the data has different representation not just in different languages, but on different platforms also. Moreover, future or some special processors can operate with some special data some special way (for example, it can process bit fields, matrix or unlimited integers). I need a mechanism to pass a descriptor of any data together with a code and a receiver should find the best method of operate with this the data.

   The 5th and 6th goals are very similar (5th about an "operations democratic" and 6th about "data representation" democratic). Let's name they as a "third democratic goal". This goal not only about processors but about generic programming also. (We can pass different data descriptors in one procedure and have different results).

7. If I get some procedure and start it by VM I must be sure that it hasn't any side effect and I can predict the behavior by examining a call specification. It is main security goal (<NB> I have both democratic and security goals in my project!). I've started with that stuff but now I have a think to make a virtual code verifiable in different meanings.

8. It should be free. (May be it is "4th democratic goal").

9. It should be easy to use. Somebody should have a possibility to link the Quirks as a program library, load and start any procedures. It shouldn't realize multi thread, task management and so on (by the first, it will break the goals 1, 2, 3 and 4- the first problem that multi threaded code is system-dependent). The multi thread can be realized by starting UVM in many threads - and for it we should have some "Universal Parallel Architecture" (if we like it). (I don't name it as 5th democratic goal but somebody can).