Re: Target-specific Front-Ends? (Was: front end changes for altivec)

[Ziemowit Laski <zlaski at apple dot com>]

On Tuesday, November 27, 2001, at 09:47 , Stan Shebs wrote:

> I wasn't going to mention your name, but if you want to take
> credit I can't stop you... :-)

I likewise held my peace, but now that the cat is out of the bag... :) :)
>
>> For MrC[pp] is was easy to do.  And it was based on
>> feedback from our internal (Apple) AltiVec users (the *only* users at
>> that time other than Moto).  They didn't want to write __vector and
>> they certainly couldn't tolerate "vector" being a macro that expanded
>> to __vector (which Moto was proposing).  And "vector" couldn't be
>> treated as an unconditional reserved word either.
>
> Nevertheless, I still think it was a mistake.  When it comes to
> messing with the language, we often need to say "no" to users, who

I agree that Ira's 'vector' (as opposed to '__vector') was not the
cleanest way to approach this (although not nearly as nefarious as
'#pragma poison'), but THIS IS TOTALLY BESIDE THE POINT!

My point (or, perhaps, points) were:
   1. GCC is used on a variety of real-world platforms
   2. In that same real world, people have invented tons of
      target-specific extensions to C and C++ to get extra mileage
      out of their particular hardware/OS setup.
   3. Ergo, we should be able to come up with a 'configure'-based
      mechanism for enabling selected extensions for selected target
      WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

How could we go about step 3?  I'm sure there are a million ways,
but let me illustrate one possible scenario (for AltiVec):
   1. We create a file called gcc/config/rs6000/c-parse.in.diff
      (and something analogous for C++)
   2. At build time, this diff will be used to patch up
      gcc/c-parse.in if needed.

The foregoing approach has two immediate consequences:
   1. The mainline grammar/lexical analyzer remains unchanged
   2. It will be the sole responsibility of the users of AltiVec
      extensions to maintain the diff so that it can be applied
      cleanly; mainline developers need not and SHOULD NOT be
      forced to deal with this.

> the world?  Ironically, this extension makes our internal version of
> GCC more complicated and time-consuming to merge with FSF sources, so
> our imports take longer and have more problems, which means that your
> own daily work today has been made more difficult by the expedient
> choice of several years ago.

True, but I suspect that we (i.e., Apple) are far from the only ones
in this situation, which is why it is so desirable, IMHO, to be
able to put all such target-specific stuff in the FSF tree to begin
with!  Of course, we already do this for back-end/codegen stuff -- we
just need to generalize this model.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085