Hi thanks grischka, this is pretty much what I was expecting. Yes, we do have something that generates C code which is why it seemed like an easy way. The problem with that however, as I mentioned before, is that the generated C code makes use of some GCC extensions which I believe are not available in TCC... (Some very useful stuff for code generation, such as statements as an expression for example). There's maybe one or 2 of them... One solution would be to implement those and we could make a lot of progress in that direction.
Another problem is that there are some issues with C code generation, such as required prototyping and reordering of declarations which causes us many headaches which could get rid of if we were to skip the intermediate C code. Assembly would be a little low level however and what you're proposing of providing an interface for those generators brings up sparkles in my eyes. We'd be happy to work on that to make it possible to plug at a more C-like level. Thanks again! Jerome On Sat, Jun 13, 2009 at 8:39 AM, grischka<[email protected]> wrote: > Jerome St-Louis wrote: >> >> Hi all... >> >> We are contemplating using TCC as the backbone engine to generate >> object code for an eC language Just-In-Time compiler system. >> >> At the moment, the compiler uses C as an intermediate language, >> outputs intermediate C files, then call GCC on those to produce object >> code. >> We're hoping to do everything at once, in-memory for a more lively >> solution. >> >> How would this best be done by using the TCC library? Is there some >> kind of abstract syntax tree system or other in memory code >> representation we could plug into directly, as opposed to having TCC >> do parsing again? This would ideally increase performance a lot.. >> >> One of our main worries are the few GCC extensions the intermediate C >> code makes use of, which I believe TCC does not support... Again this >> might possibly not be an issue if we're going directly to an in-memory >> code representation? > > If you have something already working that produces C code then it > might be easy to adjust it for TCC. The performance on the side > of TCC might be a non issue, it reads 20-30MB of C per second. > > Of course it has advantages if you can use a code generator directly, > say TCG (Tiny Code Generator from qemu) as something small and fast > or LLVM as something more solid. > > However the input for such generators is not C, it's more like high > level assembler code. Basically you get arithmetic instructions with > abstract registers such as > tcg_gen_add_i32(R2, R0, R1); > and branch instructions to labels such as > tcg_gen_brcond_i32(TCG_COND_EQ, R0, R1, L1); > and that's it, roughly. > > Currently TCC's does not provide an interface with such generators, > but I guess sooner or later we are going there (if anywhere). That > is either by using TCG and/or changing TCC's current generators to > provide a better defined interface. > > For now TCC's only input is C and the only "in memory representation" > is machine code. > > See "libtcc.h" for the interface and "tests/libtcc_test.c" for an > usage example. > > --- grischka > >> It is very likely that this project becomes our primary focus for the >> time to come so we're very interested in any feedback you guys may >> have, and if there is an opportunity for us to improve TCC at the same >> time we'd be more than happy to contribute. >> >> Thanks. >> >> Best regards, >> >> Jerome @ Ecere > > > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/tinycc-devel > _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
