System and method for Automatic Hardware Interrupt Handling

Abstract

A processing system is provided consisting of an interrupt pin, multiple registers, a stack pointer, and an automatic interrupt system. The multiple registers store a number of processor states values. When the system detects an interrupt on the interrupt pin the system prepares to enter an exception mode where the automatic interrupt system causes an interrupt vector to be fetched, the stack pointer to be updated, and the processor state values to be read in parallel from the registers and stored in memory locations based on the updated stack pointer, prior to the execution of an interrupt service routine. A method for automatic hardware interrupt handling is also presented.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application is a divisional of U.S. application Ser. No. 12/847,772, filed Jul. 30, 2010, (now allowed), which is incorporated by reference herein in its entirety.

BACKGROUND

1. Field of Invention

Embodiments of the present invention relate generally to microprocessors and in particular to interrupt handling.

2. Related Art

Within a computer processing environment, an interrupt is an event that interrupts normal program execution. Programs typically execute on a microprocessor in an ordered fashion. Typical execution is altered by instructions that expressly cause program flow to deviate, e.g., a jump instruction and a branch instruction. Interrupts disrupt normal execution of instructions. Typically upon detection of an interrupt, a special program known as an interrupt handler, or interrupt service routine, is executed that context switches the system. Context switching includes storing the state (e.g., context) of the processor, servicing the interrupt, and restoring the context of the process such that execution of instructions can be resumed from the point prior to the interrupt.

The process of context switching requires a large number of processor cycles during which the processor executes the interrupt service routine. This interrupt service routine typically flushes the processor's pipeline and saves numerous state registers in memory. As programs increase in complexity the time consumed performing interrupt service routines decreases availability of processor resources available for other program functions.

BRIEF SUMMARY

This section is for the purpose of summarizing some aspects of the present invention and to briefly introduce some embodiments of the invention. Simplifications or omissions may be made to avoid obscuring the purpose of the section. Such simplifications or omissions are not intended to limit the scope of the present invention.

Therefore, what is needed are methods and systems to service interrupt requests in a more timely and efficient manner.

In an embodiment of the invention, there is provided a processing system consisting of an interrupt pin, multiple registers, a stack pointer, and an automatic interrupt system. The multiple registers store a number of processor states values. When the system detects an interrupt on the interrupt pin the system prepares to enter an exception mode where the automatic interrupt system causes an interrupt vector to be fetched, the stack pointer to be updated, and the processor state values to be read in parallel from the registers and stored in memory locations based on the updated stack pointer, prior to the execution of an interrupt service routine.

In another embodiment of the invention, there is provided a method that includes receiving an interrupt request, fetching an interrupt vector, reading a number of processor state values in parallel, and storing the number of processor state values in memory locations specified by the updated stack register, in preparation for entering an exception mode and prior to execution of an interrupt service routine.

In a further embodiment of the invention, there is provided a non-transitory computer readable storage medium including computer readable program code for generating a processor where the program code includes computer-readable code to generate an interrupt pin, computer-readable code that generates a number of registers that store multiple processor state values, computer-readable code that generates a stack pointer, and computer-readable code that generates an automatic interrupt system. The automatic interrupt system detects an interrupt on the interrupt pin and fetches an interrupt vector, updates a stack pointer, and reads, in parallel, a number of processor state values from the registers and stores those values in memory locations specified by the updated stack pointer, prior to execution of an interrupt service routine.

These and other embodiments and features, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. The invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the information contained herein.

BRIEF DESCRIPTION OF THE FIGURES

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which corresponding reference symbols indicate corresponding parts. Further, the accompanying drawings, which are incorporated herein and form part of the specification, illustrate the embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.

FIG. 1 is a block diagram of a processing system, according to an embodiment of the invention.

FIG. 2 illustrates the format of an interrupt control register, according to an embodiment of the invention.

FIGS. 3A-3L present register field descriptions of registers within an interrupt control register, according to an embodiment of the present invention.

FIG. 4 illustrates the format of a status control register, according to an embodiment of the invention.

FIGS. 5A-5T present register field descriptions of registers within a status control register, according to an embodiment of the present invention.

FIG. 6 illustrates the format of a SRS control register, according to an embodiment of the invention.

