Re: libcaps thread testing code committed

[sander <sander@xxxxxxxxxxxxxxxxxxx>]

On Mon, 8 Dec 2003, David Leimbach wrote:

>
> On Dec 8, 2003, at 10:33 AM, Sander Vesik wrote:
>
> > Craig Dooley <cd5697@xxxxxxxxxx> wrote:
> >> I dont think this will work. Anything before the pIII did not have
> >> SSE,
> >> so PPro, PII, old Xeons are now useless?  Also, even the pIII only had
> >> SSE, not SSE2, so there is no way to do double precision floating
> >> point
> >> with just SSE.  Any Athlon before they went to XP I believe does not
> >> have SSE, and I think there might also be no SSE2 in AMD Chips except
> >> Athlon64 and maybe Barton.  I dont think this many CPU families can be
> >> dropped.  They will have to be supported though.
> >
> > Worse, K8 is the first AMD processor that has SSE2, similarily several
> > of the minority x86 processors don't have it. So this is basicly a bad
> > idea.
>
> Yeah... sometimes you actually do want double precision floating point
> to work :).
>
> That's the problem with Altivec... even on the G5 it doesn't do double
> precision.  Luckilly
> PowerPC has a pretty good floating point unit anyway.
>

yes, the need for SSE2 style FPis less on ppc as you already have a flat
32 register space for floating point. So having two floationg point units
(like alpha had) is in such a scenario in most cases better and more
flexible than having 128 bit 2-wide fp SIMD instructions. There are of
course many reasons why a 256bit Altivec2 would make sense (wheteve as a
separate reg file or as altivec1 operating on bottom bits), but a 2-wide
double prec fp extension to Altivec1 would imho not really make sense.
Just having a second FP and Load/store uint would be not much more
expensive but give more benefits.


	Sander

+++ Out of cheese error +++