[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: i386 floating point expertise needed
> We need someone with i386 floating point knowledge (and I mean, deep down
> low, what every instruction is supposed to do, and how it is supposed to
> be used, including all the surrounding support flags words and whatever)
> to have a look at this, and work out what the problem is.
> I have not been following, but I do know the 386 from years ago.
I used to have such knowledge. Unfortunately, I don't know Unix-style
386 assembly, having gained that knowledge in the x86 commercial
world; but I don't think that's needed.
The problem is that the 386 does computations with 80-bit numbers, not
The compiler has evidently optimized out a store that would have forced the
If you don't save the intermediate computations to a double, the spare bits
I did not see the full code sequence posted, but it's clear that although
64-bit values may be bit identical, the 80-bit intermediate that was used to
compute one of them is not. (I can see that on the stack dump.) The 16 LSBs
could not be non-zero unless that's a value that was computed and left on
the stack. With the 386, this is an important optimization for performance;
but it can cause exactly this kind of problem.
AMD64 doesn't use 80-bit intermediates, so this issue doesn't arise.
Main Index |
Thread Index |