P. 1
The SPARC Architecture Manual

The SPARC Architecture Manual

|Views: 1,054|Likes:
Published by Raja Mustafa

More info:

Published by: Raja Mustafa on Feb 11, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





The SPARC-V9trap model stipulates that:

(1) Reset traps, except software_initiated_reset traps, occur asynchronously to program

(2) When recovery from an exception can affect the interpretation of subsequent
instructions, such exceptions shall be precise. These exceptions are:

— software_initiated_reset

— instruction_access_exception

— privileged_action

— privileged_opcode



— trap_instruction

— instruction_access_error

— clean_window

— fp_disabled

— LDDF_mem_address_not_aligned

— STDF_mem_address_not_aligned

— tag_overflow

— unimplemented_LDD

— unimplemented_STD

— spill_n_normal

— spill_n_other

— fill_n_normal

— fill_n_other

(3)IMPL.DEP.#33: Exceptions that occur as the result of program execution may be precise
or deferred, although it is recommended that such exceptions be precise. Examples:
mem_address_not_aligned, division_by_zero.

(4) An exception caused after the initial access of a multiple-access load or store
instruction (load-store doubleword, LDSTUB, CASA, CASXA, or SWAP) that
causes a catastrophic exception may be precise, deferred, or disrupting. Thus, a
trap due to the second memory access can occur after the processor or memory
state has been modified by the first access.

(5) Implementation-dependent catastrophic exceptions may cause precise, deferred, or
disrupting traps (impl. dep. #31).

(6) Exceptions caused by external events unrelated to the instruction stream, such as
interrupts, are disrupting.

For the purposes of this subsection, we must distinguish between the dispatch of an
instruction and its execution by some functional unit. An instruction is deemed to have
beendispatched when the software-visible PC advances beyond that instruction in the
instruction stream. An instruction is deemed to have beenexecuted when the results of
that instruction are available to subsequent instructions.

For most instructions, dispatch and execution appear to occur simultaneously; when the
PC has advanced beyond the instruction, its results are immediately available to subse-
quent instructions. For floating-point instructions, however, the PC may advance beyond
the instruction as soon as the IU places the instruction into a floating-point queue; the
instruction itself may not have completed (or even begun) execution, and results may not
be available to subsequent instructions for some time. In particular, the fact that a floating-
point instruction will generate an exception may not be noticed by the hardware until addi-

7.4Trap Control


tional floating-point instructions have been placed into the queue by the IU. This creates
the condition for a deferred trap.

A deferred trap may occur one or more instructions after the trap-inducing instruction is
dispatched. However, a deferred trap must occur before the execution (but not necessarily
the dispatch) of any instruction that depends on the trap-inducing instruction. That is, a
deferred trap may not be deferred past the execution of an instruction that specifies source
registers, destination registers, condition codes, or any software-visible machine state that
could be modified by the trap-inducing instruction.

In the case of floating-point instructions, if a floating-point exception is currently deferred,
an attempt to dispatch a floating-point instruction (FPop, FBfcc, FBPfcc, or floating-point
load/store) invokes or causes the outstanding fp_exception_ieee_754 trap.

Implementation Note:

To provide the capability to terminate a user process on the occurrence of a catastrophic exception
that can cause a deferred or disrupting trap, an implementation should provide one or more instruc-
tions that provoke an outstanding exception to be taken as a trap. For example, an outstanding float-
ing-point exception might cause an fp_exception_ieee_754 trap when any of an FPop, load or store
floating-point register (including the FSR), FBfcc, or FBPfcc instruction is executed.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->