[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IEEE float co-processors
- To: firstname.lastname@example.org
- Subject: IEEE float co-processors
- From: email@example.com (Richard Fateman)
- Date: Mon, 27 Jan 86 23:08:19 PST
- Cc: firstname.lastname@example.org
in CLtL p193-194 it is stated that an operation combining a short float
with a long results in a long. Presumably if you combine
a short + a single you get a single. But how precise is the intermediate
Is it OK to do the arithmetic in "long", or MUST you do the arithmetic
no more precisely and with no larger range than "single"?
Consider any of a number of existing and proposed
co-processors in which all arithmetic is in fact done in, say, 80 bit units.
A single * short * short then stored to a single
would be done by converting each argument to a long, multiplying
and rounding to single. This is faster than any other method using most
Unfortunately, it might get an answer better than that prescribed by following
CLtL strictly. Using the method on p 194, one can come up with problems
where intermediate arithmetic done in single might overflow, underflow,
or lose precision disasterously, (or all of these) before the final,
exactly-single-representable answer is computed.
I believe the standard should allow the processor to perform all floating
point arithmetic computations in highest precision, and not require
multiple conversions (from short to single to double to long).
The paragraph which allows rearrangement or conversion to the longest
format IN THE EXPRESSION is not flexible enough to quite allow this.