20120703, 20:10  #34 
∂^{2}ω=0
Sep 2002
República de California
3×5^{2}×149 Posts 
[reviving this toolongdormant 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 wholexmmregister bitwise XOR), but neither a logical (1scomp) nor arithmetic (2scomp) NOT of any kind? 
20120703, 20:35  #35  
"Ben"
Feb 2007
6256_{8} Posts 
Quote:


20120703, 20:53  #36  
May 2008
Worcester, United Kingdom
523 Posts 
Quote:
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 :( 

20120704, 01:14  #37 
Undefined
"The unspeakable one"
Jun 2006
My evil lair
13×419 Posts 
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.

20120704, 02:07  #38 
∂^{2}ω=0
Sep 2002
República de California
3×5^{2}×149 Posts 

20120707, 02:15  #39 
∂^{2}ω=0
Sep 2002
República de California
10101110100111_{2} Posts 
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 floatingdouble <> 64bit integer conversions. I have an application whose outputs are packeddouble (xmmregister) representations of 50bit nonnegative ints, which I need to convert to integer form for further manipulation as 64bit ints.
I am thinking of emulating the missing conversion by taking advantage of the 50bit normalization, like so: 0. Star with the outputs in packeddouble form; 1. Add (packed double)2^{50} 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 64bit ints, do some simple integermask magic to mask off the IEEEdouble exponent bits and rightjustify the mantissas. This would also wipe away the extra power 2^{50} we added in step [1]. Does anyone know if the operand/operationtypemixing which occurs in step [2] will impose a significant cycle penalty? Any other ideas  not necessarily SSEbased  for efficiently doing the above type conversions are also welcome. 
20120707, 03:27  #40 
P90 years forever!
Aug 2002
Yeehaw, FL
15273_{8} Posts 
IIRC, most Intel CPUs have a one clock penalty for moving an operand from the FPU to the integer units.

20120707, 04:35  #41 
Undefined
"The unspeakable one"
Jun 2006
My evil lair
13×419 Posts 
If you add 2^{52} instead then you only need the mask and can eliminate the shift.

20120707, 17:43  #42  
∂^{2}ω=0
Sep 2002
República de California
3×5^{2}×149 Posts 
Quote:
Quote:
Time to code it and time it... 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Posts that seem less than useless, or something like that  jasong  Forum Feedback  1050  20190429 00:50 
Fedora gedit for bash has become useless  EdH  Linux  11  20160513 15:36 
Useless DC assignment  lycorn  PrimeNet  16  20090908 18:16 
Useless p1 work  jocelynl  Data  4  20041128 13:28 