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
next 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).