I think the main problem is that any VM written in a higher-level language will be too slow for practical use.
Take a good look at the performance of alternatives to C in the benchmarks at the GCS when doing VM like things.
In many, maybe most cases, C is left behind by compilers for languages like Haskell, Erlang, OCaml, SML, and my favorite Clean.
When you combine their deeply analysing and heavily optimising compilers, with their freeing the programmer from so much of the low-level housekeeping like memory management, using almost any of them to create a VM interpreter would be a win in terms of productivity.
It may be that you would want to hand code the dispatch loops and JIT compilers in C or even assembler--maybe--to squeeze out the final ounce of performance, but you retain those generated by the compiler/hll for debug and benchmark purposes.
C does can produce very fast compiled code--in the hands of exceptionally proficient programmers--but that performance comes at a huge cost in terms of productivity. Coding yet another set of memory management, allocation/deallocation infrastructure, debug and trace routines et al. And when things do go wrong it requires a special breed of immensely skilled and dedicated practitioners to investigate and track down the causes.
Most of us here recognise the benefits of using high(er) level languages with in-built memory management and revel in the freedoms that gives us. It seems silly to eshew those benefits for writing the vast majority of the infrastructure and kernel of a VM. Better to write in a HLL for reliability and productivity and reserve C for tuning the performance critical parts.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|