zalman@mips.com (Zalman Stern) (06/08/91)
In article <14775@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: >jbs@WATSON.IBM.COM writes: >>If your chip has 80 bit registers I fail to see how you can avoid >>performing 80 bit loads and stores while saving and restoring these registers. > >Other people have managed in the past. Perhaps you are insufficiently >imaginative. The only problem comes when "machine epsilon" computed >in registers does not match the "machine epsilon" stored in memory. >Otherwise, it is a big help when accumulating into a register (as in >inner product, for example) since the extra bits are most helpful in >guarding against lost precision. > >I'm not certain I remember this correctly, but I recall that friends >at Rice had this "problem" with a compiler that they wrote for a >machine called the "PC/RT". Note that the same problem ("excess >precision") occurs on the RS/6000 in certain situations. The IBM PC/RT did not have floating point support in its processor architecture. There were three hardware acceleration options: a board using the National Semiconductor 16081 (I think that's the number, it was the FP chip for the 16032), a board based on some Weitek chip (the Advanced FPA board), and the Motorola 68881 which was included on the processor board of later models in the line. I'm not sure which of these pieces of hardware caused the problem you describe. It was hard to believe how hokey floating point was on this machine. In addition to the hardware choices, there was a software emulator as well. It was indeed possible to get different results depending on what kind of FP support you were using. IBM eventually implemented an abstract language that the compiler generated. At runtime, your program jumped into some magic code in the kernel which converted the abstract language into code for whatever kind of FP hardware you were using. The 16081 board was extremely flakey and would produce incorrect results when it failed. Of course the diagnostics didn't check this so the machine would boot and ran fine. This prompted one programmer to add code like "if (2.0 * 2.0 != 4.0) {fprintf(stderr, "Floating point doesn't work, exiting.\n"); exit(1);}" to his mail reader. (And believe me, at the time, you didn't have to worry about the compiler optimizing it out...) On top of this, the NAt. Semi. chips was hideously slow. The Motorola and Weitek accelerators were at least competitive for a while. Given the extreme failure of FP in the RT, the RS/6000 team vowed not to make the same mistake again. Some might say they over compensated a bit :-) -- Zalman Stern, MIPS Computer Systems, 928 E. Arques 1-03, Sunnyvale, CA 94088 zalman@mips.com OR {ames,decwrl,prls,pyramid}!mips!zalman (408) 524 8395 "So you see, what we can do is try something new / If you're crazy too I don't really see why can't we go on as three" Triad By David Crosby