--- ais/ai-00267.txt 2001/05/26 02:55:11 1.2 +++ ais/ai-00267.txt 2001/10/19 01:36:44 1.3 @@ -1,6 +1,7 @@ -!standard 4.6 (33) 01-05-25 AI95-00267/02 -!standard A.5.3 (00) +!standard 4.6 (33) 01-10-18 AI95-00267/03 +!standard A.5.3 (41) !class amendment 01-05-14 +!status ARG approved 9-0-0 01-10-07 !status work item 01-05-14 !status received 01-05-14 !priority Medium @@ -9,15 +10,15 @@ !summary -An attribute is added to enable high-performance conversions from float types -to integer types when the exact rounding does not matter. +An attribute is added to enable high-performance conversions from floating +point types to integer types when the exact rounding does not matter. !problem -4.6(33) specifies the rounding for conversions from float types to integer types. -However, the specified rounding is different than the default rounding provided -for conversions on many common machines. Thus, such conversions are quite -expensive. +4.6(33) specifies the rounding for conversions from floating point types to +integer types. However, the specified rounding is different than the default +rounding provided for conversions on many common machines. Thus, such +conversions are quite expensive. For example, one vendor reports that the effect of the specified rounding on the performance of their implementation of the Generic_Elementary_Functions was @@ -42,6 +43,19 @@ of X when S'Signed_Zeros is True. This function should use whatever rounding is most efficient on the target processor. +AARM note: + +The intended use of this attribute is in a type conversion to some integer +type: + + Some_Integer(Some_Float'Machine_Rounding(X)) + +Implementations should detect this case to generate fast code for the +conversion of X to Some_Integer. In particular, the usual Float to Integer +type conversion rounding code is not necessary, as the value has already been +rounded. (This applies to all of the rounding and trunctation attributes +defined in A.5.3). + !example !discussion @@ -68,6 +82,25 @@ be requiring documentation of the rounding used, which potentially would encourage users to depend on a particular rounding. +!corrigendum A.5.3(41) + +@dinsa +@xindent<The function yields the integral value nearest to @i<X>, rounding +toward the even integer if @i<X> lies exactly halfway between two integers. A +zero result has the sign of @i<X> when S'Signed_Zeros is True.> +@dinss +@xhang<@xterm<S'Machine_Rounding> +S'Machine_Rounding denotes a function with the following specification:> + +@xindent< @fc<@b<function> S'Machine_Rounding (@i<X> : T)@hr + @b<return> T>> + +@xindent<The function yields the integral value nearest to @i<X>. If @i<X> lies +exactly halfway between two integers, one of those integers is returned, but +which of them is returned is unspecified. A zero result has the sign +of @i<X> when S'Signed_Zeros is True. This function should use whatever +rounding is most efficient on the target processor.> + !ACATS test Create a C-Test to check for the existence of this attribute. (It can't be @@ -111,10 +144,10 @@ > (because there is no way to avoid the type conversion which carries along > the expense). -I agree with this assessment. We have run into the same problem on a variety of -processors. At some point we considered having a configuration pragma to mean -I-don't-give-a-damn-about-mid-point-rounding, but we never had time to implement -it. +I agree with this assessment. We have run into the same problem on a variety +of processors. At some point we considered having a configuration pragma to +mean I-don't-give-a-damn-about-mid-point-rounding, but we never had time to +implement it. One practical situation where this shows up is the implementation of the elementary functions. You perform some FP computation, based on which you

Questions? Ask the ACAA Technical Agent