I'm programming a SPARC v8 (32bit) system and need to verify response to HW traps.
The SPARC provides 256 traps, each of which differing by the trap type, tt, of which the first 128 are the HW traps, and trap types 128 to 255 are software traps. The SPARC instruction set documents say that executing
ta N ; trap always, n = 0..127
causes a trap of type tt=N+128. A trap causes a jump to the trap base address + tt * 16.
Is there a way to programmatically cause a HW trap without writing code exhibiting each of the HW trap conditions, such as window underflow, unaligned access, etc?
I'm thinking of installing SW trap handlers that simply jump to the handler for trap(N-128) and keep my fingers crossed. I'm uncomfortable with this idea because HW traps might cause other processor state to change which a SW trap wouldn't...
Is there a way to programmatically cause a HW trap without writing code exhibiting each of the HW trap conditions, such as window underflow, unaligned access, etc?
No, there isn't a way to replicate all the effects caused by a hardware trap programmatically. For example, a real hardare trap sets the tt (trap type field) in the TBR register to indicate the type of the trap. This field cannot be modified by the programmer by writing to the TBR register. If this field is being read inside the trap handlers (for whatever reasons), you may not be able to set it artificially. However, as the comment mentions it may be possible to cause a hardware trap if your processor implementation provides a debug interface.
I'm programming a SPARC v8 (32bit) system and need to verify response to HW traps.
Is there a particular reason why you cannot write code which actually causes a hardware trap (for example a window overflow or divide by zero etc. ? It is actually quite straightforward to write small unit tests in sparc-asm for testing such traps. If you want to test the response to traps thoroughly it might actually be necessary. Another possiblity is to use a sparc V8 simulator.