On Mon, 2006-07-17 at 14:49 -0700, Allison Randal wrote: > re2c and lemon aren't enough of an improvement over flex and bison to be > worth the pain of rewriting IMCC from scratch. If we do create a new way > of producing bytecode (and it's a safe bet that we will at some point), > I would lean toward using our own tools.
> - Patrick is already looking into implementing a version of PGE in C. > This will be an infinitely better parser than any existing alternatives, > so it's worth waiting for. > > - We already want an OST(opcode syntax tree)-to-bytecode compiler that > bypasses PIR for the compiler tools. That same compiler could be used to > implement PIR (combined with a lightweight version of TGE in C). > > - IMCC is not a straight translator, it also performs optimizations. > These should be implemented in a modular way, with a standard interface, > so that developers can swap in new and improved optimizers as we go > along. The best place to hook them is probably off the OST-to-bytecode > compiler. Allison having said that we need an API for byte code generation that supports plug n play optimizers would it make sense to start implementing this layer. This API could be used for OST to byte code generation. Later when Patrick's PGE to C parser generator is ready we could use his code to implement the PIR compiler and just use the API's that we write for byte code generation. Initially for prototyping purposes we might just use the existing flex/yacc or re2c/lemon. Allison should this development wait or can we start working on it? Will we need a PDD before we can commence working on this API. Let me know your thoughts. It might not hurt to start working on a Prototype API and see how it fits withe OST-to-bytecode compiler. > This approach does mean that the tools to start an IMCC rewrite aren't > available yet. It's a long-term solution (possibly post-1.0), so we can > afford to take a long-term view. > > Allison
