[i336_]

Hi, wanted to quickly ask a slightly offtopic question about TCG that I've wondered about for a few years. I was never sure who to ask.

Rob Landley made some small noises about the possibility of leveraging TCG as a successor to tcc (I read about the tinycc/tcc debacle (http://www.landley.net/code/tinycc/) - really sad). I was just curious if such an idea - turning QEMU's code generator into a standalone compiler - is technically feasible in terms of architectural sanity and practical maintainability.

[pm215]

Well, I guess technically you could do it -- the codegen started out as code from tcc, after all. However we've made enough changes over the years that right now it has some specializations to QEMU's needs. Also questions like "is this optimization pass worthwhile" have definitely different answers for QEMU's JIT purposes compared to an actual compiler -- we care a lot more about codegen speed so there are some optimizations that we prototyped but abandoned because they didn't improve the runtime performance enough to make up for codegen getting slower.

[i336_]

I didn't actually know that TCG was built from tcc, interesting.

Leveraging TCG in its current JIT-optimized state could actually be very compelling though: the only "C interpreters" I'm aware of are PicoC and Ch (and pedantically, tcc -run), all very different codebases. None offer a JIT-optimizing C interpreter though.

I take it that all that would be necessary would be ripping out the disassembler frontend and wiring in something like http://www.quut.com/c/ANSI-C-grammar-y.html + http://www.quut.com/c/ANSI-C-grammar-l-2011.html (or an equivalent), or maybe even a (heavily) forward-ported copy of tcc's C parser?

[bonzini]

TCG used to have no optimizations at all, so the current ones shouldn't be worse than what tcc used to have... That said I have never looked at tcc's code generator.