Hello, >> We talked about having a Scheme-based language that could compile to >> both plain C and JIT, but decided that would make the VM too >> complicated, > > Maybe I forgot to feed that thread, but I think it might be easier to > have a high-level representation the VM opcodes as sexps (possibly a > subset of Scheme), and then write the C files from that. > > Though the main difficulty is to find a sufficiently expressive way to > write opcodes in.
Oh dear. My impression was that we had decided to use a C parser. If not, I think the hardest part of making this work would be making the C output look nice. Libjit and C are such similar languages that making the translator would be quite simple. >> I notice that GCC now has the ability to use plugins, > > The plug-in API doesn’t allow plug-ins to add new front-ends > (info "(gccint) Plugins"). Ah, I see. I read their wiki a bit. It does look like using GCC would be difficult, but I still think it would be worthwhile to do just because they have such a nice compiler already written. It looks like what you need to build a frontend is the ability to manipulate GCC's data structures and the ability to write functions that C code can call back to. I believe the FFI can do both of these things now (not that it wouldn't be a pain to fit everything together). Also, after looking at the MELT project and the Modula-2 frontend, I'd say they might be receptive to the idea of using a high-level language to write parts of GCC. Noah