FIGS. 7A-7J present register field descriptions of registers within a SRS control register, according to an embodiment of the present invention.

FIG. 8 illustrates the format of a Cause register, according to an embodiment of the invention.

FIGS. 9A-9N present register field descriptions of registers within a Cause register, according to an embodiment of the present invention.

FIG. 10 illustrates the format of an Exception Program Counter register, according to an embodiment of the invention.

FIG. 11 presents register field descriptions of registers within an Exception Program Counter register, according to an embodiment of the present invention.

FIG. 12 illustrates the format of a Configuration register, according to an embodiment of the invention.

FIGS. 13A-13W presents register field descriptions of registers within a Configuration register, according to an embodiment of the present invention.

FIG. 14 illustrates the layout and naming of an interrupt return instruction, according to an embodiment of the present invention.

FIG. 15 is a flowchart of a method for automatic hardware interrupt handling, according to an embodiment of the present invention.

Features of various embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION

The invention will be better understood from the following descriptions of various “embodiments” of the invention. Thus, specific “embodiments” are views of the invention, but each does not itself represent the whole invention. In many cases individual elements from one particular embodiment may be substituted for different elements in another embodiment carrying out a similar or corresponding function. It is expected that those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility.

The embodiments described herein are referred in the specification as “one embodiment,” “an embodiment,” “an example embodiment,” etc. These references indicate that the embodiment(s) described can include a particular feature, structure, or characteristic, but every embodiment does not necessarily include every described feature, structure, or characteristic. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is understood that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

I. AUTOMATIC HARDWARE INTERRUPT HANDLING

FIG. 1 is a block diagram of a processing system 100 including a system for automatic hardware interrupt handling, according to an embodiment of the present invention. The system 100 includes a processor 110 coupled to an interrupt controller 102 where interrupt controller 102 is connected to a number of interrupt lines 104. Interrupt controller 102 prioritizes interrupts 104 and generates interrupt requests to processor 110 using interrupt lines 106. Interrupt controller can also pass interrupt vector 108 to processor 110.

Within processor 110 there exists an exception logic block 112, an interrupt vector generator 116, a shadow register set control register 120, a general purpose register set 124, and a number of shadow register sets 126. In an embodiment, shadow register sets 126 are substitutes for the normal general purpose register (GPR) 124 that can be used in certain processor modes of operation, e.g., Kernel Mode and Exception Mode, or in response to a vectored interrupt or exception. Once a shadow register set 126 is bound to a particular mode, reference to addressable registers in the GPR 124 work with a particular shadow register set that is dedicated to that mode.

Exception logic block 112 within processor 110 receives interrupt lines 106 and determines which, if any, exception is to be processed. If an exception, e.g., an interrupt, is to be processed, exception logic block 112 send signals 114 to exception vector generator 125. Exception vector generator 125 uses signals 114 to create instruction address 118 to be used to handle the exception. Exception vector generator 125 may also receive vector 108 directly from interrupt controller 102. Instruction address 118 is then sent to program counter logic 109 to change the flow of the instruction execution.

The shadow register set control register 120 contains a Current Shadow Set (CSS) register 121 and a Previous Shadow Set (PSS) register 123. Exception logic block 112 sends signals 126 to shadow register set control register 120 and associated logic to switch to the appropriate shadow register set that was assigned for the exception that is to be handled. As previously described, there is the need to reduce the time required to service interrupt service requests. In an embodiment, Table 1 below outlines the number of cycles processor 110 must expend in order to start execution of an interrupt service routine generated by the detection of an interrupt, e.g., interrupts 104 and 114, by the use of software based interrupt handling.

One possible format of an interrupt control register is shown in FIG. 2 and will be discussed in further detail later. Example field descriptions of registers within an interrupt control register can be found in FIGS. 3A-3L and will be discussed in further detail later.

An example format of a COP0 status register in system 400 is shown in FIG. 4. Example field descriptions of registers within a status register can be found in FIGS. 5A-5T of system 500, according to an embodiment of the invention.

An example format of a COP0 SRSCtl register in system 600 is shown in FIG. 6. Example field descriptions of registers within a SRSCtl register are shown in FIGS. 7A-7J of system 700.

