mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (02/25/91)
In article <45758@mips.mips.COM>, cprice@mips (Charlie Price) writes: >By the way, even if someone implements 80-bit FP (we don't), >nobody I know of *stores* 80 bits in memory or on disk. Just about any architecture which uses 80-bit FP has a way of storing 80 bits. Otherwise, a context switch has desastrous effects (Undeterministic loss of precision between computations. ;-) Actually, there once was such a multi-tasking beast (from Honeywell, I think) which had 80 bit fp (or whatever) in the FPU, but did not allow saving of the extra precision bits. Now programs would give results based on the scheduling behavior of the OS. PS: Any other stories of completely brain-dead architectures? Michael K. Gschwind, Institute for VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door mike@vlsivie.uucp 5-6-7-8 innovate don't litigate e182202@awituw01.bitnet 9-A-B-C interfaces should be free Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go! Fax: (++43).1.569697
mac@eleazar.dartmouth.edu (Alex Colvin) (02/26/91)
>Just about any architecture which uses 80-bit FP has a way of storing 80 >bits. Otherwise, a context switch has desastrous effects >(Undeterministic loss of precision between computations. ;-) Actually, >there once was such a multi-tasking beast (from Honeywell, I think) >which had 80 bit fp (or whatever) in the FPU, but did not allow saving >of the extra precision bits. Another Urban legend... The GE635 (later Honeywell) did use three architectural registers as an 80 bit FP accumulator, but used 72 bits in floating stores. However, a context switch stored the registers, all 80 bits worth.