The requirement that says "Must run on every OS known to Man, and then some." Writing C that's that portable is hard, but I don't think I need to tell you that. One of the features I haven't mentioned is PGE, which is, essentially, the parser. Patrick Michaud is currently writing it in PIR. Who's going to write it in C? I don't know enough portable C to do so ... finding someone who knows enough, has the time, and is interested is going to be a ... challenge.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Patrick's original implementation of PGE was in C. Now that he's got a nifty PIR implementation, it shouldn't be too much work for him to create a C implementation again if the need arises. As I understand it, the main problem is that the PIR implementation utilizes continuations quite a bit, so those would have to be "ported" to C as well to keep the implementation simple yet equally as powerful.
| [reply] |
I think the main problem is that any VM written in a higher-level language will be too slow for practical use. That's why the Java VM and Mono are written in C (and .Net is written in C++?). The compiler doesn't matter so much, it's only involved once in the execution process and can be written in a higher-level language, but for the actual runtime you need to get as close to the metal as you can which means writing it in C.
| [reply]
[d/l] |
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.
| [reply] |
If and only if you can have those compilers emit this C code to be compiled on other platforms. That's the big issue with writing the VM in non-C.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |