On 8/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > I think you're running too far with your sarcasm. SSE's instructions do > not go so far as to specify integer vs. floating point. To me, "ps" > means "32-bit SIMD", independent of integerness. Excuse me if i'm amazed being replied bitwise ops on floating values make no sense as the justification for breaking something that used to work and match hardware features. I naively thought that was the purpose of that convenient extension.
> > So, that's what i feared... it was intentional. And now i guess the only > > sanctioned access to those ops is via builtins/intrinsics. > No, you can do so with casts. Floating-point to integer vector casts > preserve the bit pattern. For example, you can do Again SIMD ops (among them bitwise stuff) comes in 3 mostly symmetric flavors on x86 namely for int, float and doubles; "casting" isn't innocuous because there's a penalty for type mismatch (1 cycle of re-categorization if i remember for both k8 and core2), so it's either that or some moving around. Let me cite "Intel(r) 64 and IA-32 Architectures Optimization Reference Manual", 5-1, "When writing SIMD code that works for both integer and floating-point data, use the subset of SIMD convert instructions or load/store instructions to ensure that the input operands in XMM registers contain data types that are properly defined to match the instruction. Code sequences containing cross-typed usage produce the same result across different implementations but incur a significant performance penalty. Using SSE/SSE2/SSE3/SSSE3 instructions to operate on type-mismatched SIMD data in the XMM register is strongly discouraged." You could find a similar note in AMD's doc for the k8.
