altivec questions

[Ziemowit Laski]

On 29 Jun 2004, at 13.58, Janis Johnson wrote:

> Some AltiVec observations and questions:
>
> 1. vector bool
>
>    The documentation says "The bool type is deprecated and will be
>    discontinued in future revisions.  Use vector signed instead."

That's a bug in the documentation.  'vector bool ...' types are 
first-class
citizens which _must_ be kept distinct from 'vector signed ...' or
'vector unsigned ...'.

>    Recently, though, Zem added lots of support for vector bool and
>    except for some apparent oversights it appears to be fully supported
>    now, along with vector pixel.

Indeed.  What are the oversights? :-)  I wouldn't mind fixing them, 
unless
you have done so in the work you mention below.

>
> 2. vector long types
>
>    Use of "vector signed long" and "vector unsigned long" isn't
>    documented, but GCC gives "warning: use of 'long' in AltiVec types
>    is deprecated; use 'int'".  These ought to be hard errors for -m64,
>    right?

Why?
>
> 3. pointers to long and unsigned long
>
>    Several tests pass 'long *' or 'unsigned long *' in places where the
>    Motorola AltiVec PIM does not include those types among the
>    acceptable arguments.  GCC doesn't complain for either -m32 or -m64.
>    These ought to be errors for -m64, right?

Yes, I think they probably should.

>  Should GCC's altivec.h
>    support the ones that are used in the gcc.dg/vmx tests?
>
> I've gone through the Motorola AltiVec PIM and altivec.h comparing the
> generic and specific AltiVec operations with the C++ functions and the
> C macros.  I'm sure these matched up when Aldy was finished, but there
> are a lot of inconsistencies since the addition of support for vector
> bool and vector pixel.  I'm testing a big patch to altivec.h that makes
> everything match again, and I'll have a patch to extend.texi to make 
> the
> documentation match what's supported in altivec.h.  Before I submit
> these I'd like to clear up the questions above and make sure I'm
> understanding this stuff correctly.

Great; thanks.  Please also take a look at the apple-ppc-branch (which 
both
IBM and Apple are currently working on); it is possible that it 
contains some
of the fixes you are looking for.

Thanks,

--Zem