> I was wondering how much interest is out there to create an alternative > version of Maru's emit.l that emits bytecode for a tiny C-based VM.
That seems like a step backwards no? Let me explain my thoughts from having played around with emit.l Emitting to a C-vm pulls you right back into needing a C toolchain & crt. It won't run all that much faster (assuming you're using GCC as a toolchain). I think the biggest loss would be a loss of learning / transparency. It's very clear what the assembly instructions are doing directly to the HW and memory layout. The C VM would (especially around function calls, thunks, closures, and oop-at lookups) obscure all that. Once you have a COLA like Maru (with its pre-scheme like abilities) you can write at both the high and low level. I've been starting to play with making emit.l handle ARM so I can run maru programs on the Raspberry pi. The approach I'm planning to take is to write a simple abstract stack machine as an embedded DSL in maru. You could then evaluate that down to x86 or arm. This is similar to what compliers use an IR for (though GCC's IR is an IR that isn't). If ever we wanted to run an optimizer against this whole thing, one of the targets could be llvm assembly (it's an SSA assembly rather than a register assembly). Going from the stack machine IR to llvm assembly in SSA form shouldn't be all that complicated. LLVM can then do smarter register allocation and whole program (cross compilation module) optimization and inlining. It's possibly even good enough to produce a good nile runtime specified in Maru (or any description that transform down to maru via a PEG transform pipeline). shawn > In my mind, we'd generate a single portable C file, which would > interpret an embedded data array representing the compiled program. If > such a emitvm.l existed, then we could do away with the hand-written > eval.c and make changes only to eval.l, and regenerate eval.c from > there. > > Is that in line with your plans for the project, Ian? >From the latest yearly report it seems like they are pursuing both Nothing and >Maru as bootstrapping vehicles. > > Thanks, > > -- > Michael FiG <[email protected]> //\ > http://michael.fig.org/ \// > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
