Klass-Jan Stol writes: > > The thing is, I don't have a lot of experience when it comes to > > compilers, but I do know a whole lot about python. :) If this > > approach makes sense, is there someone with IMCC experience who'd > > be willing to do some virtual pair programming with me and spike > > out a prototype? > > > > If I understood correctly, the codegenerator is isolated to one > module, right? I don't know Python, and I've a little experience > with IMC, but it seems to me only a new code generator module should > be written. So, if for example the Python code generator (generating > python byte code) has a method "gen_assignment(...)" for generating > python byte code doing an assignment, then the new module method > (generating IMC) should do the same, but with IMC instructions. As > noted earlier, I've got no experience in Python whatsoever, but it > seems to me it's just a matter of generating the right IMC > instructions for each construct, so when walking the parse tree, > calling "gen_imc_*" methods.
Well... sortof. It's definitely going to take writing a whole new code generator module; it's not just a matter of getting the right instructions. Python's interpreter is stack-based, while Parrot's is register-based, which are two very different kinds of data. I think it would be good design to have the python binary parse for us, but it's not likely practical. Python has eval, so unless we want to link with python, we should probably write our own parser.[1] I know a little python, and it looks like writing a parser for it should not be too difficult. > I'm no compiler guru (basic overview + a little experience + much > interest :-), but I find the material very interesting and would > gladly help. I'm pretty good at compilers, and helping out would certainly teach me more python. So, I'm up for it. > Klaas-Jan Luke