An example format of a COP0 Cause register in system 800 is shown in FIG. 8. Example field descriptions of registers within a Cause register is shown in FIGS. 9A-9N of system 900.

An example format of an COP0 EPC register in system 1000 is shown in FIG. 10. Example field descriptions of registers within an EPC register are shown in FIG. 11 of system 1100.

An example format of a COP0 Configuration register in system 1200 is shown in FIG. 12. Example field descriptions of registers within a Configuration register are shown in FIGS. 13A-13W of system 1300.

TABLE 1
Clock cycles Associated with Interrupt
Service Routine (ISR) Processing
Cycles	Event	Hardware/Software
2	Signal Latched	HARDWARE
3	Pipeline Flushed	HARDWARE
1	Interrupt Prioritized	HARDWARE
4	Fetch Interrupt Vector	HARDWARE
0	GPRs saved to Shadow Register Sets	HARDWARE
2	Adjust Stack Pointer	SOFTWARE
2	Save C0_Status to Stack	SOFTWARE
2	Save C0_SRSCtl to Stack	SOFTWARE
2	Save C0_EPC to Stack	SOFTWARE
5	Adjust Status, IPL, EXL	SOFTWARE
—	1st Instruction of ISR
24	Total

As Table 1 indicates, a total of 24 cycles are expended from the point the interrupt is latched to when the first instruction of the interrupt service routine is executed. In another embodiment, Table 2 below outlines the number of cycles processor 110 must expend in order to start execution of an interrupt service routine generated by the detection of an interrupt, e.g., interrupts 104 and 114, by the use of hardware based interrupt handling logic using Interrupt Automated Prologue (IAP).

TABLE 2
Clock cycles Associated with Interrupt Service
Routine (ISR) Processing using IAP.
Cycles	Event	Hardware/Software
2	Signal Latched	HARDWARE
3	Pipeline Flushed and Interrupt	HARDWARE
	Vector is Speculatively Fetched
1	Interrupt Prioritized and	HARDWARE
	Interrupt Vector is Refetched if
	other Exception
4	Fetch Interrupt Vector	HARDWARE
0	GPRs saved to Shadow Register Sets	HARDWARE
1	Read C0_Status, C0_SRSCtl,	HARDWARE
	C0_EPC in parallel, Adjust
	Stack Pointer
3	Save C0_Status, C0_SRSctl,	HARDWARE
	C0_EPC to Stack and Adjust
	Status, IPL, EXL
—	1st Instruction of ISR
10	Total

As Table 1 indicates, the number of cycles expended from the point the interrupt is latched and when the first instruction of the interrupt service routine is executed is decreased to 10, from 24, by the use of IAP.

II. INTERRUPT AUTOMATED PROLOGUE (IAP)

The use of Shadow Register Sets can decrease the overhead of saving usermode state values before executing an interrupt service routine. The Interrupt Automated Prologue (IAP) feature automates some of the software steps that would be needed to save control and status registers, e.g., COP0, state values before executing an interrupt service routine. Decreased latency to executing the first useful instruction of an interrupt service routine can be achieved by executing some of the steps using parallel hardware instead of serial execution of instructions.

In an embodiment, the IAP feature is only available when:

• • Shadow Register Sets are implemented (SRSCtl_Hss !=0)
  • External Interrupt Controller Mode is enabled (Config3_VEIC=1, IntCtl_VS !=0, Cause_IV=1, and Status_BEV=0)
  • IntCtl_APE=1

In an embodiment, the IAP feature only takes effect when an interrupt is signaled to the exception logic block and the exception priority logic has resolved the interrupt to be the highest priority exception to be handled. If an exception other than an interrupt is signaled, this feature does not take effect.

The IAP operation can be enabled with either a single stack pointer or with multiple stack pointers. In the example where only one stack pointer is being used the following steps are automated by the use of IAP:

