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]

Re: Vector Extensions in GCC


kumar@chaos.ph.utexas.edu wrote:
> 
> 1. As far as the copyright is concerned.  Motorola did sign a future
> assignment back in August of 1993 for gcc.  I have a copy of it sent to me
> by Brian Youmans at FSF.  The 68k/88k references are in Schedule A not in
> the actual assignment (it looks like the standard assignment from that
> point in time).

That's great news!  One bit of worry gone...

> 2. Providing support for the Altivec Programming Model:  Should gcc in
> general provide support for extensions that 3rd parties support for a
> given architecture.  Altivec is just one example of this problem.  All PPC
> 3rd party commerical compilers (Diab, MetroWerks, Green Hills,
> Metaware) provide support for the AltiVec model as defined by
> Motorola.  While it can be argued that there are alot of things bad about
> the model, should gcc at least support it to allow people using one
> compiler to move to another?

This is always a difficult decision for GCC.  It would be very easy to
get sucked into a mode of always trying to keep up when features added
to other compilers, even if they're technically undesirable.  Each one
of those features eats up people's time, and since GCC has so many
targets, people working on one target would have to code around things
added for a different target, slowing down development as a whole.
That happens even with today's fairly strict policy on target-specific
features, and the AltiVec changes in their current form are so extensive
that I can guarantee they would be a boat anchor on GCC development
for years to come.  In fact, this has already happened - the AltiVec
code makes illicit backend-to-frontend calls, and the GNAT folks
working on their port to Mac OS X have had to add a workaround.

So we need to "deconstruct" the AltiVec support, separating it into
the parts that make sense for mainline GCC and justifying each, one
by one, and then keeping whatever is left over in Apple, LinuxPPC, etc
versions of the compiler.

Stan


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