This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Joe Buck <jbuck at synopsys dot COM>, Ziemowit Laski <zlaski at apple dot com>, "Joseph S. Myers" <jsm28 at cam dot ac dot uk>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: 27 Nov 2001 20:23:20 -0600
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for
- References: <32170000.1006903600@gandalf.codesourcery.com>
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>> Consider a preprocessor that takes current Altivec C code and produces
>> either standard or extended C code (GNU extensions). If adopting the
>> existing Altivec syntax is too painful, a second choice might be to figure
>> out syntax choices that would make such a preprocessor very easy to write.
>> Then we don't have to ask existing users to rewrite their code.
> Yup, I thought about this too. It's plausible, but a pretty substantial
> effort, and not easy to do robustly with the tools we've got.
I've actually thought about implementing generic front end extension
support to gcc for this kind of nonsense. Sort of like a preprocessor
that runs after the actual C preprocessor-- massages the output in any
way it sees fit, and feeds its output to the lexical analyzer.
This way if someone wants to implement some brain dead front end
extension widely used somewhere else, it could be a plugin-- and we
could offer a whole slew of plugins in the future (altivec plugins,
msoft inline assembly plugin, etc etc).
That sounds like a good project :)
what do y'all think?