Re: Frontend for C with gcc extensions

VBDis <vbdis@aol.com> wrote:
>>The obvious answer -- gcc frontend itself doesn't count, because it's
>>not frontend in traditional sence -- it's rather an inextricable mix
>>of frontend and backend.
>
> How do you distinguish a frontend from anything else?


I think what the original poster wanted is something that
can parse GNU C, type-check it and then spit out some form of
abstract syntax tree or other intermediate form which can then be
used for code generation.




> IMO you can strip all "backend" code off the gcc sources, in order to
> obtain the desired "frontend". Of course some prodcedures must be
> replaced or introduced, to create the desired output of the frontend.


Stripping off the "backend" code from GCC is easier said than done.


GNU C does use RTL as its intermediate form and you can pass
in parameters to dump the RTL after various passes of the
compiler. You might be able to modify the GCC code at these
"dump points" to hand over the RTL to some of your own
passes and bypass the remaining GCC passes. But I'm not
sure of how self-contained the RTL is and whether it depends
on certain global state in order to be processed.




> As mentioned in another thread, a modern preprocessor (frontend?) can
> not easily be separated from the according compiler (backend). When
> e.g. your frontend should handle sizeof() expressions in conditional
> statements, then it also must understand any type declarations in the
> source code.


See above, what he wants is not a pre-processor but the entire
scanning/parsing/type-checking front-end which generates
an IR that can be given to a subsequent compiler pass. So I
would expect the front-end to handle types, sizeofs and so on.


Manoj

Return to the comp.compilers page.
Search the comp.compilers archives again.