3.9 Traps and Interrupts
3.9.1 Machine State at Reset
The reset trap is triggered asynchronously by asserting the external PRST signal. When the hyperSPARC CPU recognizes the PRST signal, it enters reset mode and stays there until the PRST line is deasserted. The processor then enters Execute mode and executes the trap procedure. The specific actions taken during reset are:
• ET (enable trap) bit in the PSR is set to O.
• S (supervisor) bit in the PSR is set to 1.
• PC is set to 0 and nPC is set to 4.
• FTD bit in the ICCR is set to 0 and the ICE bit is set to O.
All other fields in the above programmer-accessible registers and all other registers are unspecified on a power-up reset; if the reset is not a power-up reset, they retain their values from the last execution mode.
Internally, on a reset trap
• All the valid bits in the ICACHE are cleared.
• The valid bits in the instruction fetch buffers are cleared.
• The valid bits of all the FPQ entries are cleared. Because all FPQ entries are cleared, the qne bit will also be initially cleared.
• Control is then transferred to location O.
F o E
c w
integer unit exception pending :
Tl T2 T3
( gen tt ) ( trap addr
>
: (ETChk)
,
/TBR\
~
(save)
PC
~ ~ Figure 3-56. Exception Pipeline
TEO H N O ' a G Y.
,~ ============;:;;;R;:;;;T;:;;;6;:;;;2;:;;;O;:;;;h;!;;:yp=e;:;;;r;:;;;SP;:;;;~;:;;;R;:;;;C=C;:;;;P=U
3.9.2 Exception Pipeline
A trap is always taken at the end of the Writeback stage. Instructions which preceded the instruction which caused the trap are allowed to complete register Update before the trap is recognized. At the end of this Wri-teback stage, three additional pipeline stages are "appended" to support trap handling. These stages are referred to as Tl, T2, and T3. Figure 3-56 shows these stages along with the activities performed during each stage. Note that if Tl is entered while the trap enabled (ET) bit in the PSR is cleared, the processor enters ERROR mode.
There is a special case involving an ALU instruction in slot-a paired with a load instruction in slot-b. Ifboth instructions are launched together and the load instruction causes a data access trap, the ALU instruction is allowed to complete its register Update.
3.9.3 Trap Operation
SPARC traps are enabled or disabled with the enable traps (ET) bit in the processor state register (PSR). If traps are enabled, the following occurs upon recognizing a trap:
• The current window pointer (CWP) in the PSR is decremented, thus changing the CWP. Note that this is done without regard to the WIM register and without checking for window over-flow.
• The existing user/supervisor mode is preserved in the PS bit: S ~ PS.
• The user/supervisor mode is changed to supervisor: I ~ S.
• The RT620 automatically saves the PC in r[17] (local register 1) of the current window.
• nPC is automatically saved in r[18] (local register 2) of the current window.
• The ET bit of the PSR is cleared, thereby disabling traps.
• The trap type is automatically entered into the tt (trap type) field of the trap base register (TBR).
• If the trap is a reset trap, control is transferred to address 0: 0 ~ PC, 4 ~ nPC.
• If the trap is not a reset trap, control is transferred to the address specified by the TBR:
TBR ~ PC, TBR+4 ~ nPC.
The trap table pointed to by the TBR has a space of four instructions for each trap vector specified by the TBR. This available slot of four instructions is generally used to jump to a trap handler routine.
If the enable trap bit is cleared (ET = 0) when a trap is recognized by the processor, the RT620 enters error mode and halts execution. If ET = 0 and an interrupt or deferred exception occurs, it is ignored.
3.9.4 Error Mode
SPARC processors enter error mode or state when a trap occurs while traps are disabled (when the ET bit of the PSR is set to zero). Upon encountering this event, the processor halts execution and asserts the PERROR signal. Standard trap actions, such as decrementing CWP and saving the program counters (PC and nPC) in r[17] and r[18] do not occur. The tt field of the TBR is not written except in the case of a RETT instruction that traps while ET = O. In this singular case, the tt field is written to indicate the exception type induced by the RETT instruction. The method of handling error mode is implementation dependent, but it is typically handled by causing the processor to trigger an external reset.
~~/$
============;;;;;R;;;;;T;;;;;6;;;;;2;;;;;O;;;;;h;;:;y:;;;pe;;;;;r;;;;;SP;;;;;1\;;;;;R;;;;;C=C;;;;;P=U 3.9.5 Trap PrioritiesEach trap type is assigned a priority; priority 1 is the highest priority and priority 31 the lowest. If two traps occur simultaneously, the highest priority trap is taken. The RT620 avoids the case of two traps occuring with the same priority by disallowing simultaneous launch of instructions which can cause exceptions at the same priority level.
The trap table (used to direct traps to the appropriate trap handler) is divided into two halves. The first half is dedicated to hardware exceptions and the second half is dedicated to software exceptions. Hardware ex-ceptions are detected by the processor logic. Software traps are accessed through the Ticc instruction.
Table 3-7lists exceptions supported by the RT620:
Table 3-7. RT620 Supported Exceptions
Exception Priority tt
reset 1 n/a
instruction access exception 5 OxOI
privileged instruction 6 Ox03
illegal instruction 7 Ox02
floating-point disabled 8 Ox04
coprocessor disabled 8 0x24
unimplemented flush 8 0x25
window overflow 9 Ox05
window underflow 9 Ox06
memory address not aligned 10 Ox07
floating-point exception 11 Ox08
data access exception 13 Ox09
tag overflow 14 OxOa
division by zero 15 Ox2a
trap instruction 16 Ox80 through Ox:ff
interrupt level 15 17 Oxlf
Precise trap exception conditions are detected during anyone of the integer instruction pipeline stages. The priority encoding of these exceptions is performed at each pipeline stage as the instruction progresses.
Table 3-8 identifies the pipeline stage at which each exception is detected during instruction execution.
T E C H N O L O G Y ,
~~~~~~~~~~~~~~R~T~6~2~O~h=yp=e~r~SP~~~R~C~C~P=U
Table 3-8. Pipeline Stage Exception Recognition
Decode Execute Writeback
instruction access illegal instruction data access
privilege violation window overflow
illegal instruction window underflow
floating-point unit disabled memory not aligned
CP disabled tag overflow
floating-point exception floating-point exception floating-point exception trap instruction (ticc) interrupt
unimplemented flush divide-by-zero
A pending fp exception is recognized in Decode if the instruction is a FBfcc, in Execute if the instruction is an fp Load or an FPop, and in Write back if the instruction is an fp store. Note that an fp exception is always taken regardless of the exception priority if the instruction is valid (for example, if an fp Store recognizes an fp exception and there is a misaligned exception on the Store, the fp exception trap is taken even though a misaligned trap has higher priority).
In the RT620, an illegal instruction exception is signaled when an integer instruction is not implemented.
An illegal instruction exception is recognized in Decode except for an illegal instruction exception due to a WRPSR instruction with an invalid CWP which is recognized in Execute.
3.9.7 Interrupting Traps (Asynchronous)
For interrupt requests, the MIRL<3 :0> is compared against the processor interrupt level (PIL) of the proces-sor status register (PSR). If traps are enabled (ET
=
1) and if MIRL<3:0> is greater than the PIL, or if MIRL<3 :0>=
Ox 15 (a non-maskable interrupt), the interrupt trap is taken if no higher priority traps are out-standing.Note that an interrupt will be masked when:
• traps are disabled (ET
=
0) or• the interrupt level on the extemallines (MIRL<3 :0> ) is less than or equal to the PIL in the PSR (unless MIRL<3:0> = 15, which is a non-maskable interrupt).
Interrupts are sampled two successive times at a sampling rate of one-half of the IMCLK frequency before a new MIRL<3:0> value is recognized by the processor. The value of MIRL<3:0> must be held until the interrupt trap is taken. This is usually accomplished by coding the interrupt trap routine to access a user-de-fined system interrupt control register and clear the interrupt.
, E C H N O ' 0 G Y,
,$
============;;;;;;R;;;;;;T;;;;;;6;;;;;;2;;;;;;O;;;;;;h;;:;;y:;;;pe;;;;;;r;;;;;;SP;;;;;;i\;;;;;;R;;;;;;C=C;;;;;;P=U 3.9.8 Floating-Point Unit Traps (Deferred Traps)There are four types of fp exceptions:
Unimplemented fp instruction: This exception is signaled when the floating-point unit local decoder determines that the opcode bit pattern is invalid or the instruction is a SPARC fp instruction that is not supported in hardware in the RT620 (e.g., FADDx).
Unfinished fp instruction: This exception is signaled when the floating-point unit is operating in stan-dard mode and any of the inputs is a denormalized number or when the output is a tiny number before rounding, with the following exceptions:
1. One operand is a NaN, or during an add or subtract operation.
2. One operand is a NaN, or during a multiply or divide operation.
3. The operand is a negative denormalized number during a square root operation.
4. The instruction is an absolute value (FABSs), move (FMOVs), negate (FNEGs), compare (FCMPs, FCMPd, FCMPEs, FCMPEd, or convert floating-point to/from integer (FdTOi, FsTOi, FiTOs, FiTOd).
Sequence Error: This exception is signaled when the floating-point unit is in exception (TRAP) mode and an fp instruction other than an fp store is decoded. This exception is also signaled when a STDFQ instruction is issued when the floating-point unit is not in EXCEPTION mode.
IEEE Exceptions: This is a class of exceptions defined by the IEEE-754 standard. The specific exception is signaled through the cexc field of the FSR.
The fp exceptions are signaled through the
Itt
field in the FSR as shown below.Table 3-9. FTT Field of FSR
ftt Field Exception Type
000 none
001 IEEE
010 Unfinished
011 Unimplemented
100 Sequence error
101 Hardware error (not supported in RT620)
110 reserved
111 reserved
The exceptions are detected by the FPQC in the Round stage, or previous pipeline stages in which case they advance through the fp pipeline stages until they reach the Round stage. All the exceptions cause fp deferred traps except those corresponding to IEEE exceptions. For a particular IEEE exception, the IEEE exception will cause a deferred trap only if the corresponding bit in the trap enable mask field in the FSR is set. On recognizing a trap condition, the floating-point unit enters exception pending mode and asserts the fp excep-tion pending signal. The next fp instrucexcep-tion to enter the instrucexcep-tion decoder will cause the integer unit to acknowledge the fp exception and take an fp trap as shown in Figure 3-57. When the floating-point unit receives the exception acknowledgement signal, it goes into EXCEPTION mode as discussed in Section 3.5.
~$,~ =============R;;;;:T6;;;;:2;;;;:O;;;;:h;!;;y=pe;;;;:r;;;;:SP;;;;:~;;;;:R;;;;:C=C;;;;:P=U
As defined in the SPARC architecture, when an fp trap occurs:
• the destination register is unchanged.
• the FSRfcc field is unchanged.
• the FSR aexc field is unchanged.
• the FSR cexc field is unchanged except for an IEEE-754 exception; in this case, the cexc con-tains exactly one bit (which is 1) corresponding to the exception which caused the trap.
FP Inst 1 (causes trap)
FP Inst 2
fp_exception_pending ,
:
r--trap~-'~
_ _ - J 'l_~~s~~J
__ ----__ --~:~I --~~SS:
ss;
Figure 3-57. Floating-Point Exception Pipeline
, 1
:IL...-__
,,--I _ _
When an fp exception is acknowledged by the integer unit, an fp exception trap handler is invoked and the floating-point unit enters exception mode (also referred to as trap mode). Typically, this trap handler executes a sequence of store double floating-point queue (STDFQ) instructions to empty the queue of its address and instructions. The FPQ is emptied starting at post-queue entry 0 and working back through to pre-queue entry 6, skipping invalid entries. If any fp instruction other than a store instruction is attempted, a sequence error occurs and the processor remains in exception mode. When the FPQ is emptied, the float-,ing-point unit returns to normal execution mode.
The instruction decoder checks to see if there is an fp exception pending in different stages depending on the instruction being decoded as given in the following table.
Table 3-10. FP Pipeline Stage Exception Recognition
Instruction Stage
FBfcc Decode
FPop Execute
fp Load Execute
fp Store Writeback
FP exceptions are checked in the Decode stage if the instruction is an fp Branch to maintain correct PCs to save in the trap handler.
In case ofFPop instructions, fp exception is checked for in the Execute stage. If this were done in the Decode stage, then in the case where the exception pending signal from the floating-point unit arrives in the Execute cycle, the integer unit would assume that the instructions had been successfully launched. However, the floating-point unit would not accept the instructions, and the instructions would then be "lost."
T E C H N O L O G Y ,
FP Inst 1 (causes a trap) fp store inst
fp_exception_
pending fp_exception_
acknowledge
: I : 11....----.-_ _
--~--~--7_~--~:I~ ~:~I __
~---Figure 3-58. Floating-Point Exception during Forwarding to Store
In case of fp Load instructions, fp exceptions are checked in the Execute stage. This is because no dependen-cy checks are done for a load in Decode stage against the instruction in entry 0 (the Round stage of the instruction); if the instruction should cause an fp exception pending in the next cycle, it would be detected in the Execute cycle of the Load.
The instruction decoder checks for the exception pending signal in the Write back stage of the Store instruc-tion. This case is illustrated in Figure 3-58. The Store instruction is waiting for data to be forwarded from the fp instruction. However, the Store instruction anticipates the completion of the fp instruction and goes into the Execute stage in the same cycle that the fp instruction enters Round stage. If the fp instruction takes a trap, then the exception pending signal arrives too late for the instruction decoder to recognize the excep-tion while the Store is in Execute. Since the data forwarded is invalid in the case of an excepexcep-tion, the Store instruction needs to be cancelled and the exception has to be recognized. The Store instruction is cancelled by the FPQC which sends the cancel signal (in the next cycle) to the IBIU if there is an fp Store in Execute and there is an exception pending. The instruction decoder checks for an exception pending signal from the floating-point unit in the Writeback stage of the Store and takes the fp exception only if the exception pend-ing signal was also asserted in the previous cycle (if the exception pendpend-ing signal was asserted startpend-ing in the Write back stage, then the fp exception is not recognized on the Store instruction since it is too late to annul the Store).
3.9.8.1 IEEE Exceptions
There are five RT620 supported IEEE exceptions: inexact, underflow, overflow, invalid, and divide by zero.
The conditions under which these exceptions occur are described in the IEEE-754 standard. However, a few details of the IEEE-754 standard are implementation dependent. Also, the RT620 does not handle denor-malized operands in all cases. The behavior of the RT620 in the case ofIEEE-754 exceptions is described in the following sections. Note that there cannot exist more than two exception cases simultaneously. If there are two exception cases, one exception will be an inexact exception. In the standard mode, two exception cases can arise when an overflow exception occurs; in the non-standard mode, an inexact exception can arise along with any other exception.
T E C H N O L O G Y ,
In non-standard mode, denormalized numbers at the input or output are substituted by zero if the case is such that an unfinished exception would result in the standard mode. Detailed description of the behavior of each individual instruction in standard and non-standard mode is given in Section 3.9.8.6.
NXM refers to the inexact bit in the term, NX indicates that an inexact trap is taken (the nx bit is set in the cexc), and nx means that the inexact bit is set in the cexc and ORed into the aexc but no trap is taken. Similar abbreviations are used for the other exception types.
3.9.8.2 Inexact exception 3.9.8.2.1 Standard mode:
The inexact exception can arise due to two causes:
1. There is an overflow condition as discussed in Section 3.9.8.3.3.
2. The result is inexact as defined by the IEEE standard and there is no other exception.
3.9.8.2.2 Non-Standard Mode:
In addition to the exception cases in the standard mode, an inexact exception also occurs if denormalized numbers at the input or output are substituted by zero; the inexact exception will trap only if NXM = 1 and no other higher priority IEEE exception trap occurs as discussed in the tables below.
3.9.8.3 Underflow Exception 3.9.8.3.1 Standard Mode:
In the standard mode of operation, there is no underflow exception; an unfinished trap is taken if the result underflows.
3.9.8.3.2 Non-Standard Mode:
If tininess is detected in the result of an operation (before rounding), then an underflow condition exists. The state of the inexact and underflow trap enable mask bits in the FSR decides the course of action taken.
If both the inexact and the underflow traps are disabled, then the uf and nx bits in the cexc field of the FSR are set and also ORed into the aexc, and the result is replaced by zeros with the same sign. If the uf and/or the nx traps are/is enabled, then the trap which is taken is prioritized (remember that only one bit in the cexc should be set when an fp trap due to an IEEE exception is taken).
The following table indicates the priority between the IEEE exceptions when there is a denormalized result with the floating-point unit in non-standard mode (Note: XX denotes bit set and trap taken, xx denotes bit set only).
Trap Enable State FSR Update (NS = 1)
UFM= 1. NXM=x UF
UFM=O,NXM= 1 NX
UFM=O,NXM=O nx, uf
T E e H N 0 LOG Y.
,$
=============R=T=6=2=O=h;!;:y:pe=r:;;;SP=}\=R=C====C=P;;;i:;U 3.9.8.3.3 Overflow Exception:Overflow behaves identically in the non-standard mode and the standard mode. The following table defines the behavior when an overflow exception occurs (Note: XX denotes bit set and trap taken, xx denotes bit set only).
Trap Enable State FSR Update
OFM= I,NXM=x OF
OFM=O,NXM= 1 NX
OFM=O, NXM=O nx,of
3.9.8.4 Invalid Exception 3.9.8.4.1 Standard Mode:
This exception occurs as specified in the IEEE 754-1985 standard.
3.9.8.4.2 Non-Standard Mode:
In the non-standard mode, in addition to the standard-mode exceptions, if the exception occurs due to substi-tution of denormalized numbers, the exceptions are prioritized as follows (Note: XX denotes bit set and trap taken, xx denotes bit set only).
Trap Enable State FSR Update (NS
=
1)NVM = 1, NXM = x NV
NVM = O,NXM = 1 NX
NVM = 0, NXM =
°
nX,nv3.9.8.5 Divide by Zero Exception 3.9.8.5.1 Standard Mode:
This exception occurs as specified in the IEEE 754-1985 standard.
3.9.8.5.2 Non-Standard Mode:
In the non-standard mode, in addition to the standard-mode exceptions, ifthe exception occurs due to substi-tution of denormalized numbers, the exceptions are prioritized as follows (Note: XX denotes bit set and trap taken, xx denotes bit set only).
Trap Enable State FSR Update (NS
=
1)DZM= l,NXM=x DZ
DZM = 0, NXM = 1 NX
DZM = 0, NXM =
°
nX,dz3.9.8.6 Result Generation
3.9.8.6.1 Standard Mode Result Generation
The following sequence of tables provides the results generated by the floating -point unit for various combi-nations of input operands when the processor is operating in standard mode and the corresponding trap
~~,$ ============:;;;;:R:;;;;:T:;;;;:6:;;;;:2:;;;;:O:;;;;:h;!;;:yp=e;;;;;;r:;;;;:SP:;;;;:1\:;;;;:R:;;;;:C~C:;;;;:P;;:;;;;;U
enable mask bit for an IEEE exception is cleared. However, in the case of an unfinished exception, the trap is always taken.
In the following tables, terms are abbreviated as follows:
Inum
a quiet NaN which appears at the rs n source operand input.
a quiet NaN which appears at the rs n source operand input.