This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Monday, November 26, 2001, at 03:45 , Joseph S. Myers wrote:

> On 26 Nov 2001, Aldy Hernandez wrote:
>
>> the altivec specs require changes to the gcc front end.  this has been
>> brought up before but no one has really commented.  now before everyone
>> start raising shields and going "yuck, no way", hear me out.

Unfortunately, AltiVec extensions are (syntactically) quite yucky.  
Legacy
Motorola/Apple/IBM code is likely to rely not only on '__vector' and 
'__pixel'
and 'bool' (in its non-C++ sense!) but also 'vector', 'pixel' and even 
'__bool'!
If I had my druthers, I'd just stick to the '__attribute__(...)' 
notation, but
obviously I don't have my druthers. :(  At any rate, AltiVec syntax is 
not
easy to "intellectually reconcile" with any of the underlying 
languages.  (And
yes, we do have it in our Apple gcc3 tree...)

But this brings up a more general question, one that I've been meaning to
ask of the wider community for quite some time: Should we come up with a
generalized architecture in GCC (for all front-ends) to enable front-end
extensions:
   1) only for specific platforms (e.g., Altivec for PPC targets, 
'dllexport'
      for Windows, etc.); and/or
   2) only when explicitly specified via the configure script (e.g.,
      '--enable-altivec-keywords', '--enable-pascal-strings')

AltiVec is merely one example of an idiosyncratic extension that exists 
on
only a small fraction of targets that GCC supports.  It would be nice to
only enable the extension for the targets that need it, analogously to
how back-end bits are pulled in from gcc/config/....  Naturally, it
would also be up to the maintainer(s) of a particular target to ensure
that the front-end extensions continue to work with the main (generic)
front-end.

Anyway, this is just a thought.  I'd be curious as to what the rest of 
you
think about this.

--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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]