Hacker News
The Intel 8087 chip: floating-point addition and subtraction
WalterBright
|next
[-]
I've always been proud to support the 8087 with my compilers, and am baffled why the numerics people ignore it.
downut
|root
|parent
|next
[-]
I dunno Walter but as the first(?) IEEE754 implementation in a PC system it seemed like a pretty damn big deal to us people working in numerical algorithms. It was a big enough deal to me at the time (I was in graduate school) that I've kept my 8087 chip all my life and have it before me now. I see the old boy has lost a pin during the last move, dammit.
Chip has "3716150AA MALAY BEV 22" embossed on the pin side. Search gets me nothing.
jcranmer
|root
|parent
|next
|previous
[-]
The main problem with the x87 floating-point unit is that it only properly works on a weird 80-bit floating-point type that doesn't have the properties you expect of regular IEEE 754 floating-point types, thanks to the explicit integer bit. The design makes it hard to properly emulate the more common 32-bit and 64-bit single and double-precision floating-point arithmetic bit-equivalently, and this is compounded by many compilers' decision to spill floating-point registers incorrectly (they're spilled as 32-bit or 64-bit, not 80-bit), which makes the numerical results of your program effectively random. Also, the size of the 80-bit types isn't really conducive to vectorization, so the floating-point unit gets left behind as SIMD programming starts to become more important.
So what happens is that the x87 is essentially the last of the pre-IEEE 754 floating-point systems that's still hanging around. A lot of the features that would make it interesting in an environment where every vendor has a different floating-point system are now just vestigial weirdness in a world where everybody is following the same floating-point system, and not worth supporting.
downut
|root
|parent
|next
[-]
As far as delivered accuracy of the 8087, performing the operations at 80 bits, rather than 64 it was better than non-extended formats. Anyway you can read all about it here:
https://en.wikipedia.org/wiki/Extended_precision#x86_extende...
Kahan endorsed is all I needed to know.
I can't remember the details from back then but the initial Sun java implementation did something weird with this.
dsign
|next
|previous
[-]
jart
|root
|parent
|next
[-]
kens
|next
|previous
[-]
jakzurr
|root
|parent
|next
[-]
russdill
|root
|parent
|next
|previous
[-]
chj
|root
|parent
|next
|previous
[-]
bonzini
|root
|parent
[-]
They definitely were used back in the day, now the x87 isn't used much at all.
bonzini
|root
|parent
|previous
[-]
kens
|root
|parent
[-]
bonzini
|root
|parent
[-]
rep_lodsb
|root
|parent
[-]
So FSTSW AX was handled by the CPU microcode, which would read the status word from a reserved I/O port and put it into AX.
The 386 was even more tightly integrated, with some of the FPU state duplicated inside the CPU, so that it could store it to memory in different formats depending on whether it was currently in 16- or 32-bit mode.