jbs@WATSON.IBM.COM (05/22/91)
Richard O'Keefe says:
Given that the same posting has already beaten Herman Rubin over the
head with the IEEE standard, this doesn't go down well. IEEE extended
precision (and the IEEE standard does recommend that it be provided)
uses 64-bit signifcands, so a "full" implementation of IEEE 754 would
include a 64x64 multiplier, not a 53x53 one. Don't the 80387 and the
68882 chips offer extended precision? What size of multiplier do they
use?
Let me explain what I meant. When I stated that the IEEE
standard has become so entrenched that manufacturers are effective-
ly forced to use it, I was referring primarily to the representa-
tion of 32 and 64 bit floating point numbers and secondarily to the
way floating arithmetic (in round to nearest mode) is defined to
work. I do not believe the entire standard is so entrenched.
In any case, is it not the case that the IEEE standard for
extended requires at least 64 bits in the fraction (not 64 bits)?
If so a 128 bit format (a much more sensible length than 80) with
106 bit fractions could utilize a 53X53 multiplier. Also does the
standard recommend that extended be provided in hardware?
James B. Shearerhenry@zoo.toronto.edu (Henry Spencer) (05/22/91)
In article <9105220041.AA14355@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes: > Let me explain what I meant. When I stated that the IEEE >standard has become so entrenched that manufacturers are effective- >ly forced to use it, I was referring primarily to the representa- >tion of 32 and 64 bit floating point numbers and secondarily to the >way floating arithmetic (in round to nearest mode) is defined to >work. I do not believe the entire standard is so entrenched. By and large it is. But you have to understand that the standard does allow some flexibility. In particular, you can be completely conforming with 32-bit numbers plus some kind of extended format for them, so many penny-pinching manufacturers say that 64-bit numbers are the extended 32-bit format rather than a second "fully supported" format. This is within the letter of the law. Unfortunately. (Well, maybe I am too harsh. Having IEEE behavior for 32 and 64 is a lot better than having, say, 370 floating point. But having an extended format for 64 too is even better.) -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (05/23/91)
In article <9105220041.AA14355@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes: |> |> Richard O'Keefe says: |> Given that the same posting has already beaten Herman Rubin over the |> head with the IEEE |> Let me explain what I meant. When I stated that the IEEE |> standard has become so entrenched that manufacturers are effective- |> ly forced to use it, But, the reason that the standard is so entrenched is that it is so useful! Manufacturers are forced to use it because users have requirements for it. What has gotten lost in this discussion is that IEEE floating point has been a tremendous boon to both users and the industry. IEEE is important to users for two reasons: 1) It is a standard. It is very important to certain users to be able to move binary data between machines without conversion. It has also become a reference standard which can be incorporated in other interoperability uses, such as XDR, the same way that ASCII became useful in telnet, for example. While this applies mainly to the representation, it is also the case that the arithmetic definition itself is very useful, because it implies that in most reasonable cases, you will get exactly the same answer on different machines when you move your program. I wish that Cray would use it. There are always programs which run on the ragged edge of precision, and which don't work right on a slightly poorer implementation. 2) IEEE is very well behaved, compared with other representations. I won't bother to substantiate this, other than to state that many experts agreed at the time it was developed that there was no known way to improve it numerically. Users and industry have both benefitted tremendously, because it has permitted standard parts to find their way into low cost PC's and workstations. The down side of IEEE is a performance hit in heavily pipelined FP units, for some input values. On the other hand, it is nice to get the right answer, even if some cases slow down. The usefulness of IEEE to support extended precision integer arithmetic is of interest, but, with today's technology, there is probably a better way to support thiis. It would not be difficult to put in a 32x32 -> 64 integer double length multiplier. As has been noted, in the CDC 6600, the fp unit could be used to multiply 48 bit significands and get 96 bit results. I believe that machines of that vintage used 10-30K gates for such a multiplier. Surely such a double length multiplier, which is what is needed to support extended precision arithmetic, would not be too many extra gates in one of those new 1.5 Million transistor chips? Even a 64 bit double length multiplier won't be that big a deal in the near future. I figure it ought to take less than 100K transistors for a fast 64 bit double length multiplier. Since some vendors are claiming they won't know what to do with all 10 Million transistors/chip available in 1995, adding an extra 1% should not be a big deal. |> James B. Shearer -- Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-1056 #include <std.disclaimer>
henry@zoo.toronto.edu (Henry Spencer) (05/23/91)
In article <1991May22.221824.16887@riacs.edu> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >The down side of IEEE is a performance hit in heavily pipelined FP units, for >some input values... Of note in this connection is the AMD 29050's "sloppy" mode. (Well, they don't call it that. :-)) This treats all denormalized numbers as zero, and generates a zero whenever you would normally get a denormalized number. So the user gets a choice: if he really wants the highest possible speed, or highly predictable speed without data-dependent delays, he can turn on sloppy mode. On the other hand, if he merely wants the right answer :-), he can use IEEE-standard arithmetic. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
jimp@cognos.UUCP (Jim Patterson) (05/23/91)
In article <1991May22.221824.16887@riacs.edu> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >1) It is a standard. It is very important to certain users to be able to >move binary data between machines without conversion. This isn't quite correct. While IEEE specifies quite a bit about the format of its floating point representations, it leaves unsaid a few details such as endian-ness. The 80x87 chips, for example, follow INTEL convention and represent floats in little-endian format (the sign bit is at the highest address, not the lowest). Representations of the extended precision formats are also not pinned down; 80x87 uses 80 bit extended while other implementations e.g. HP-PA use a 128 bit extended precision. (This is an internal format, though; not a lot of need to transfer it around between machines). So, while you might get by with doing at most a byte-swap to move IEEE floats around, you can't blindly assume that all IEEE floats are the same. -- Jim Patterson Cognos Incorporated UUNET:uunet!cognos.uucp!jimp P.O. BOX 9707 BITNET:ccs.carleton.ca!cognos.uucp!jimp 3755 Riverside Drive PHONE:(613)738-1440 x6112 Ottawa, Ont K1G 3Z4