daw@cbnewsh.ATT.COM (David Wolverton) (05/03/90)
In article <1990Apr25.162502.5977@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <4328.263076F2@puddle.fidonet.org> CSPW.RURES@p0.f4.n494.z5.fidonet.org (CSPW RURES) writes: > >1. Does ANSI C say anything about IEEE arithmetic? > > Basically, no. Alas. Which means that you are stuck with whatever your > supplier gives you, and you will have to consult his manuals to find out > just what that is. With one or two exceptions (Apple), the suppliers have Also Sun (since at least SunOS 3.?) and AT&T (since SVR3). > not been good at complete and correct support of IEEE arithmetic. Dave Wolverton att!attunix!daw
dneff@garth.UUCP (David Neff) (05/04/90)
Not being a Sun expert, I'm limiting my comments to the IEEE spec. In article <1990Apr27.173218.19870@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >(1) Where's the support for extended-format variables? > >(2) Where's the support for extended format *at all* with the high-speed > floating-point add-ons? Extended format is not optional in IEEE! If I'm not mistaken, extended precision is not required for IEEE conformance. And in any case, double precision is a perfectly conforming representation for single extended. Here's the relevent text (remember that `shall' means a conforming implementation *must* support the feature, `should' means that a conforming implementation need not support the feature): From section 3.4: All implementations conforming to this standard shall support the single format. Implementations should support the extended format corresponding to the widest basic format supported, and need not support any other extended format. This tells me that an implementation can be fully conforming even if it only supports single precision. And that an implementation can also conform if it supports only single and double precision. From section 3.3: An implementation of this standard is not required to provide (and the user should not assume) that single extended have greater range than double. Given the language I quoted from Section 3.4, I read the `shall's elsewhere in Section 3.3 as describing the requirements of the extended formats *if you have them*, not as requiring that you have them. This is much like Section 8 that says that traps are only a `should' feature but if you have them they `shall' appear as described. Finally, Table 1 shows that the format parameters for single extended are indeed met by double precision. I agree that trouble occurs if a vendor claims to support IEEE extended forms (beyond the degenerate single extended = double case I mentioned) but doesn't provide ways to get at them. But conformance can be achieved simply by backing off from such a claim. And, more subtly, that also means *not* leaving intermediate expression values in extended precision from one operation to the next. Another issue that's been hinted at in this thread is support for NaNs. As I read the standard, a conforming implementation need not preserve one of the input NaNs. It is only required to produce some quiet NaN. From section 6.1 (again, note `should's and `shall's): Every operation involving one or two input NaNs, none of them signaling, shall signal no exception but, if a floating-point result is to be delivered, shall deliver as its result a quiet NaN, which should be one of the input NaNs. -- UUCP: {pyramid,sri-unix,ingr}!garth!dneff USPS: Intergraph APD, 2400 Geng Road, Palo Alto, Ca, 94303 AT&T: (415) 852-2334
meissner@osf.org (Michael Meissner) (05/05/90)
In article <272@garth.UUCP> dneff@garth.UUCP (David Neff) writes: | Not being a Sun expert, I'm limiting my comments to the IEEE spec. | | In article <1990Apr27.173218.19870@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | >(1) Where's the support for extended-format variables? | > | >(2) Where's the support for extended format *at all* with the high-speed | > floating-point add-ons? Extended format is not optional in IEEE! | | If I'm not mistaken, extended precision is not required for IEEE | conformance. And in any case, double precision is a perfectly | conforming representation for single extended. If it were otherwise, then the MIPS and 88k implementations would be illegal, since they only have single and double precision. It's been a long time, since I read 754, but I can't recall where it talks about the format of any but single and double precisions. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
tneff@bfmny0.UU.NET (Tom Neff) (05/08/90)
Actually I'm a little disappointed that vendors (even Intel's own iC86/286) don't appear to support the IEEE 80-bit real format (a la PL/M TEMPREAL or assembler 'DT 1.2E+34'). You pick these processors, read all the lavish documentation talking about their special features, then they don't let you at them. I understand how everything has to be dumbed down and have happy faces painted on it for the glorious new future of standardization, but sometimes in the trenches I wish these things were still designed by dweebs so that ugly, dweebish, necessary jobs were easier to do.
henry@utzoo.uucp (Henry Spencer) (05/10/90)
In article <15466@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Actually I'm a little disappointed that vendors (even Intel's own >iC86/286) don't appear to support the IEEE 80-bit real format... >... I understand how everything has to be >dumbed down and have happy faces painted on it for the glorious new >future of standardization... The problem is not standardization; this is exactly what ANSI C "long double" is for. ANSI C is weak on IEEE arithmetic support in some other areas, but this at least they got right. The problem is lazy vendors. The solution, or at least the beginning of it, is: !!COMPLAIN!!. To the vendor, not to the net. -- If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry henry@zoo.toronto.edu