a Strange Inversion

catch(e) " href="http://1.bp.blogspot.com/_XCDTVvEbBMU/SiU4lGL5Z5I/AAAAAAAAACo/h2VqfN3wD4A/s1600-h/inversion.png">
If you at the correlation between programming languages and their underlying virtual machine, you will find a strange inversion of the more typical abstraction pyramid. For example, if you look at Ometa/Squeak2, you'd see a correlation pyramid that looks like the one on the right.

At the basic layer is the virtual machine that the hardware's instruction set implements. As many performance conscious hardware designers have moved their architectures forward, it has been necessary to implement virtual machines at the hardware level to retain backwards compatibility with previous chips.

The next layer of virtual machine is the C language's VM, which is a single stack with call frames machine. The individual compiler can make tradeoffs between register usage and stack usage, within the narrow confines of the C ABI for your desired platform. In general, gcc without any optimizations turned on produces a very clean, stack heavy, direct translation of your C code into machine code. Unfortunately, the basic C virtual machine isn't terribly efficient even on modern processors tuned for executing C.

Squeak is implemented in a subset of Smalltalk, which is then translated into C. That C is then compiled using the host platform's compiler, and produces a system native binary on which to run the Squeak VM. This VM has historically differed substantially from the C one. Eliot Miranda's new Cog VM goes a long way towards marrying the two, but adds a few twists to support the context games often required by Squeak code. Moreover, as Smalltalk is a message passing language, subroutine execution is vectored at runtime which adds an additional layer of indirection between the code and the virtual machine byte codes executed.

Finally, running on top of Squeak is the Ometa virtual machine, which is a rather clever state machine for translating input streams based on an extensible recursive grammar into system executable representations. There are implementations of Ometa that run using Javascript to implement the Ometa VM, C#, Python, and much much more. In a way, Ometa is a parasitic programming language in that it "requires" a host language to live.

The Strange Inversion

Now there is actually no good reason that Ometa should require a host. All of these layers of translation exist only to make it easier for the programmer to continue using tools he's already familiar with. One could just as easily translate Ometa input directly into machine code. Since there are already environments which host Ometa, retargeting one to output a machine native binary would not be terribly difficult.
catch(e) " href="http://1.bp.blogspot.com/_XCDTVvEbBMU/SiU-08AKCUI/AAAAAAAAACw/_92o2rjNAzQ/s1600-h/inversion2.png">
The resulting model would look something like this, and would be no less capable of interfacing with the other systems. Remember, if a host operating system defines an ABI, all you need to do to interface with it is mimic its calls. The overhead you face is no more than you would have making a native call. Unless of course, your language has problems with data structures.