3 ms·

> The chip has BCD support. Circa 1980 having BCD support was not seen as insane. Most IBM systems had BCD support (due to the use of BCD for money computatio

by pwg 8y ago

> The chip has BCD support. Circa 1980 having BCD support was not seen as insane. Most IBM systems had BCD support (due to the use of BCD for money computations where the different round-off issues with binary vs base-10 are not well tolerated [1]), in fact, even the lowly 6502 (Apple II, Atari, Commodore systems) had BCD support. The computing world had not yet coalesced around base-2 binary math at the most common one to utilize, so at that time in the past what would have been likely seen as "insane" would have to have not had BCD support. This is also at the tail end of the time frame where one could still find systems with 15-bit bytes and a whole host of other "differences" from what the computing world of today looks like. [1] https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantages https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantage...

ghaff 8y ago
In fact, the latest IBM mainframe still has register-to-register BCD arithmetic. [1] As you say, by the time the 8087 came out you were starting to see some increasing standardization in computer designs (even if systems from different vendors were still incompatible). On the other hand, you still had MPPs, vector supercomputers, Lisp machines, and a bunch of different mainframe designs. [1] ftp://public.dhe.ibm.com/eserver/zseries/zos/racf/pdf/ny_naspa_2017_10_z14_overview.pdf
burfog 8y ago
Yeah but... this is an FPU. It's a floating-point unit.
- pwg 8y ago
  "floating point" does not equate to "binary". Floating point simply means that the radix point of a fractional value can be placed at any location relative to the significant digits, i.e., it can 'float'. It says nothing about how the "digits" are encoded. Decimal floating point (BCD) is a thing, and it is actually part of IEEE 754 (https://en.wikipedia.org/wiki/Decimal_floating_point https://en.wikipedia.org/wiki/Decimal_floating_point). Few today pay much attention because everything is binary floating point, but decimal floating point has advantages: "Working directly with decimal (base-10) fractions can avoid the rounding errors that otherwise typically occur when converting between decimal fractions (common in human-entered data, such as measurements or financial information) and binary (base-2) fractions." (quote is from the wikipedia article cited above). [1] When the 8087 was designed, there was more use of BCD encodings and more languages that suppored BCD encodings for numerical operations, so providing the ability to also accelerate BCD math operations was just as much a boost for the system as providing acceleration for binary math operations. The computing world was quite different, and by far far less homogeneous, thirty years ago. [1] More detail on this rounding error referenced is here: https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantages https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantage.... The tl;dr variant is that decimal coded fractional values have the identical infinite fractional decimal values (i.e. decimal representation of 1/3) as what one learns in math class in school, so most of us already intuitively know the values where errors can be introduced . Binary values have a much larger number of fractions that require infinite length binary values to represent exactly (i.e. 1/5 (.2) is one example), so one's intuition from decimal fractions no longer applies in all cases. A little trick I used to play back in the early 80's when it seemed there was a computer store on every corner and at least one IBM-PC on display was to setup a quick BASIC program to count down (subtract) from 100 by a penny (0.01) at a time. On an IBM-PC, since it's BASIC used binary floating point (and likely 32-bit FP as well), this took about 6 loops or so before the IBM-PC was printing 99.939999988733 or some such. On the Atari 800 (which at the time would often be sitting only a few feet away) the same program would count down from 100.00 to 0.00 in 0.01 steps exactly for the entire sequence (the Atari's used BCD floating point, which was why the 'trick' worked). Then for whomever was watching, I'd ask: "Which one do you want balancing /your/ checkbook?" At the time one of the often quoted reasons for "buying a home PC" was "checkbook balancing". The 'trick' still works with modern systems that use binary, one just has to ask for enough precision that the standard libraries default rounding does not hide the issue from view: fp.c: #include <stdio.h> int main(int argc, char ** argv) { double i = 100.0; printf("%.40f\n", i); i = i - 0.01; printf("%.40f\n", i); } Compile: gcc -std=c99 -o fp fp.c Run: ./fp $ ./fp 100.0000000000000000000000000000000000000000 99.9899999999999948840923025272786617279053 edit: change to be more precise in the meaning of "floating point" in first paragraph.

by pwg 8y ago

ghaff 8y ago

In fact, the latest IBM mainframe still has register-to-register BCD arithmetic. [1] As you say, by the time the 8087 came out you were starting to see some increasing standardization in computer designs (even if systems from different vendors were still incompatible). On the other hand, you still had MPPs, vector supercomputers, Lisp machines, and a bunch of different mainframe designs. [1] ftp://public.dhe.ibm.com/eserver/zseries/zos/racf/pdf/ny_naspa_2017_10_z14_overview.pdf

burfog 8y ago

Yeah but... this is an FPU. It's a floating-point unit.

pwg 8y ago
"floating point" does not equate to "binary". Floating point simply means that the radix point of a fractional value can be placed at any location relative to the significant digits, i.e., it can 'float'. It says nothing about how the "digits" are encoded. Decimal floating point (BCD) is a thing, and it is actually part of IEEE 754 (https://en.wikipedia.org/wiki/Decimal_floating_point https://en.wikipedia.org/wiki/Decimal_floating_point). Few today pay much attention because everything is binary floating point, but decimal floating point has advantages: "Working directly with decimal (base-10) fractions can avoid the rounding errors that otherwise typically occur when converting between decimal fractions (common in human-entered data, such as measurements or financial information) and binary (base-2) fractions." (quote is from the wikipedia article cited above). [1] When the 8087 was designed, there was more use of BCD encodings and more languages that suppored BCD encodings for numerical operations, so providing the ability to also accelerate BCD math operations was just as much a boost for the system as providing acceleration for binary math operations. The computing world was quite different, and by far far less homogeneous, thirty years ago. [1] More detail on this rounding error referenced is here: https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantages https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantage.... The tl;dr variant is that decimal coded fractional values have the identical infinite fractional decimal values (i.e. decimal representation of 1/3) as what one learns in math class in school, so most of us already intuitively know the values where errors can be introduced . Binary values have a much larger number of fractions that require infinite length binary values to represent exactly (i.e. 1/5 (.2) is one example), so one's intuition from decimal fractions no longer applies in all cases. A little trick I used to play back in the early 80's when it seemed there was a computer store on every corner and at least one IBM-PC on display was to setup a quick BASIC program to count down (subtract) from 100 by a penny (0.01) at a time. On an IBM-PC, since it's BASIC used binary floating point (and likely 32-bit FP as well), this took about 6 loops or so before the IBM-PC was printing 99.939999988733 or some such. On the Atari 800 (which at the time would often be sitting only a few feet away) the same program would count down from 100.00 to 0.00 in 0.01 steps exactly for the entire sequence (the Atari's used BCD floating point, which was why the 'trick' worked). Then for whomever was watching, I'd ask: "Which one do you want balancing /your/ checkbook?" At the time one of the often quoted reasons for "buying a home PC" was "checkbook balancing". The 'trick' still works with modern systems that use binary, one just has to ask for enough precision that the standard libraries default rounding does not hide the issue from view: fp.c: #include <stdio.h> int main(int argc, char ** argv) { double i = 100.0; printf("%.40f\n", i); i = i - 0.01; printf("%.40f\n", i); } Compile: gcc -std=c99 -o fp fp.c Run: ./fp $ ./fp 100.0000000000000000000000000000000000000000 99.9899999999999948840923025272786617279053 edit: change to be more precise in the meaning of "floating point" in first paragraph.