• • 1. If IntCtl_UseKStk is zero, then TempStackPointer is updated with the value from GPR 29 of the Previous Shadow Register Set. If IntCtl_UseKStk is one, go to Step A. (see below).
  • 2. TempStackPointer is decremented by the value specified by the IntCtl_StkDec register field.
  • 3. The value in COP0 EPC register is stored to external memory using virtual address [TempStackPointer]+0x0.
  • 4. The value in COP0 Status register is stored to external memory using virtual address [TempStackPointer]+0x4.
  • 5. The value in COP0 SRSCtl register is stored to external memory using virtual address [TempStackPointer]+0x8.
  • 6. GPR 29 of the Current Shadow Register Set is written with the value of TempStackPointer.
  • 7. Status_IPL register field is updated with the value in Cause_RIPL.
  • 8. If IntCtl_ClrEXL is set, then KSU, ERL, and EXL fields of the Status register are cleared to zero.

The only sequence dependencies are (Implementations must maintain these dependencies):

• • Step 2 is dependent on Step 1 (or Step A below).
  • Steps 3-5 are dependent on Step 2.
  • Steps 7 & 8 are dependent on Step 4.
  • Steps 6-8 are dependent on Steps 3-5 reaching a stage at which no further exceptions can be generated.

In an embodiment, TempStackPointer is an internal register within the processor and is not visible to software. It is used so that the modification of GPR 29 does not happen until there is no longer any possibility of memory exceptions occurring during IAP. This allows the TLB handler to be used without modification for a TLB exception that happens during IAP.

In more complicated environments where multiple stack pointers are used, e.g., user-mode and kernel-mode, the IntCtl_UseKStk control bit can be used to select another stack point for the interrupt handling. For example, GPR 29 of the Shadow Register Set is used to hold the kernel stack pointer. GPR 29 of the Shadow Register Set 1 can be pre-initialized to hold the appropriate kernel stack pointer value. In an embodiment, the following steps illustrate how IAP works when the pre-initialized stack point is used, e.g., IntCtl_UseKStk is one.

• • A) If (interrupted instruction was executing in usermode) then TempStackPointer=GPR 29 of Shadow Register 1 else TempStackPointer=GPR 29 of Shadow Register Set used at the time of the interrupted instruction.
  • B) Go to Step 2 (above).

For Step A, if the interrupted instruction was already in kernel mode, then it would have been using the stack pointer value that was previously derived from the kernel stack pointer held in GPR 29 of Shadow Register 1.

III. EXCEPTIONS DURING IAP

In an embodiment, the memory store operations that occur during IAP may result in Address Error, e.g., address space privilege violation, TLB refill, e.g., TLB does not have an entry matching the requested address, TLB invalid, e.g., TLB entry matching the requested address is not valid, TLB modify, e.g., TLB entry matching the requested address is marked not-writeable and a store instruction is attempting to write a location within the entry's page, Cache Error, e.g., the lookup within the cache memory hierarchy resulted in a parity or uncorrectable Error-Correction-Code error instead of returning the request data, and Bus Error, e.g., the lookup within the external memory hierarchy resulted in an error instead of returning the requested data. exceptions. For example, if such memory exceptions occur during IAP:

• • The Cause_ExcCode register field reports the exception type.
  • Cause_AP register bit is set.
  • EPC is unchanged; points to the instruction which was originally interrupted.
  • All of the other exception reporting COP0 registers are updated as appropriate for the exception type. These registers reflect the effective word address that caused the exception, e.g., as if an individual SW instruction had caused the exception.
  • If the memory store operation uses a mapped address and there is no matching address in the TLB, the TLB refill exception handler (offset 0x0) is used. The other TLB related exceptions (invalid, modify) use the general exception handler (offset 0x180).
  • The Shadow Register Set designated by the SRSCtl_ESS register field is used for the memory exception.
  • The exception handler returns to the original code PC location, which is held in C0_EPC.
  • Since the interrupt is still asserted, the interrupt is signaled again and IAP is repeated. This time, it completes as the faulting condition had previously been fixed.

In this example, the IAP feature will run to completion unless one of these memory exceptions takes place. The IAP feature is not interruptible, that is, IAP is atomic from the point of view of another pending interrupt.

IV. INTERRUPT AUTOMATED EPILOGUE (IAE)

In an embodiment, the Interrupt Automated Epilogue is the mirrored operation of IAP. In preparation for returning to non-exception mode, this feature automates restoring COP0 Status, SRSCtl, and EPC registers from the one or more stacks. In an embodiment, the IAE functionality is made available through an instruction, for example the IRET instruction. In an example, the IRET instruction should only be used when:

