upvote
Back in the day, the 8087 and 80287 were supported by quite a bit of software (spreadsheets, statistics, etc...). First dev job I had (was 15 at the time), I had to recalc our accountants 1-2-3 models because I had a 80287 in my AT clone... and that resulted in a "hell yes" a year later when I asked for a 386 + 387. I put on the write up on why I needed it was a) it would compile faster and when needed I b) could recalc financial models faster. That model took maybe 5 minutes with the 287 and maybe 40 sec on the 386+387 setup... I suspect the generous 4mb of RAM was more important... I never really understood why people wouldn't shell out the extra couple hundred bucks on the math coprocessors, they really sped things up provided that software supported them.
reply
"numerics people ignored it"

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.

reply
I mean, the 8087 was the primary influence on IEEE 754, and hence all of modern floating-point, so in that sense, the numerics people don't ignore it.

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.

reply
The 8087 came out when the premier numerics processors worldwide were the various Cray/CRI products, and if you know this much about the 8087's extended register format then it's likely you already know about Seymour's opinion expressed in silicon about the handling of the LSBs. As a freshly minted computational mathematician I was worried about the Cray systems accuracy on long running computations but after 5 years right on the front lines of the 1-4 highest throughput systems worldwide, with, ISTR, zero practical effect on any computation that ever mattered. Huh turns out Seymour was smarter than me. Should've picked up a shovel.

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.

reply
Sun wanted the jvm to "replicate exactly" between machines so they chopped off the precision of all intermediate operations to 64 or 32 (double/single) which infuriated kahan
reply
Aha! TY. Sun's floating point people were world class but I still think this was a dumb thing to do.

With the NAS Parallel Benchmarks we were trying to encourage as wide a diversity of hardware and algorithms as possible so we were lenient with the acceptable "valid" interval of "correct" behavior. I've already discussed heretical Cray FP. Those were fantastic systems. No way would we disqualify some weird/different algorithm/architecture if it meaningfully advanced the SOA in performance/efficiency. OTOH wars were fought over having any firm accuracy requirements at all. So this jvm thing looked... pointless at best?

This is all nostalgia for a past that actually was. Those were the days my friends.

reply
> 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)

My compilers behaved properly.

reply
That was win64, not win32. My mistake.
reply