Re: motorola altivec extension question

[Jim Wilson <wilson at specifixinc dot com>]

Spundun Bhatt wrote:
> Is this not the correct mailing list for this question? If not, could 
> you tell me where to post this question?

It is a reasonable list for this question.  You could also try gcc-help. 
 Most GCC work is done by volunteers, and we don't always have time to 
answer everyone's questions.  (Some of us are paid by our employers to 
do work on gcc, but we aren't paid to do things for the FSF, such as 
answer questions like this.)

I have limited knowledge of the Altivec support, so my answers are not 
definitive.

> > The question is "how different is the motorola-altivec-extension to c 
> > in gcc-3.2 to the motorola hack on 2.95.2?
> > Googling, the best answer I have found so far is this. 
> > http://www.simdtech.org/apps/group_public/email/altivec/msg03916.html
> > I wanted to confirm that there are no other symantic or name changes 
> > in the api.

That is very likely to be the right answer.  There may have been some 
improvements since then, so some of them might have been fixed.  It is 
certainly our intention to follow the API as closely as possible.  The 
main problem I am aware of if the vector keyword support, as that 
requires implementing context dependent keywords.  Some people feel that 
this is a mistake, so it hasn't been implemented.

I believe Apple has their own implementation of the Altivec support, 
possibly based on the Motorola patches.  So if you have a mac, and are 
using an Apple supplied compiler, you might get different results than 
if you are using FSF gcc.

> > In the motorola hacked version of altivec gcc, the builtin vector 
> > functions were prototyped seperately for different data types(i.e. 
> > vector unsigned,vector int etc...). Looking through the new backend, I 
> > could not find that. I found one builting per altivec instruction... 
> > its amusingly simpler, but I just wanted to ask how did you do that? 
> > and why the motorola guys didnt do that?

For the first question, this isn't specific enough for me to answer.  I 
don't know what is different in the FSF code than in the Motorola code. 
 If you are asking why we only need one builtin function for signed int 
and unsigned int, it is probably because they map to the same 
instruction.  If they mapped to different instructions, we would need 
two builtin functions.

You would have to ask the motorola guys to get an answer to that last 
question.  I can't read their minds.

> > I am a part of a research project and we are planning to port our work 
> > from 2.95.3 to 3.2. All work is in the rs6000 backend. Any perticular 
> > pitfalls to watchout for? any other advise? any?

Expect a lot of things to be different.  2.95 to 3.2 is a big jump, and 
many things have changed.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com