A suggestion to make it easier to develop gcc front ends

A suggestion to make it easier to develop gcc front ends

[Pablo De Napoli]

Dear developers of gcc:

I want to make a suggestion of an improvement to gcc. The goal of this 
improvement would be making easier to develop new front-ends to gcc for
different languages. 

My idea is that the backend and the front-ends of the gcc should be clearly 
separated. The backend should be implemented as a library. Then if someone 
wants to develop a new language, he would include the apropiated headers  
(say #include <gccbackend.h>) and link with the library. 

The backend library would implement the convertion from RTL code to assembler 
code, generating debugging code and (language-independent) optimizations.

The gcc backend library should have a well-documented and (hopefully) stable 
API. So that when the gcc backends improves, we don't need to change every time 
the gcc front-ends source.

What would we get from this ?

- It would be easier to develop gcc front-ends. This surely would mean
that we will have more languages! 

- It would be easier to compile gcc. We wouldn't need the whole source
tree. Each language front-end (execpt perhaps C that is needed for 
bootstraping the compiler) would be compiled in its own, with its 
own source code tree.

- It would make gcc easier to mantain. For example, gcc developers working
in one front end (say fortran compiler), won't need to know all the 
details about the backend or the other front-ends. Also we could have
independent releases for each language, different CVS repositories for
each language, etc.

- In general, I think it is a good design practice that each program should
do one or two things, and the programs should cooperate to do more complex 
tasks (this is the over-all Unix philosophy).

I hope that you like my idea. I should confess that I don't know well the
gcc internals, perhaps there is a thecnical reason why my idea is very 
difficult to implement or it is not convenient.

Best regars,
                        Pablo De Napoli
                        (from Buenos Aires, Argentina
                        (pdenapo AT yahoo.com)  


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Re: A suggestion to make it easier to develop gcc front ends

[Paul Brook]

On Saturday 05 April 2003 4:02 pm, Pablo De Napoli wrote:
> Dear developers of gcc:
>
> I want to make a suggestion of an improvement to gcc. The goal of this
> improvement would be making easier to develop new front-ends to gcc for
> different languages.
>
> My idea is that the backend and the front-ends of the gcc should be
> clearly separated. The backend should be implemented as a library. Then
> if someone wants to develop a new language, he would include the
> apropiated headers (say #include <gccbackend.h>) and link with the
> library.
>
> The backend library would implement the convertion from RTL code to
> assembler code, generating debugging code and (language-independent)
> optimizations.
>
> The gcc backend library should have a well-documented and (hopefully)
> stable API. So that when the gcc backends improves, we don't need to
> change every time the gcc front-ends source.

It still isn't entirely done, but a large proportion of the things you 
suggest have already been implemented in the tree-ssa branch. Specifically 
there is the GENERIC/GIMPLE intermediate tree representation. Generating 
these trees (the frontend) and optimizing/generating code from them (the 
backend) are two distinct processes, with the exception of a bit of setup 
code.

I'm not sure I'd describe the interface as well documented or stable as it's 
still fairly new, but It certainly could (and IMHO should) be.

I know of at least one person who routinely does work on g95 by developing 
the fronted in a seperate tree and linking with libbackend.a.

I haven't looked at the mainline/release branches recently, so couldn't say 
how much this is true for those.

Paul Brook