Useless SSE instructions

[ewmayer]

[reviving this too-long-dormant thread]

Originally Posted by __HRB__

Synthesizing AND-NOT requires two instructions, so PANDN can be twice as fast. If you need NOT, you can do that with XOR in one instruction, using a memory operand and a location filled with FFFF, if you're experiencing register pressure.

OK, but why does the ISA give us not one but *two* separate instructions - PXOR and XORPD - to do exactly the same thing (a whole-xmm-register bitwise XOR), but neither a logical (1s-comp) nor arithmetic (2s-comp) NOT of any kind?

[bsquared]

Originally Posted by ewmayer

[reviving this too-long-dormant thread]



OK, but why does the ISA give us not one but *two* separate instructions - PXOR and XORPD - to do exactly the same thing (a whole-xmm-register bitwise XOR), but neither a logical (1s-comp) nor arithmetic (2s-comp) NOT of any kind?

Hear-hear! I got a few more gray hairs over lack of NOT a while ago. WTF.

[Brian Gladman]

Originally Posted by bsquared

Hear-hear! I got a few more gray hairs over lack of NOT a while ago. WTF.

It is so sad that it was the x86 architecture and not the 68000 architecture that captured the market. The 68000 architecture was designed whereas the x86 architecture has been an unholy mess for as long as it has existed.

Repeated cycles of messy design decisions bolted on earlier mess has now produced a need for backwards compatibility that is so strong that all attempts to produce something better have inevitably failed in mass market terms.

It seems we will never escape this abomination :-(

[retina]

Originally Posted by Brian Gladman

It seems we will never escape this abomination :-(

If and when the tablets and smart phones finally push out the desktop and laptop markets then we will all be using ARM. Let's just hope the MSs latest x86 "surface" fails and sanity prevails with ARM taking over.

[ewmayer]

Originally Posted by Brian Gladman

It seems we will never escape this abomination :-(

Is "abomination domination" a marketing buzz-phrase?

It should be.

[ewmayer]

Closely related to Useless SSE Instructions is the category "SSE Instructions Which Would Be Useful But Which Are Inexplicably Absent". Onesuch which has caused me annoyance this day is the lack of anh SSE Instruction to perform floating-double <--> 64-bit integer conversions. I have an application whose outputs are packed-double (xmm-register) representations of 50-bit nonnegative ints, which I need to convert to integer form for further manipulation as 64-bit ints.

I am thinking of emulating the missing conversion by taking advantage of the 50-bit normalization, like so:

0. Star with the outputs in packed-double form;

1. Add (packed double)2⁵⁰ to each to yield identical exponent fields, effectively "aligning the hidden bits", which allows us to use a constant set of mask and shift parameters in the ensuing step;

2. Now treating the operands as packed 64-bit ints, do some simple integer-mask magic to mask off the IEEE-double exponent bits and right-justify the mantissas. This would also wipe away the extra power 2⁵⁰ we added in step [1].

Does anyone know if the operand/operation-type-mixing which occurs in step [2] will impose a significant cycle penalty? Any other ideas - not necessarily SSE-based - for efficiently doing the above type conversions are also welcome.

[Prime95]

Originally Posted by ewmayer

Does anyone know if the operand/operation-type-mixing which occurs in step [2] will impose a significant cycle penalty? Any other ideas - not necessarily SSE-based - for efficiently doing the above type conversions are also welcome.

IIRC, most Intel CPUs have a one clock penalty for moving an operand from the FPU to the integer units.

[retina]

Originally Posted by ewmayer

1. Add (packed double)2⁵⁰ to each to yield identical exponent fields, effectively "aligning the hidden bits", which allows us to use a constant set of mask and shift parameters in the ensuing step;

If you add 2⁵² instead then you only need the mask and can eliminate the shift.

[ewmayer]

Originally Posted by Prime95

IIRC, most Intel CPUs have a one clock penalty for moving an operand from the FPU to the integer units.

That would be of the very-acceptable variety.

Originally Posted by retina

If you add 2⁵² instead then you only need the mask and can eliminate the shift.

Yes, the same thought occurred to me in the shower this morning - so just a single masking operation will suffice.

Time to code it and time it...