• • Shadow Register Sets are implemented (SRSCtl_HSS !=0)
  • External Interrupt Controller Mode is enabled (Config3_VEIC=1, IntCtl_VS !=0, Cause_IV=1, and Status_BEV=0)

The IRET instruction is meant to reverse the effects of the Automated Interrupt Prologue feature. So the IRET instruction should only be used when the COP0 registers are saved onto the stack in the manner specified by the IAP feature.

V. EXCEPTIONS DURING IAE

In an embodiment, the memory load operations that occur during IAE may result in Address Error, TLB refill, TLB invalid, Cache Error, and Bus Error exceptions. In an example, if such memory exceptions occur during IAE:

• • The Cause_ExcCode register field reports the exception type
  • EPC is updated to the IRET instruction location.
  • All of the other exception reporting COP0 registers are updated as appropriate for the exception type. These registers reflect the effective word address that caused the exception, e.g., as if an individual LW instruction had caused the exception.
  • If the memory store operation uses a mapped address and there is no matching address in the TLB, the TLB refill exception handler (offset 0x0) is used. The other TLB related exceptions (invalid) use the general exception handler (offset 0x180).
  • The Shadow Register Set designated by the SRSCtl_ESS register field is used for the memory exception.
  • The exception handler jumps to the IRET instruction, which is held in C0_EPC.
  • The IRET instruction now completes since the faulting condition was previously fixed. The IRET returns to the original code PC location, which is un-wound from the stack.

In this example, the IRET instruction will run to completion unless one of these memory exceptions takes place. The IRET instruction is not interruptible, that is, IRET is atomic from the point of view of another pending interrupt.

VI. INTERRUPT CHAINING

In an embodiment, the concept of interrupt chaining reduces the number of cycles needed to respond to an interrupt that is pending when returning from the current interrupt. An interrupt may be pending because the current interrupt handler has disabled interrupts, or because the pending interrupt has lower priority than the interrupt which is currently being processed. Typically, software must disable interrupts when restoring registers from a stack when finishing handling an exception. During such a time, another interrupt could be signaled. In such a situation, the new interrupt would be ignored until an instruction, e.g., the ERET instruction, clears a status indicator, e.g., the EXL bit, and has started execution at the return address pointed to by a register holding the content of the program prior to jumping to an exception handler, e.g., the EPC register. In an embodiment, during this time, the pipeline is flushed to complete the exception handling. When the subsequent interrupt is finally recognized by the exception logic, a second pipeline flush is necessary as the processor was about start executing the instructions at the return address.

In an embodiment, the Interrupt Chaining feature avoids the above described pipeline flushes by allowing an Interrupt Controller, e.g., Interrupt Controller 102 or other External Interrupt Controller unit, to update the interrupt signals sent to exception logic block 112 before the IRET instruction completes. If these signals represent an interrupt that is of a higher priority than the current priority, e.g., in Status_IPL, the IRET instruction will update the COP0 registers as if just entering exception mode. The IRET instruction will then jump directly to the new interrupt vector, thus avoiding the following steps:

• • 1. Flushing the pipeline in return to non-exception mode
  • 2. Clearing the Status_EXL bit
  • 3. Returning to the EPC address
  • 4. Flushing the pipeline a second time to enter exception mode.

In an embodiment, the Interrupt Chaining feature when used together with the Interrupt Automated Prolog and Interrupt Automated Epilog features also avoids the following steps:

• • Loading saved EPC and SRSCtl values from the stack before returning to the EPC instruction
  • Saving Status, EPC and SRSCtl values to the stack before processing the pending interrupt

However, in an embodiment, Interrupt Chaining is made available through the IRET instruction and is only available when:

• • Shadow Register Sets are implemented (SRSCtl_HSS !=0)
  • External Interrupt Controller Mode is enabled (Config3_VEIC=1, IntCtl_VS !=0, Cause_IV=1, and Status_BEV0)
  • IntCtl_ICE=1

