Hacker News Reader

Comment by WalterBright | Hacker News Reader

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.

Reply on news.ycombinator.com