Possible bug in atomicOp

[Don]

Don wrote:
> Robert Jacques wrote:
>> On Sat, 23 Oct 2010 15:50:30 -0400, Sean Kelly 
>> <sean at invisibleduck.org> wrote:
>>>>>
>>>>> Basically, atomicLoad (which atomicOp uses) always returns in ALU
>>>> > registers.
>>>>> Floating point numbers need to be returned in floating point
>>>> > registers.
>>>>> Therefore, a NaN always gets returned from atomicLoad!double, and a
>>>> > NaN isn't
>>>>> equal to anything.
>>>>
>>>> So shouldn't there be a static assert to prevent one from using
>>>> atomicOp with floats and doubles? Or should atomicLoad be implemented
>>>> to support floats and doubles?
>>>
>>> The former in the short term and the latter in the long term.
>>
>> Well, here's the assembler to load a value onto the FP stack:
>> float  __int2float  (ref int  x) { asm { fld float  ptr [EAX]; } }
>> double __long2double(ref long x) { asm { fld double ptr [EAX]; } }
> 
> That should be:
> fild dword ptr [EAX];
> fild qword ptr [EAX];
> 
>> Unfortunately, direct loading from a register doesn't seem to be 
>> supported. So writing wrapper code which uses a union would be almost 
>> as fast. I know there is an SSE instruction to load directly from 
>> registers, but we can't assume SSE support.

Wait a minute. x86 has no read-modify-write instructions for x87, or for 
SSE. So I don't think it's possible to implement atomic floating-point 
ops, apart from assignment.
(Of course, you can fake it with a mass of casts and a CAS, but that 
doesn't seem helpful).
It should just be prevented, except possibly for assignment. (Is an 
80-bit float assignment atomic? Maybe not, since it would need special 
logic).