FIG. 2 illustrates the layout and naming of an IntCtl register in system 200 referred to above, according to an embodiment of the present invention. FIGS. 3A-3L illustrate the naming and functionality of the fields within the IntCtl register in system 300 as shown in FIG. 2, according to an embodiment of the present invention. For example, FIGS. 3A, 3B and 3C describe, respectively, the IPTI, IPPCI, and IPFDC fields for interrupt compatibility and vectored interrupt modes. FIG. 3D describes the PF field for enabling the vector prefetching feature. FIG. 3E describes the ICE field for the IRET instruction that enables interrupt chaining. FIG. 3F describes the StkDec field used in the IAP feature that determines the number of words that are decremented from the value of stack pointer 113, e.g., GPR 29. FIG. 3G describes the ClrEXL field used in the IAP feature and the IRET instruction that determines if the KSU/ERL/EXL fields are cleared. FIG. 3H describes the APE field that determines if the IAP feature is enabled. FIG. 3I describes the UseKStk field that chooses which stack to use during IAP. FIGS. 3J and 3L describe reserved fields, not yet defined. FIG. 3K describes the VS field that specifies vector spacing.

VII. IRET INSTRUCTION

FIG. 14 illustrates the layout and naming of the IRET instruction referred to above, according to an embodiment of the present invention. The IRET instruction provides for an interrupt return with automated interrupt epilogue handling. The instruction can optionally jump directly to another interrupt vector without returning to the original return address as discussed above. The IRET instruction can be implemented in multiple instruction set architectures, for example the two possible numbering and names are shown in FIG. 4, the second set shown in parenthesis.

The IRET instruction automates some of the operations that are required when returning from an interrupt handler and can be used in place of other instructions at the end of interrupt handlers, e.g., ERET. The use of the IRET instruction is appropriate when using Shadow Register Sets and the EIC Interrupt mode. The automated operations of this instruction can be used to reverse the effects of the automated operations of the IAP feature.

If the EIC interrupt mode and the Interrupt Chaining feature are used, the IRET instruction can be used to shorten the time between returning from the current interrupt handler and handling the next requested interrupt.

If the Automated Prologue feature is disabled, then IRET behaves exactly like ERET.

If either the Status_ERL or Status_BEV bits are set, then IRET behaves exactly like ERET.

If Interrupt Chaining is disabled:

• • Interrupts are disabled. COP0 Status, SRSCtl, and EPC registers are restored from the stack. GPR 29 is incremented for the stack frame size. IRET then clears execution and instruction hazards, conditionally restores SRSCtl_CSS from SRSCtl_PSS, and returns at the completion of interrupt processing to the interrupted instruction pointed to by the EPC register.

If Interrupt Chaining is enabled:

• • Interrupts are disabled. COP0 Status register is restored from the stack. The priority output of the External Interrupt Controller is compared with the IPL field of the Status register.

If Status_IPL has a higher priority than the External Interrupt Controller value:

• • COP0 SRSCtl and EPC registers are restored from the stack. GPR 29 is incremented for the stack frame size. IRET then clears execution and instruction hazards, conditionally restores SRSCtl_CSS from SRSCtl_PSS, and returns to the interrupted instruction pointed to by the EPC register at the completion of interrupt processing.

If Status_IPL has a lower priority than the External Interrupt Controller value:

• • The value of GPR 29 is first saved to a temporary register then GPR 29 is incremented for the stack frame size. The EIC is signaled that the next pending interrupt has been accepted. This signaling will update the Cause_RIPL and SRSCtl_EICSS fields from the EIC output values. The SRSCtl_EICSS field is copied to the SRSCtl_CSS field, while the Cause_RIPL field is copied to the Status_IPL field. The saved temporary register is copied to the GPR 29 of the current SRS. The KSU and EXL fields of the Status register are optionally set to zero. No barrier for execution hazards or instruction hazards is created. IRET finishes by jumping to the interrupt vector driven by the EIC.

In an embodiment, the IRET instruction does not cause the execution of the next instruction (i.e., it has no delay slot). This instruction is re-startable if an exception occurs during the memory transactions accessing the stack. All of the stack memory transactions must be completed before Status, SRSCtl and EPC are modified by this instruction. If an exception occurs before IRET completes:

• • 1. the SRSCtl and EPC registers are not updated
  • 2. only the EXL bit has been changed in the Status register.

VIII. RESTRICTION IN THE IRET INSTRUCTION

In an embodiment, the operation of the processor is UNDEFINED if the IRET instruction is executed in the delay slot of a branch or jump instruction.

