Comment by downut
4 hours ago
"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.
I meant ignored the 80 bit floating point. I received a lot of pushback for doing 80 bit arithmetic in D.
TY. I am ignorant of the compiler side of the process here. My mental model as a former numerical algorithms guy at the time was that the x87 chips performed the 80 bit operations as opaque internal operations, and returned the visible results back as 32/64 bit IEEE754 floating point format bytes.
Is that inaccurate? If not how did you store the extra 16 bits (DP)? I should've bought a zortech compiler back in the day? ;-)
I am sorry that Borland hooked me with turbo-p and then jacked me up with turbo-c/c++.
FLD and FSTP have opcode variants that load/store 10 bytes from/to a memory address.
Downside is, of course, 10 bytes is a fairly awkward size; it is not nearly as fast as 32/64 bits to move in and out, plus it -has- to be memory (i.e. can't just borrow another register) and then the potential impacts around alignment of data structures/etc to consider.
TurboC generated very fast code. Up to a point. As the program got larger, the execution speed slowed down. This was puzzling, as TurboC didn't generate very good code. Until I discovered that the TurboC runtime library was implemented in carefully hand-coded assembler. This gave small programs (i.e. benchmark programs, the only programs that mattered) a big boost in speed! It was a smart move by Borland.
Zortech's `long double` was 80 bits. In D, the `real` type is 80 bits. Sadly, that isn't available on the AArch64 processor.