Abnormal normalizations?

[D. Hugh Redelmeier]

[This is an old thread -- I'm behind in my mail]

| Date:     Mon, 22 Nov 93 14:49:12 GMT
| From: Doug Gwyn (ACISD/MCSB) <gwynaBRL.MIL>
| Message-Id:  <9311221449.aa09586aVGR.BRL.MIL>
| 
| More to the point, some f.p. representations may be in registers and
| some in RAM, and the number of bits of precision can differ depending
| on which kind of storage has been allocated to the variable (or
| intermediate result, in the midst of a computation).  I am told that
| there are actual computers like this.  Thus, some bits can be "scraped
| off" when a quantity represented in a register passes through a memory
| "knothole", and naturally the skinny value may not compare equal to
| the original wider value.

By my reading of the standard, this isn't clearly legal.  Extra
precision is legal in intermediate computations, but not after an
assignment or cast.

There are actually three distinct but related attributes: type,
representation, and precision-and-range.  The standard nails down
the type, but it allows latitude in the precision-and-range.  As
long as the as-if rule is satisfied, representation is only the
business of the implementation.  In the following, I will use the
old X3J11 section numbers.

[3.2.1.4: Floating Types]

	When a float is promoted to double or long double, or a double
	is promoted to long double, its value is unchanged.

	When a double is demoted to float or a long double to double or
	float, if the value being converted is outside the range of values
	that can be represented, the behavior is undefined.  If the value
	being converted is in the range of values that can be represented
	but cannot be represented exactly, the result is either the nearest
	higher or nearest lower value chosen in an implementation-defined
	manner.

[from 3.2.1.5: Usual Arithmetic Conversions]:

	The values of floating operands and of the results of floating
	expressions may be represented in greater precision and range
	than that required by the type; the types are not changed
	thereby [30].

	Note 30: The cast and assignment operators still must
	perform their specified conversions, as described in 3.2.1.3 and
	3.2.1.4.

I think that these clearly show intent, but language lawyers can
argue an implementation that does have extra precision-and-range
sometimes still could be following the rules.  The reason is that
the standard doesn't actually specify what precision is and how it
is to be measured.  There seems to be no connection between the
model of FP described in 2.2.4.2.2 Characteristics of Floating Types
<float.h> and the sections quoted above.

While we are looking at the above two readings from scripture, it is
interesting to try to fit them in with:

[from 3.3.4 Cast Operators]:

	A cast that specifies no conversion has no effect on the type or
	value of an expression.

I think that (double) (1 / 3) should push the result through the
knothole, even though it does not change the type.  I'm not sure
whether this specifies a conversion.

| From: johnlaiecc.com (John R Levine)
| Cc: ncegaiecc.com
| In-Reply-To:  <9311221449.aa09586aVGR.BRL.MIL>; from "Doug Gwyn" at Nov 22, 93 2:49 pm
| 
| |I am told that there are actual computers like this.
...
|
| No kidding -- I'm typing this on one of them, a 486.
| 
| This is not quite as capriciously brain damaged as it seems.  The '87
| has 80 bit registers and only one FP format in a register, extended.
| When you store something to memory, you can store it as float,
| double, or extended, and the shorter formats are widened to extended
| when you load them.  So even if you are doing arithmetic on floats,
| the '87 does you a favor and internally does the work on extendeds,
| turning them back to floats only when you save them.
| 
| I am not enough of a numerical analyst to say whether this is a good idea
| or not, but a few years back I listened to a most interesting talk given
| by one of the guys who designed the 8087, and it was clear that this
| deecisions was not made arbitrarily.

As I noted above, I think that this contravenes the standard.  I
think that it is still possible to store variables in registers, as
long as you keep pushing them through the knothole as part of
assignment.

I think that this is an important practical point.  My
interpretation severely effected the efficiency of FP code produced
by my compiler for the 68881 FPU.  I welcome discussion.

Hugh Redelmeier
hughamimosa.com or {utcsri, utzoo, scocan}!redvax!hugh
When all else fails: hughacsri.toronto.edu
voice: +1 416 482-8253