The operation of the processor is UNDEFINED if IRET is executed when either Shadow Register Sets are not enabled, or the EIC interrupt mode is not enabled.

In an example, if an IRET instruction is placed between an LL and SC instruction then such a placement will cause the SC instruction to fail.

The effective addresses used for stack transactions must be naturally-aligned. If either of the two least-significant bits of the address is non-zero, an Address Error exception occurs.

IRET implements a software barrier that resolves all execution and instruction hazards created by Coprocessor 0 state changes. The effects of this barrier begin with the instruction fetch and decode of the instruction at the PC to which the IRET returns.

In another embodiment, IRET does not restore SRSCtl_CSS from SRSCtl_PSS if Status_BEV=1 or Status_ERL=1, because any exception that sets Status_ERL to 1 (Reset, Soft Reset, NMI, or cache error) does not save SRSCtl_CSS in SRSCtl_PSS. If software sets Status_ERL to 1, it must be aware of the operation of an IRET that may be subsequently executed.

The stack transactions behave as individual LW operations with respect to exception reporting.

A Coprocessor Unusable Exception is signaled if access to Coprocessor 0 is not enabled.

To enable a clean transition from exception-mode to non-exception-mode, all of the COP0 registers modifications as well as the stack pointer modification must be completed as if this instruction is atomic. This is, interrupts are not accepted while the operations of this instruction are being processed. As previously stated, the memory transactions that are part of this instruction can cause address error, bus-error, parity/ECC, TLB miss/invalid/write exceptions.

Table 3 below represents pseudo code associated with the operation of the IRET instruction as follows:

TABLE 3
IRET Pseudo code
if IsCoprocessorEnabled(0) then
if (( IntCtlAPE == 0) | (StatusERL == 1) | (StatusBEV== 1))
Act as ERET // read Operation section of ERET description
else
if (ISAMode)
EPC ← PC31..1 || 1 // in case of memory exception
else
EPC ← PC // in case of memory exception
endif
temp ← 0x4 + GPR[29]
tempStatus ← LoadStackWord(temp)
ClearHazards( )
if ( (IntCtlICE == 0) | ((IntCtlICE == 1) &
(tempStatusIPL > EICRIPL)) )
temp ← 0x8 + GPR[29]
tempSRSCtl ← LoadStackWord(temp)
temp ← 0x0 + GPR[29]
tempEPC ← LoadStackWord(temp)
endif
// Only modify COP0 registers after no further possible exceptions
Status ← tempStatus
if ( (IntCtlICE == 0) | ((IntCtlICE == 1) &
(tempStatusIPL > EICRIPL)) )
GPR[29] ← GPR[29] + DecodedValue(IntCtlStkDec)
SRSCtl ← tempSRSCtl
EPC ← tempEPC
temp ← EPC
StatusEXL ← 0
if (ArchitectureRevision ≧ 2) and (SRSCtlHSS > 0) and
(StatusBEV = 0) then SRSCtlCSS ← SRSCtlPSS
endif
if IsMicroMIPSImplemented( ) then
PC ← temp31..1 || 0
ISAMode ← temp0
else
PC ← temp
endif
LLbit ← 0
CauseIC ← 0
ClearHazards( )
else
Signal_EIC_for_Next_Interrupt( )
(wait for EIC outputs to update)
CauseRIPL ← EICRIPL
SRSCtlEICSS ← EICSS
temp29 ← GPR[29]
GPR[29] ← GPR[29] + DecodedValue(IntCtlStkDec)
StatusIPL ← CauseRIPL
SRSCtlCSS ← SRSCtlEICSS
NewShadowSet ← SRSCtlEICSS
GPR[29] ← temp29
if (IntCtlClrEXL == 1)
StatusEXL ← 0
StatusKSU ← 0
endif
CauseIC ← 1
ClearHazards( )
PC ← CalcIntrptAddress( )
endif
endif
else
SignalException(CoprocessorUnusable, 0)
endif
function LoadStackWord(vaddr)
if vAddr1..0 ≠ 02 then
SignalException(AddressError)
endif
(pAddr, CCA) ← AddressTranslation (vAddr, DATA, LOAD)
memword ← LoadMemory (CCA, WORD, pAddr, vAddr, DATA)
LoadStackWord ← memword
endfunction LoadStack Word
function CalcIntrptAddress( )
if StatusBEV = 1
vectorBase ← 0xBFC0.0200
else
if (ArchitectureRevision ≧ 2)
vectorBase ← EBase31..12 || 011)
else
vectorBase ← 0x8000.0000
endif
endif
if (CauseIV = 0)
vectorOffset = 0x180
else
if (StatusBEV = 1) or (IntCtlVS = 0)
vectorOffset = 0x200
else
if (Config3VEIC = 1 and EIC_Option=1)
VectorNum = CauseRIPL
elseif (Config3VEIC = 1 and EIC_Option=2)
VectorNum = EIC_VectorNum
elseif (Config3VEIC = 0 )
VectorNum = VIntPriorityEncoder( )
endif
if (Config3VEIC = 1 and EIC_Option=3)
vectorOffset = EIC_VectorOffset
else
vectorOffset = 0x200 + (VectorNum × (IntCtlVS || 05))
endif
endif
endif
CalcIntrptAddress = vectorBase | vectorOffset
endfunction CalcIntrptAddress

