And Smalltalk - for much the same reasons - has some pretty quirky code in the VM to be able to make the concept of message passing between objects work fast enough to do real work. There is a pretty sharp dividing line in the VM between 'the elegant stuff' and 'the hack to make it all work', where the primitives are activated.
Smalltalk primitives and their classes are of necessity implemented outside of the language, they 'just work' and you can not inspect their implementation within the VM because that would require you to reflect on its own implementation, which it can not do for obvious reasons.
So even though Smalltalk is 'self aware' to an extreme degree that self awareness does not extend all the way to the bottom, and I don't see how that would be possible anyway. At some level you will have to make the jump between the CPU you'd like to have (the one executing Smalltalk directly) to the one that you actually have.
There is this guy: http://www.merlintec.com/lsi/jecel.html who has been working on a ST hardware implementation for a long time, I am not aware of its current status.
But note that even in that situation you will still be limited, but then not at the level of the VM builtins but at the level of the CPU instruction set implementing the primitives.
Ideally Smalltalk would be able to transcend the boundaries of the computer it runs on sending messages to other computers with proper error handling, that would be some kind of hybrid between the BEAM and the Smalltalk VM.
I guess it's not the same kind of introspection because it adds a level of indirection, but I've heard stories of the VM itself being implemented in something called "slang"[1] that's a kind of lower level smalltalk that easily compiles to C, but can be interpreted in smalltalk itself (via an Interpreter class that is perfectly normal smalltalk).
Information is quite sparse on that topic, and my knowledge is quite fuzzy there but I'd love to find more info on that (in case anyone can provide links.)
When Pharo and Squeak people do VM development, they do it inside a special image equipped with the VMMaker package [1]. What this package has is both "slang" -- which can easily compile to C -- and an emulator running the development VM inside the smalltalk image.
So with some exceptions, VM development occurs almost exclusively inside Smalltalk itself. In fact, this is how Alan Kay, Dan Ingalls, and others brought Squeak to life from an old Apple Smalltalk implementation. They touched C directly as minimally as possible and took the Smalltalk concept very seriously.
Instead of using Pascal or C, the code was written in a subset of Smalltalk-80 itself. This subset (later named Slang in the Squeak project in 1996) doesn't use objects nor polymorphism. It only deals with an Array of integers and only uses a few control structures, so every expression has a C equivalent.
The first VM implementers at Apple, DEC, Tektronix and HP manually translated this code into Pascal, assembly or C as their starting point and then evolved their code from there.
Much later it was shown that this code could actually run inside Smalltalk-80.
...which is not all that strange. If you were using a Lisp machine (or, say, IBM z/OS), and you wanted to do POSIX software development, you'd probably
1. use your own POSIX machine to cross-compile a POSIX ABI simulator for the target OS; and then
2. deploy a POSIX sandbox to the target, with POSIX tools like gcc inside, and continue work on things like the POSIX ABI simulator in there.
Thanks for mentioning my project! I am still working on the design of Smalltalk hardware, but this year I have expanded that a bit to include efficient emulation of other machines (such as x86 or ARM) and not just the Smalltalk VM.
Note that in Self many of the implementation tricks needed to make Smalltalk run fast were eliminated. And I see no reason why the number of primitives can't be as few as 12 or so. The rest are needed either for speed (but a good compiler can let normal Smalltalk code do the same job) or to talk to the operating system (but a Smalltalk on "bare metal" doesn't need that).
Smalltalk primitives and their classes are of necessity implemented outside of the language, they 'just work' and you can not inspect their implementation within the VM because that would require you to reflect on its own implementation, which it can not do for obvious reasons.
So even though Smalltalk is 'self aware' to an extreme degree that self awareness does not extend all the way to the bottom, and I don't see how that would be possible anyway. At some level you will have to make the jump between the CPU you'd like to have (the one executing Smalltalk directly) to the one that you actually have.
There is this guy: http://www.merlintec.com/lsi/jecel.html who has been working on a ST hardware implementation for a long time, I am not aware of its current status.
But note that even in that situation you will still be limited, but then not at the level of the VM builtins but at the level of the CPU instruction set implementing the primitives.
Ideally Smalltalk would be able to transcend the boundaries of the computer it runs on sending messages to other computers with proper error handling, that would be some kind of hybrid between the BEAM and the Smalltalk VM.