Hi Shawn, Shawn Morel <[email protected]> writes:
>> 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. We already have that: eval.c. I'm not proposing anything but a replacement for the current development methodology: 1) Implement a new language feature in eval.l 2) Reimplement it in eval.c for bootstrap purposes Instead: 1) Implement a new language feature in eval.l 2) Rerun emitcvm.l to regenerate eval.c for bootstrap purposes > It won't run all that much faster (assuming you're using GCC as a > toolchain). What I'm proposing will probably run slower. The standard emit.l would be used for everything that isn't bootstrap. > 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. I think you may be overestimating how different a C VM would be. I'm talking about virtualising the emit.l environment, but keeping clarity, at some loss of efficiency. The bootstrap eval.c doesn't need to be fast, it just needs to be featureful and portable. > 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). You should probably talk to Ian about the VPU... that's been one of his successful approaches to abstracting CPUs and handling all the register allocation nastiness. Thanks for your comments, -- Michael FiG <[email protected]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