IX. METHOD

FIG. 15 illustrates method 1500 for automatic hardware interrupt handling, according to an embodiment of the present invention. In the example shown in FIG. 15, the method starts with step 1502 that includes receiving a first interrupt request. Step 1504 continues by fetching a first interrupt vector. Step 1506 contains a reading a plurality of processor state values in parallel. Step 1508 continues by updating a stack pointer with a value from a shadow register. Step 1510 concludes by storing the plurality of processor state values in a plurality of memory locations specified by the updated stack register, in preparation for entering an exception mode and prior to execution of an interrupt service routine.

X. SOFTWARE EMBODIMENTS

For example, in addition to implementations using hardware (e.g., within or coupled to a Central Processing Unit (“CPU”), microprocessor, microcontroller, digital signal processor, processor, exception logic block, System on Chip (“SOC”), or any other programmable or electronic device), implementations may also be embodied in software (e.g., computer readable code, program code and/or instructions disposed in any form, such as source, object or machine language) disposed, for example, in a computer usable (e.g., readable) medium configured to store the software. Such software can enable, for example, the function, fabrication, modeling, simulation, description, and/or testing of the apparatus and methods described herein. For example, this can be accomplished through the use of general programming languages (e.g., C, C++), hardware description languages (HDL) including Verilog HDL, VHDL, SystemC Register Transfer Level (RTL) and so on, or other available programs, databases, and/or circuit (i.e., schematic) capture tools. Such software can be disposed in any known non-transitory computer readable storage medium including semiconductor, magnetic disk, optical disk (e.g., CD-ROM, DVD-ROM, etc.). In addition, such software can also be stored as a computer data signal embodied in a computer usable (e.g., readable) medium (e.g., any other medium including digital, optical, or analog-based medium). As such, the software can be transmitted over communication networks including the Internet and intranets.

It should be understood that the apparatus and method embodiments described herein may be included in a semiconductor intellectual property core, such as a microprocessor core (e.g., embodied in HDL) and transformed to hardware in the production of integrated circuits. Additionally, the apparatus and methods described herein may be embodied as a combination of hardware and software.

XI. CONCLUSION

The summary and abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventors, and thus, are not intended to limit the present invention and the claims in any way.

The embodiments herein have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.

The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others may, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the claims and their equivalents.

Claims

1. A method of interrupt handling, comprising:

determining a privilege level associated with a first interrupt;

updating a first stack pointer register with a value copied from a first fixed register,

storing a value associated with the first interrupt in a first memory address at a location identified by the first stack pointer register, and

disallowing access to the first fixed register from a process operating at a second privilege level, wherein the second privilege level is lower than the privilege level of the first interrupt.

2. The method of claim 1, further comprising:

determining a privilege level of a second interrupt;

updating a second stack pointer register with a value copied from a third stack pointer register associated with an interrupted process operating at a third privilege level, wherein the third privilege level is equal to the privilege level of the second interrupt;

modifying the value in the second stack pointer register, and

storing a value associated with the second interrupt in a second memory address at a location identified by the second stack pointer register.