VALIDEZ DE LA PRUEBA DE CONCEPTO HIPROOR 1 Prueba de rendimiento de HIPROOR

A Floating-point Exception trap occurs if one of the following four circumstances arises: 1. The processor requests system software assistance to complete the operation, via the

Software Assist trap

2. The IEEE Overflow trap is enabled and an overflow occurs 3. The IEEE Underflow trap is enabled and an underflow occurs 4. The IEEE Inexact trap is enabled and an inexact result occurs

When an overflow, underflow, or inexact result occurs, the appropriate status flags are updated in the FPSR. If enabled, a Floating-point Exception trap occurs, and an indication of which enabled trap occurred is stored in ISR.code and the fpa bit in ISR.code (ISR{14}) is set as described in the next paragraph.

ISR.fpa is set to 1 when the magnitude of the delivered result is greater than the magnitude of the infinitely precise result. It is set to 0 otherwise. The magnitude of the delivered result may be greater if:

• The significand is incremented during rounding, or

• A larger pre-determined value (e.g. infinity) is substituted for the computed result (e.g. when overflow is disabled).

There is no requirement that the Software Assist Floating-point Exception trap ever be signaled, nor is there a mode to force its use. In order to ensure maximum floating-point performance, most implementations will not use this exception except in difficult situations, such as operations creating denormal numbers. The occurrence of a Software Assist trap is indicated when a trap bit is set in ISR.code, but that trap is disabled. The destination register contains the trap enabled response for that trap.

The precedence among Floating-point Exception traps for arithmetic operations is depicted in

Figure 5-12.

5.4.2

Definition of Overflow

The overflow exception can occur whenever the rounded true result would exceed, in magnitude, the largest finite number in the destination format.

The IEEE Overflow Floating-point Exception trap disabled response for all normal and Parallel-FP arithmetic instructions is to either return an infinity or the correctly signed maximum finite value for the destination precision. This depends on the rounding mode, the sign of the result, and the operation. An inexact result exception is signaled.

The IEEE Overflow Floating-point Exception trap enabled response for all normal arithmetic instructions is to return the true biased exponent value MOD 217 and for all Parallel-FP arithmetic instructions is to return the true biased exponent value MOD 28. The value’s significand is rounded to the specified precision and written to the destination register. If the rounded value is different from the infinitely-precise value, then inexactness is signaled. If the significand was rounded by adding a one to its least significant bit, then bit fpa in ISR.code is set to 1. Finally, an interruption due to a Floating-point Exception trap will occur.

Note that when rounding to single, double, or double-extended real, the overflow trap enabled response for normal (non Parallel FP) arithmetic instructions is not guaranteed to be in the range of a valid single, double, or double-extended real quantity, because it is in 17-bit exponent format.

5.4.3

Definition of Tininess, Inexact and Underflow

Tininess is detected after rounding, and is said to occur when a non-zero result (computed as

though the exponent range were unbounded) would lie strictly between +2Emin and -2Emin. See

Table 5-1 for the values of Emin for each real type. Creation of a tiny result may cause an exception later (such as overflow upon division because it is so small).

Inexactness is said to occur when the result differs from what would have been computed if both

the exponent range and precision were unbounded.

Figure 5-12. Floating-point Exception Trap Prioritization

000912 tmp_exp? Pre- computed Res? FLAGS.u = 1 Inf No Infinity Result Underflow Enabled? Yes <Emin START Zero Zero Result

Inf. Precision Operation Unbounded Range Rounding tmp_exp, tmp_sig tmp_i, tmp_fpa >Emax Overflow Enabled? FP TRAP FLAGS.u = 1 FLAGS.i | = 1 Exp = tmp_exp%217 Sig = tmp_sig ISR.u = 1 ISR.i = tmp_i ISR.fpa = tmp_fpa >=Emin <=Emax No FP TRAP FLAGS.o = 1 FLAGS.i | = tmp_i Exp = tmp_exp%217 Sig = tmp_sig ISR.o = 1 ISR.i = tmp_i ISR.fpa = tmp_fpa Yes FTZ? Zero Res tmp_i = 1 tmp_fpa = 0 Inf. Prec Operation BoundRange Rounding tmp_i, tmp_fpa Zero/Den/ MinReal Res No Yes tmp_i? No Yes tmp_i? MaxReal/ Inf Res tmp_fpa FLAGS.o = 1 DONE No FLAGS.i = 1 Yes Inexact Enabled? No FP TRAP ISR.i = 1 ISR.fpa = tmp_fpa Yes

tmp_exp = result exponent tmp_sig = result significand tmp_i = inexactness indicator tmp_fpa = significand roundup

Terminal State

