C Compiler dlopen VM
Q. What is the matrix?A. The matrix is the "C compiler + dynamic linking +
fork() + etc." Virtual Machine that is spread throughout computerland.
I actually think the comparison between "The Matrix" and the C compiler Virtual Machine is a good one, albeit in a self-imposed dumbed down way. But don't worry the Tunes team is here to save the day...
Starring fare as Morpheus Shows François sitting with crossed-legs with hands pressed together praying and a feint smile with the camera swirling round him and water as Neo Shows water doing a karate move. "Yaaa!"
A Virtual Machine is any agreed upon standard which gives a consistent interface to using software on different hardware platforms or software in different contexts. A Virtual Machine hopefully should be able to express the semantics of a computing system in a way that is capable of expressing problems and solution with semantics relevant to the domain of the problem (or actually any problem that computers might be called upon to deal with including dealing with themselves) rather than semantics only relevant to technical worries. The current most universally available VM is the C compiler, linker and dynamic linking etc. It is poor at incremental staged evaluation. It has no support whatsoever for migration or orthogonal persistence. (Note that orthogonal persistence is a kind of migration. -- MaD70) Lacking these it makes it so hard that it becomes unusual for anyone to want to use a computer more naturally. That is, do some work (in terms of the already established problem domain semantics) then walk away, trusting in the system to handle the rest. The main fault in thinking is to, like C VM does, impose artificial barriers between 'programming' and 'using' computers.
I don't want to write any more code in C/C++. Did you ever get the point when you learnt C? No because there is no point. C/C++ code should be written by a computer. Its true, your instincts are right. Every time you write some C identifier down your keystrokes are forever lost in the ether.
But for projects I am doing which have an expedient need I still need to be able to interface and use with current software written in C/C++ (which is a lot) including some commercial. Because the "C/C++ compiler + dynamic linking + fork()" is the most universally available/used Virtual Machine for current software. (For SGI graphics machines less and less free software supports IRIX).
As well as being universally available it is the standard in terms of speed (of course). That is, for any machine with a C compiler the speed at which certain raw numeric operations are done for that machine with that C compiler is considered to be the "speed of the machine", and this is available to anyone who knows C without writing a native compiler for each individual machine. For real-time software you often need it to be running at this speed, after a possible process of deliberation (staged evaluation).
But I also want a program which you don't need to quit, you just keep on adding and adding new instructions to it and changing existing ones. This is not usually the philosophy for UNIX/C which uses sockets or pipes and new programs communicating via them as part of the VM instead (which is a broken idea).
So I need these things now, 'cos it would be doable and fun. Sort of like beating the UNIX/C system at its own game. My solution to my own problems so far... with thanks to help from water (in the December 2003 Tunes mailing list Not sure: "real-time constrains for tunes migration"? -- MaD70).
Use a HLL with macros like Lisp or Scheme to generate C/C++ code dynamically, with interfaces to existing C/C++ code. The semantics of the macros will be suitable for me (humans) to understand for whatever their problem domain (eg. certain numeric operations).
Use C/C++ compilers dynamically called from Lisp to compile the generated code. So the C compiler is part of the Virtual Machine. Run a master process which starts up other processes to run the code and co-ordinate exchanges via shared memory or sockets. It is actually possible to do dynamic code generation on UNIX (or Win32) providing you are willing to treat UNIX as a dumb slave and do the rest of the module system yourself. Using dlopen() or dlclose() on UNIX one can use freshly compiled code from an existing process. Could be sub-masters etc.
MACISTE does that, and so does Goo. Well, to a point; no management of subprocesses fault containment for untrusted libraries. -- Faré
The point of this is to act like a glue between various components such as scene graph, Oracle database, specifically for me for virtual reality apps.
Seeing as how universal the C VM is, I surprisingly haven't been able to find much stuff on generating C code from a customizable language such as Lisp (I don't mean compiling Lisp to C like ECL does, I mean a library to generate C). But that's ok I'll start off with specific stuff that I need in fact I might start with the dynamic linking part and just have C embbeded in Lisp code.
-- codeburnt
Keep us informed about your progress on this front. -- MaD70
Further discussions on pocketpc thoughts
This page is linked from: Virtual Machines