This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Status of SSE support in current gcc mainline
- To: David Korn <dkorn at pixelpower dot com>
- Subject: RE: Status of SSE support in current gcc mainline
- From: Daniel Berlin <dan at www dot cgsoftware dot com>
- Date: Fri, 23 Mar 2001 11:04:16 -0500 (EST)
- cc: "'Daniel Berlin'" <dberlin at redhat dot com>, kumar at chaos dot ph dot utexas dot edu, Dave Korn <davek-ml at ntlworld dot com>, Jan Hubicka <jh at suse dot cz>, Samuel Figueroa <figueroa at apple dot com>, Bernd Schmidt <bernds at cambridge dot redhat dot com>, gcc at gcc dot gnu dot org
On Fri, 23 Mar 2001, David Korn wrote:
> >-----Original Message-----
> >From: Daniel Berlin [mailto:dberlin@redhat.com]
> >Sent: 23 March 2001 14:50
>
> >> Vectors are always 16 bytes on altivec. The doc states that 'p' is a
> >> pointer to a vector.
> >
> >I must have misread that part, i thought it also said that sizeof(p)
> >is 16, not sizeof(*p)==16.
>
> Well, whatever the actual case is, it's simply a thinko if the size of
> a pointer-to-vector is 16 bytes, and not an essential part of the
> programming model!
>
> >Errr, look at how, for instance, Intel does SSE programming. They have
> >a few datatypes defined, a whole bunch of intrinsics, and C++ classes
> >that encapsulate the intrinsics in a vector class, etc.
> >
> >They didn't make basic changes to the actual language to try to
> >accomodate their code.
>
> Do you have a pointer to any docs handy?
DEveloper.intel.com has them somewhre, sorry i can't be more specific.
? I'd be interested to see this.
> How does it work for normal C?
You can just use the intrinsics.
> I'd hate to have to jump through a virtual
> function pointer every time I wanted to add two vectors - then again I'm
> afraid I don't know the meaning of the term 'intrinsic' - is it like a
> builtin ?
Yes.
intrinsic is, unless i'm mistaken, interchangable with the term builtin.
>
> >As a result, MSVC7, Intel's reference compiler,, and
> >various versions of GCC (probably not seen by most) support the
> >model without any trouble(off the top of my head, i'm sure there are
> >more). In fact, I can compile the same code on any of the compilers,
> >
> >What's better, things like the vector class that uses the intrinsics
> >will use normal, non-SSE calculations if your platform doesn't support
> >it (through #ifdefs).
>
> Are you saying that there's no direct way for the coder to control
> the low level details of how the vector instructions are used?
No, of course you can.
The advantage motorola was trying to give you was the ability to perform
normal arithmetic operations on vector types, without having to remember
to use "vector_add(a,b)" or something of the sort (IE you could just do
a+b).
This is the same thing Intel's C++ class gives you, except they don't
screw the base language to do it. They use overloaded operators.
If you want to use the intrinsics, which are basically scheduled asms, you
can. I was just trying to give a way to do what motorola was trying to do.
If you want to use C, you have to use the intrinsics, obviously.
But i don't think it's worth introducing completely new extensions that
aren't exactly all that nice, just so you can type "a+b" rather than
"vec_add(a,b)".
> I did
> like the idea of having vector types and builtins that compile straight
> down to single asm instructions.
Remember, they are scheduled, too, so they are little better than just
straight asms.
>
> I am completely unfamiliar with the intel model, but ISTM that the
> motorola version is something that low level, pedal-to-the-metal
> performance hackers would be happier with, and the intel one is more
> suited to the needs of high level number crunching and portable coding.
Nope, you can do the same as you do with the motorola model, if you like.
It's just very slightly different syntax.
>
<snip>
Yes, you are correct. I probably should have stopped while i was behind.
>
> DaveK
> --
> All your base are belong to us!
>
>