public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pablo De Napoli <pdenapo@yahoo.com>
To: gcc@gcc.gnu.org
Subject: A suggestion to make it easier to develop gcc front ends
Date: Sat, 05 Apr 2003 20:51:00 -0000	[thread overview]
Message-ID: <20030405150258.49354.qmail@web41511.mail.yahoo.com> (raw)


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

             reply	other threads:[~2003-04-05 15:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-05 20:51 Pablo De Napoli [this message]
2003-04-05 21:30 ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030405150258.49354.qmail@web41511.mail.yahoo.com \
    --to=pdenapo@yahoo.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).