CVS difference for ais/ai-00268.txt

Differences between 1.7 and version 1.8
Log of other versions for file ais/ai-00268.txt

--- ais/ai-00268.txt	2002/03/13 00:48:28	1.7
+++ ais/ai-00268.txt	2002/03/14 23:47:09	1.8
@@ -412,124 +412,3 @@
 
 ****************************************************************
 
-From: Brian Wichmann
-Sent: Saturday, March  9, 2002  6:58 AM
-
-I am totally confused by this AI and also what the RM says!
-
-1. Independent of rounding, the RM is clearly wrong for some m/cs.
-
-Take a machine which only has double-length hardware and a round instruction.
-Single length is a type, but by 11.6, the compiler will use double-length
-operations and just does round on assignment. It would be crazy to truncate
-static expressions to single length on such a machine, but the RM seems
-to require that.
-
-2. IEEE is a red-herring. Clearly, the rounding should be appropriate to
-the target. This is not to the target type, as point 1 shows.
-
-3. The static expression model is just right. Hence Pascal's example is
-misleading since for a compiler to replace division by multiplication is
-hardly ever safe (obviously, replacing X/1.0 by X is fine; so some operator
-juggling is possible).
-
-4. Machine_Rounds is False does not imply truncation. The attribute might be
-false just because divide is implemented incorrectly - surely that should not
-mess up static expressions?
-
-5. Rounding is potentially dynamic. As Erhard has pointed out, full IEEE
-systems have the ability to dynamically control rounding. When using the
-facility, perhaps the user might like to recompile his program with an
-option to control the rounding - why not?
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Tuesday, March 12, 2002  7:13 AM
-
-> 1. Independent of rounding, the RM is clearly wrong for some m/cs.
->
-> Take a machine which only has double-length hardware and a round instruction.
-> Single length is a type, but by 11.6, the compiler will use double-length
-> operations and just does round on assignment. It would be crazy to truncate
-> static expressions to single length on such a machine, but the RM seems
-> to require that.
-
-I don't think there is a problem here.  This situation is similar to that of
-extended registers.  AARM A.5.3(11.d) makes it clear that we expect
-Machine_Rounds to return True in the presence of extended registers (assuming
-that the arithmetic is otherwise well-behaved) even though multiple rounding
-can sometimes yield results that are not properly rounded.
-
-> 2. IEEE is a red-herring. Clearly, the rounding should be appropriate to
-> the target. This is not to the target type, as point 1 shows.
-
-I think that IEEE is only mentioned as an example in the AI.  Surely it is an
-important case in practice.
-
-> 3. The static expression model is just right. Hence Pascal's example is
-> misleading since for a compiler to replace division by multiplication is
-> hardly ever safe (obviously, replacing X/1.0 by X is fine; so some operator
-> juggling is possible).
-
-Agreed, my comment was misguided.  The only divisions that can be safely
-converted to multiplications are those where the divisor is a power of 2.0.
-
-> 4. Machine_Rounds is False does not imply truncation. The attribute might be
-> false just because divide is implemented incorrectly - surely that should not
-> mess up static expressions?
-
-One possibility would be to say when Machine_Rounds is False, the static
-computation should emulate what the target arithmetic does. However, that looks
-like a slippery slope to me. First, it would significantly complicate those
-cross-compilers that target processors with exotic arithmetic, as emulating the
-target might be complex and error-prone.  Second, it would hamper portability,
-as the static rounding would vary from target to target.  I just don't think
-that the case where Machine_Rounds is False is important enough to warrant all
-this complexity.
-
-> 5. Rounding is potentially dynamic. As Erhard has pointed out, full IEEE
-> systems have the ability to dynamically control rounding. When using the
-> facility, perhaps the user might like to recompile his program with an
-> option to control the rounding - why not?
-
-This is beyond the scope of this AI. If we ever design a mapping to the full
-IEEE capabilities, maybe we'll want to have a configuration pragma to
-specifying the default rounding mode. In the meantime, people who use machine
-code insertions to change the rounding mode should be extra cautious with
-static expressions (and make them dynamic if they need to use the current
-rounding mode).
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Tuesday, March 12, 2002  2:05 PM
-
-> 1. Independent of rounding, the RM is clearly wrong for some m/cs.
-> Take a machine which only has double-length hardware and a round instruction.
-> Single length is a type, but by 11.6, the compiler will use double-length
-> operations and just does round on assignment. It would be crazy to truncate
-> static expressions to single length on such a machine, but the RM seems
-> to require that.
-
-This of course is the situation on the 8086 family (including the Pentiums).
-I agree that it is crazy that the RM requires rounding to single length
-(Janus/Ada 83 always created static expressions as double length, no matter
-what the type, for 8086 family machines). Why discard accuracy? However,
-this was discussed at the time Ada 95 was designed (I know I objected to
-this rule), and (as I recall) the answer was essentially that "the numeric
-guys want it this way". I certainly don't see any new information which
-would make it valuable to revisit that decision.
-
-On the other questions, I agree with Pascal.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Tuesday, March 12, 2002  3:40 PM
-
-I disagree that the rounding of floats should be implementation dependent
-in this sense. I think it is perfectly reasonable to round appropriate
-to the type for static expressions.
-
-****************************************************************

Questions? Ask the ACAA Technical Agent