> Date: Sun, 22 Sep 2013 18:39:00 +0200 > From: Sylvain BERTRAND <[email protected]> > To: [email protected] > Subject: Re: [Tinycc-devel] inline assembly and optimization passes > Message-ID: <20130922163900.GC741@freedom> > Content-Type: text/plain; charset=us-ascii > > On Sat, Sep 21, 2013 at 12:02:58AM -0500, Jared Maddox wrote: >> I recently bought a copy of the "Dragon Book", and according to >> it, optimization passes are usually performed on an AST that is >> created from a compiler-specific intermediate code: in essence, a >> specialized byte code or assembly code that the compiler outputs >> instead of directly producing the intended end-product byte code. >> It shouldn't be too hard to just add an IC / IL target and let >> someone do optimization as a completely different program >> (probably in a custom linker-and-optimizer program). I myself >> have considered adding support for a VM that could partially >> support this sort of thing. >> >> If he wants to volunteer to implement such an IC / IL target >> (particularly if he also volunteers to provide the assembler with >> the ability to understand it), then I say it would be worth >> considering any patches that he provided. Certainly though, most >> optimizations shouldn't be allowed in TCC itself. > > Since tinycc should stay C (untill the ISO standard gets really > bad), we could drop a few levels of generalization: A backend > which does not generate assembly/machine code, but a backend > which does generate "kind of optimized" C code. We would feed > again that "kind of optimized" C code to tinycc with the cpp > disabled. It seems to me a well balanced trade-off, but I may > miss obvious blockers. >
Sorry about the delay, I receive digests, so I didn't get this until after I'd sent out my last message. The reason why C is normally not used as an IL/IC is because you can design languages that are easier to parse than C. Simple as that. Your stereo typical assembly language, where each line of code corresponds to a single discrete action and it's arguments is much easier to parse than C. So, C normally doesn't get used in that role, because someone who can write a parser for any variant of C is likely to have a much easier time writing a parser for some specialized language instead. C isn't as difficult to parse as C++, but when you consider that you'll be having to parse all of this again in a completely different program, it becomes easy to see why you'd favor simplicity of parsing. _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
