Re: [Tinycc-devel] inline assembly and optimization passes

[Jared Maddox]

> Date: Sun, 22 Sep 2013 18:39:00 +0200
> From: Sylvain BERTRAND <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <address@hidden>
> 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.