How tininess and inexactness trigger the underflow exception depends on whether the Underflow Floating-point Exception trap is disabled or enabled. If the trap is disabled then the underflow exception is signaled when the result is both tiny and inexact. If the trap is enabled then the underflow exception is signaled when the result is tiny, regardless of inexactness. Note that in the event that the Underflow Floating-point Exception trap is disabled and tininess but not inexactness occurs, then neither underflow nor inexactness is signaled, and the result is a denormal.

The IEEE Underflow Floating-point Exception trap disabled response for all normal and Parallel- FP arithmetic instructions is to denormalize the infinitely precise result and then round it to the destination precision. The result may be a denormal, zero, or a normal. The inexact exception is signaled when appropriate.

The IEEE Underflow Floating-point Exception trap enabled response for all normal arithmetic instructions is to return the true biased exponent value MOD 217and for all Parallel-FP arithmetic instructions is to return the true biased exponent value MOD 28. The significand is rounded to the specified precision and written to the destination register independent of the possibility of the exponent calculation requiring a borrow. If the rounded value is different from the infinitely-precise value, then inexactness is signaled. If the significand was rounded by adding a one to its least significant bit, then bit fpa in ISR.code is set to 1. Finally, an interruption due to a Floating-point Exception trap will occur.

Note: When rounding to single, double, or double-extended real, the underflow trap enabled response for normal (non Parallel FP) arithmetic instructions is not guaranteed to be in the range of a valid single, double, or double-extended real quantity, because it is in 17-bit exponent format.

When Flush-to-Zero mode is enabled, the behavior for tiny results is different. If an instruction would deliver a tiny result, a correctly signed zero is delivered instead and the appropriate FPSR.sfx.u and FPSR.sfx.i bits are set. This mode may improve the performance on

implementations that do not implement denormal handling in hardware. When the Flush-to-Zero mode is enabled, floating-point exception software assist traps will not occur when producing tiny results.

5.4.4

Integer Invalid Operations

Floating-point to integer conversions which are invalid (in the IEEE sense) signal an Invalid Operation Floating-point Exception fault. If the IEEE Invalid Operation trap is disabled, then the largest magnitude negative integer is the result, even for unsigned integer operations.

5.4.5

Definition of Arithmetic Operations

Arithmetic operations are those that compute on the operands by treating each operand’s encoding as a value, whereas non-arithmetic operations perform bit manipulations on the input operands without regard to the value represented by the encoding (except for NaTVal detection). Non- arithmetic instructions do not cause Floating-point Exception faults or traps, but can cause the Disabled Floating-point Register fault.

5.4.6

Definition of SNaNs, QNaNs and Propagation of NaNs

Signaling NaNs have a zero in the most significant fractional bit of the significand. Quiet NaNs have a one in the most significant fractional bit of the significand. This definition of signaling and quiet NaNs easily preserves “NaNness” when converting between different precisions. When propagating NaNs in operations that have more than one NaN operand, the result NaN is chosen from one of the operand NaNs in the following priority based on register encoding fields: first f4,

then f2, and lastly f3.

5.4.7

IEEE Standard Mandated Operations Deferred to Software

The following IEEE mandated operations will be implemented in software: • String to floating-point conversion

• Floating-point to string conversion

• Divide (with help from frcpa or fprcpa instruction)

• Square root (with help from frsqrta or fprsqrta instruction) • Remainder (with help from frcpa or fprcpa instruction) • Floating-point to integer valued floating-point conversion

• Correctly wrapping the exponent for single, double, and double-extended overflow and underflow values, as recommended by the IEEE standard

5.4.8

Additions beyond the IEEE Standard

• The fused multiply and add (fma, fms, fnma, fpma, fpms, fpnma) operations enable efficient software divide, square root, and remainder algorithms.

• The extended range of the 17-bit exponent in the register format allows simplified implementation of many basic numeric algorithms by the careful numeric programmer. • The NaTVal is a natural extension of the IEEE concept of NaNs. It is used to support

speculative execution.

• Flush-to-Zero mode is an industry standard addition.

• The minimum and maximum instructions allow the efficient execution of the common Fortran Intrinsic Functions: MIN(), MAX(), AMIN(), AMAX(); and C language idioms such as a<b?a:b.

• All mixed precision operations are allowed. The IEEE standard suggests that implementations allow lower precision operands to produce higher precision results; this is supported. The IEEE standard also suggests that implementations not allow higher precision operands to produce lower precision results; this suggestion is not followed. When computations with higher precision operands produce values beyond the destination precision range, the information provided in the ISR.code allows the true result to be unambiguously determined by software. The correct wrapping count and the appropriate bias amount can also be computed.