From mboxrd@z Thu Jan  1 00:00:00 1970
From: Devang Patel <dpatel@apple.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: Devang Patel <dpatel@apple.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Target-specific Front-Ends? (Was: front end changes for
Date: Wed, 28 Nov 2001 11:09:00 -0000
Message-ID: <E8B82838-E433-11D5-A87D-00306558FC20@apple.com>
References: <m3elmjvdk7.fsf@litecycle.cc.andrews.edu>
X-SW-Source: 2001-11/msg01493.html
Message-ID: <20011128110900.6mPAVE5IbnmXoO_WM1SvIjnFSMcgrm_KTHBkBcQ4PDs@z>

On Tuesday, November 27, 2001, at 06:23  PM, Aldy Hernandez wrote:

>>>>>> "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
> ...
> what do y'all think?

- One very big disadvantage of GCC, compared to other compilers, is
   compile time speed. I think it may not be a good idea to eat millions 
of
   tokens just to take care of couple of tokens. Every machine cycle 
counts.

- It may open pandora's box for many unnecessary extensions and put
   GCC users in difficult situation when these extensions are not carry
   forwarded.

Instead of extra preprocessor , It's would be nice to have good  plug-in 
architecture
in GCC front end (like GCC back end architecture)

- Plus, this kind of extension means Altivec will always remains outside 
of main
   GCC front end engine. And it may not be a good idea in long run, 
because
   -- Any major redesign/improvement of front end will not consider 
Altivec during
       design and will require extra support to keep Altivec extension up 
to date.
   -- Any future C-based language standard update may introduce new things
        which may collide with spec supported by such Altivec extension. 
This
        can create lots of problems for Altivec users as well as GCC 
developers.
        It is better to accept clear set of Altivec specs as part of GCC 
front end so that
        GCC can raise hands against such future collisions. (Which means, 
this
        may be the time two clean up any ambiguity in Altivec spec, if 
there is any, as
        far as GCC is concerned)

my thoughts,

Devang