Comment by downut
5 hours ago
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.