I was responsible for the Turbo C (later Borland C/C++) run-time library in the late 80s and early 90s.
Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.
It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.
Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.
Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.
Hi David, thanks for the kind words. I still have the source for that I think, it was written around 1984 originally for a project of my own, then sold to Logitech, Zorland, and Borland (before I went to work for Borland). The Borland one was probably tweaked a bit - like you my memory does not include details.
There were 7 registers to play with. AX, BX, CX, DX, SI, DI, and occasionally BP. MS-DOS had no rules about frame pointer although later Borland would prefer it was kept to a standard use so that exceptions can be handled.
It would have run faster in 32 bit. Many fewer cross products for multiply and faster convergence for division and sqrt, plus just fewer registers needed. But updating the entry and exit code may have been the largest win. By the mid 1990s the FPU was moving onto the CPU chips even at the low end so the main goal would have been stability and backwards compatibility.
I wrote assembly code for many machines before and after that. In the early days such careful juggling of registers was routine. I generally wrote my algorithms in Pascal (later in Modula or Ada and by Borland days, in C++) and then hand compiled down to assembly. That separation of algorithm and coding stopped it getting too tangled.
Thanks for the shout out! These days I write System Verilog (algorithms modelled with C++) for hardware projects, and Julia for the pure software.
More specifically there are two components to this question - it being OK for the code to be released, and the code itself being available to be released :). I'm specifically asking after the former; if noone knows where the code actually is right now, well, it can be dug out later.
Nice idea, but I honestly don't think it has much value for study. It was a solution to a problem which is no longer important, and what impressed David (and was fun for me) was implementing it under constraints (8086) that are no longer relevant. I would vote for some of the other stuff mentioned by others, like TeX as an example of mastery of both the application requirements with beautiful algorithms and inspirational documentation, PostgreSQL as a thriving large system with brilliant modularization that has enabled research, or LLVM as a pinnacle of code generation which has enabled a golden era of language and hardware design over the last 20 years.
Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.
It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.
Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.
Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.