HK1162699A - System and method for automatic hardware interrupt handling - Google Patents

Description

System and method for automatic hardware interrupt handling

Technical Field

Embodiments of the present invention relate generally to microprocessors, and more particularly to interrupt processing.

Background

Within a computer processing environment, an interrupt is an event that aborts normal program execution. Programs are typically executed in an ordered fashion on a microprocessor. Typical execution is altered by instructions that explicitly deviate from program flow, such as jump instructions and branch instructions. Interrupts interfere with normal instruction execution. Typically, upon detection of an interrupt, a special program known as an interrupt handler or interrupt service routine is executed, the contents of which switch the system. Content switching includes storing the state (e.g., content) of the processor, servicing the interrupt, and storing the processed content again so that execution of the instruction can resume from the point before the interrupt.

The process of content switching requires a large number of processor cycles in which the processor executes an interrupt service routine. Such interrupt service routines typically clean the processor's pipeline (pipeline) and save a number of state registers in memory. When the complexity of a program increases, time consuming execution of the interrupt service routine reduces the availability of processor resources available for other program functions.

Disclosure of Invention

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

Accordingly, what is needed is a method and system for servicing interrupt requests in a more real-time and efficient manner.

In one embodiment of the present invention, a processing system is provided that includes an interrupt pin, a plurality of registers, a stack pointer, and an auto-interrupt system. The plurality of registers store a plurality of processor state values. When the system detects an interrupt on an interrupt pin, the system prepares to enter an exception mode in which the auto-interrupt system fetches an interrupt vector, updates a stack pointer, and, prior to executing an interrupt service routine, reads processor state values from registers in parallel and stores the processor state values in memory locations based on the updated stack pointer.

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

In a further embodiment of the present invention, a non-transitory computer-readable storage medium is provided that includes computer-readable program code for generating a processor, wherein the program code includes computer-readable code to generate an interrupt pin, computer-readable code to generate a plurality of registers storing a plurality of processor state values, computer-readable code to generate a stack pointer, and computer-readable code to generate an automatic interrupt system. The automatic interrupt system detects interrupts on the interrupt pin and fetches an interrupt vector, updates the stack pointer, and, prior to executing the interrupt service routine, reads multiple processor state values in parallel from a register and stores the values in a memory location specified by the updated stack pointer.

These and other embodiments and features, as well as the structure and operation of the various embodiments, are described in detail below with reference to the accompanying drawings. The present invention is not limited to the specific embodiments described herein. These 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.

Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbols indicate corresponding parts. Further, the accompanying drawings, which are incorporated herein and form a part of the specification, illustrate 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 pertinent art to make and use the invention.

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

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

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

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

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

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

7A-7J present register field descriptions of registers within SRS control registers according to one embodiment of the present invention.

FIG. 8 illustrates the format of the Cause register according to one embodiment of the invention.

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

FIG. 10 illustrates the format of an exception program count register according to one embodiment of the present invention.

FIG. 11 presents a register field description of a register within an exception program count register in accordance with an embodiment of the present invention.

FIG. 12 illustrates a configuration register format according to one embodiment of the invention.

13A-13W present register field descriptions of registers within a configuration register, according to one embodiment of the invention.

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

FIG. 15 is a flow diagram of a method for automatic hardware interrupt handling, according to one embodiment of the 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 drawing features 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 description of various "embodiments" of the invention. Thus, specific "embodiments" are an insight of the present invention, but each specific "embodiment" does not in itself represent the entire invention. In many cases, individual elements from one particular embodiment may be replaced with different elements in another embodiment performing similar or corresponding functions. It is expected that those skilled in the art, having the benefit of 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 to in the specification as "one embodiment," "an embodiment," "one exemplary embodiment," etc. These references indicate that the illustrated embodiments may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include every illustrated feature, structure, or characteristic. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect 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, the processing system 100 including a system for automatic hardware interrupt handling, according to one embodiment of the invention. The system 100 includes a processor 110 coupled to an interrupt controller 102, where the interrupt controller 102 is connected to a plurality of interrupt lines 104. The interrupt controller 102 prioritizes the interrupts 104 and generates interrupt requests to the processor 110 using the interrupt lines 106. The interrupt controller may also pass the interrupt vector 108 to the processor 110.

Within processor 110, there is exception logic 112, an interrupt vector generator 116, shadow register set control registers 120, a general purpose register set 124, and a plurality of shadow register sets 126. In one embodiment, the shadow register set 126 is replaced with normal General Purpose Registers (GPRs) 124 that may be used in some processor operating modes (e.g., core mode and exception mode) or in response to a vector interrupt or exception. Once the shadow register set 126 is restricted to a particular mode, the addressable registers in GPRs 124 that work with the particular shadow register set specific to that mode are queried.

Exception logic 112 within processor 110 receives from interrupt circuit 106 and determines which, if any, exceptions are to be handled. If an exception, such as an interrupt, is to be handled, exception logic 112 sends a signal 114 to exception vector generator 125. Exception vector generator 125 uses signal 114 to generate instruction address 118 for handling the exception. The exception vector generator 125 may also receive the vector 108 directly from the interrupt controller 102. Instruction address 118 is then sent to program counter logic 109 to change the instruction execution flow.

The shadow register set control registers 120 include a Current Shadow Set (CSS) register 121 and a Previous Shadow Set (PSS) register 123. Exception logic block 112 sends signal 126 to shadow register set control register 120 and associated logic to switch to the appropriate shadow register set allocated for the exception to be handled. As previously mentioned, there is a need to reduce the time required to service an interrupt service request. In one embodiment, Table 1 below summarizes the number of cycles that the processor 110 must spend in order to begin executing interrupt service routines that are generated through the detection of interrupts (e.g., interrupts 104 and 114) using software-based interrupt processing.

One possible format for the interrupt control register is shown in fig. 2 and will be discussed in more detail later. Exemplary field descriptions of registers within the interrupt control register may be found in fig. 3A-3L and will be discussed in more detail later.

An exemplary format of the COP0 status register in the system 400 is shown in fig. 4. An exemplary field description of a register within a status register may be found in fig. 5A-5T of system 500 according to one embodiment of the invention.

An exemplary format of the COP0SRSCtl register in system 600 is shown in fig. 6. Exemplary field descriptions of registers within the SRSCtl register are shown in FIGS. 7A-7J of system 700.

An exemplary format of the COP0 Cause register in the system 800 is shown in FIG. 8. Exemplary field descriptions of registers within the Cause register are shown in FIGS. 9A-9N of system 900.

An exemplary format of the COP0EPC register in the system 1000 is shown in fig. 10. An exemplary field description of a register within the EPC register is shown in FIG. 11 of the system 1100.

An exemplary format of the COP0 configuration register in the system 1200 is shown in fig. 12. Exemplary field descriptions of registers within the configuration registers are shown in fig. 13A-13W of system 1300.

Table 1: clock cycles associated with Interrupt Service Routine (ISR) processing

As shown in Table 1, it takes a total of 24 cycles for the first instruction from the point at which the interrupt is latched to the interrupt service routine to be executed. In another embodiment, Table 2 below summarizes the number of cycles that the processor 110 must spend in order to begin execution of an interrupt service routine that is generated through detection of interrupts (e.g., interrupts 104 and 114) using hardware-based interrupt handling logic that uses an Interrupt Automatic Prologue (IAP).

Table 2: clock cycles associated with Interrupt Service Routine (ISR) processing using IAP

As shown in table 1, by using the IAP, the number of cycles taken from the point at which the interrupt is latched to the first instruction of the interrupt service routine to be executed is reduced from 24 to 10.

Interrupt automatic introduction program (IAP)

The use of shadow register sets may reduce the cost of saving user mode state values prior to executing an interrupt service routine. The interrupt automatic Introduction (IAP) function automatically operates some of the software steps required to save the state values of the control and status registers, e.g., COP0, prior to executing the interrupt service routine. The reduced latency of executing the first useful instruction of the interrupt service routine may be obtained by performing some steps using parallel hardware rather than serially executed instructions.

In one embodiment, the IAP feature is only available if:

the shadow register set is implemented (SRSCTLHSS! 0)

Enabling external interrupt controller mode (Config 3)_VEIC＝1，IntCtl_VS！＝0，Cause_IV＝1，and Status_BEV＝0)

·IntCtl_APE＝1

In one embodiment, the IAP function only functions when an interrupt is signaled to the exception logic block and the exception priority logic has resolved the interrupt of the exception with the highest priority to be handled. This function does not work if an exception, rather than an interrupt, is signaled.

IAP operations can be performed with a single stack pointer or multiple stack pointers. In the example where only one stack pointer is used, the following steps are automatically performed by using the IAP:

1. if IntCtl is present_UseKStkZero, TempStackPointer is updated to the value of GPR29 from the previous shadow register set. If IntCtl is present_UseKStkIs 1, proceed to step a (below).

TempStackPointer by IntCtl_StkDecThe value specified by the register field is decremented.

3. The value in the COP0EPC register is stored to external memory using the virtual address [ TempStackPointer ] +0x 0.

4. The value in the COP0 status register is stored to external memory using the virtual address [ TempStackPointer ] +0x 4.

5. The value in the COP0SRSCtl register is stored to the external memory using the virtual address [ TempStackPointer ] +0x 8.

6. The value of TempStackPointer is written to GPR29 of the current shadow register set.

7. By Cause_RIPLValue in update Status_IPLA register field.

8. If IntCtl is set_ClrEXLThe KSU, ERL and EXL fields of the status register are cleared.

The only sequential dependencies are (embodiments must maintain these dependencies):

step 2 is subordinate to step 1 (or step a below).

Steps 3-5 are dependent on step 2.

Step 7&8 is dependent on step 4.

Step 6-8 is dependent on step 3-5, step 3-5 reaching a stage where no further anomalies can be generated.

In one embodiment, TempStackPointer is an internal register within the processor and is not visible to software. The TempStackPointer is used so that the modification of GPR29 does not occur until there are no longer any possible memory exceptions during IAP. This allows the TLB handler to be used without modifying TLB exceptions that occur during the IAP.

In more complex environments where multiple stack pointers are used, e.g., in user mode and core mode, IntCtl may be used_UseKStkA control bit to select another stack indication for interrupt handling. For example, GPRs 29 of the shadow register set are used to hold core stack pointers. GPRs 29 of shadow register set 1 may be pre-initialized to hold the appropriate core stack pointer value. In one embodiment, the following steps illustrate the use of a pre-initialized stack indication, such as IntCtl_UseKStkAt 1, how the IAP works.

A) If (executing the interrupt instruction in user mode) TempStackPointer is the GPR29 of the shadow register 1, else TempStackPointer is the GPR29 of the shadow register set used at the time of the interrupt instruction.

B) Proceed to step 2 (above).

For step A, if the interrupt instruction is already in core mode, then the stack pointer value previously obtained from the core stack pointer held in GPR29 of shadow register 1 is used.

Abnormalities during IAP

In one embodiment, memory store operations occurring during IAP may result in address errors, e.g., address space privilege violations; a TLB reload, e.g., the TLB does not have an entry matching the requested address; TLB invalidation, e.g., a TLB entry invalidation matching the requested address; TLB modifications, e.g., a TLB entry that matches the requested address is marked as not writable and a store instruction attempts to write a location within the page of the entry; cache errors, e.g., lookups within the cache hierarchy resulting in parity or incorrect Error-Correction-Code (Error-Correction-Code) errors rather than returning the requested data; and bus errors, e.g., a lookup within the external memory hierarchy results in an error rather than returning the requested data, an exception. For example, if such a memory exception occurs during IAP:

·Cause_ExcCodethe register field reports the exception type.

·Cause_APThe register bit is set.

EPC unchanged; pointing to the originally interrupted instruction.

All other exception reporting COP0 registers are updated appropriately for the exception type. These registers reflect the valid word address that caused the exception, e.g., as if a separate SW instruction caused the exception.

If the memory store operation uses a mapped address and there is no matching address in the TLB, then the exception handler is reloaded using the TLB (offset 0x 0). Other TLB-related exceptions (invalidation, modification) use a general purpose exception handler (offset 0x 180).

From SRSCtl_ESSThe shadow register set specified by the register field is used for memory exceptions.

The exception handler returns to the original code PC location held in C0_ EPC.

Since the interrupt is always present, the interrupt is signaled again and the IAP is repeated. At this point, the IAP completes when the fault condition is previously determined.

In this example, the IAP function will run to completion unless one of these memory exceptions occurs. The IAP feature is uninterruptible, i.e., the IAP is atomic from the point of view of other pending interrupts.

Interrupt automatic closing program (IAE)

In one embodiment, the interrupt automatic endgate is a mirror operation of the IAP. In preparation for returning to non-exception mode, this function automatically restores COP0 Status, SRSCtl, and EPC registers from one or more stacks. In one embodiment, the IAE function is made available by an instruction, such as an IRET instruction. In one example, the IRET instruction should only be used if:

implement shadow register set (SRSCtl)_HSS！＝0)

Enabling external interrupt controller mode (Config 3)_VEIC＝1，IntCtl_VS！＝0，Cause_IV＝1，and Status_BEV＝0)

The IRET instruction implies reversing the role of auto-interrupt prolog-program functionality. Thus, the IRET instruction should only be used when the COP0 register is saved onto the stack in a manner specified by the IAP function.

Anomaly during IAE

In one embodiment, memory load operations occurring during an IAE may cause address errors, TLB reloads, TLB invalidations, cache errors, and bus error exceptions. In one example, if such a memory exception occurs during an IAE:

·Cause_ExcCoderegister field reporting exception type

EPC is updated to IRET instruction location.

All other exception reporting COP0 registers are updated appropriately for the exception type. These registers reflect the effective word address that caused the exception, e.g., as if a separate LW instruction caused the exception.

If the memory store operation uses a mapped address and there is no matching address in the TLB, then the exception handler is reloaded using the TLB (offset 0x 0). Other TLB-related exceptions (invalidations) use a general purpose exception handler (offset 0x 180).

From SRSCtl_ESSThe shadow register set specified by the register field is used for memory exceptions.

The exception handler jumps to the IRET instruction held in C0_ EPC.

Because the fault status was previously determined, the IRET instruction is now complete. IRET returns to the original code PC location, which is not affected by the stack.

In this example, the IRET instruction will run to completion unless one of these memory exceptions occurs. The IRET instruction is not interruptible, i.e., from the perspective of other pending interrupts, the IRET is atomic.

VI. interrupt chain

In one embodiment, the concept of an interrupt chain reduces the number of cycles required to respond to an interrupt pending when returning from the current interrupt. Interrupts may be pending because the current interrupt handler disables interrupts, or because pending interrupts have a lower priority than the interrupt currently being processed. Typically, software must disable interrupts when restoring registers from the stack upon completion of the handling of exceptions. During this time, other interrupts may be signaled. In this case, the new interrupt will be ignored until an instruction, such as an ERET instruction, clears a status indicator, such as an EXL bit, and begins execution at the return address pointed to by the register holding the contents of the program, e.g., the EPC register, before jumping to the exception handler. In one embodiment, during this time, the pipeline is flushed to complete exception handling. When a subsequent interrupt is eventually recognized by the exception logic, a second pipeline flush is necessary because the processor begins executing the instruction at the return address.

In one embodiment, the interrupt chain functionality avoids the pipeline flush described above by allowing an interrupt controller (e.g., interrupt controller 102 or other external interrupt controller unit) to update the interrupt signal sent to exception logic 112 before the IRET instruction completes. If these signals indicate, for example, Status_IPLIf there is an interrupt with a higher priority than the current priority, the IRET instruction will update the COP0 register as if it had just entered exception mode oneAnd (5) sampling. The IRET instruction will then jump directly to the new interrupt vector, thus avoiding the following steps:

1. cleaning up pipelines on return to non-exception mode

2. Clearing Status_EXLBit

3. Return to EPC address

4. The pipeline is cleaned up a second time to enter an exception mode.

In one embodiment, the interrupt chain function, when used with the interrupt automatic prolog and interrupt automatic epilogue functions, also avoids the steps of:

load saved EPC and SRSCtl values from the stack before returning to the EPC instruction

Saving Status, EPC, and SRSCtl values to the stack before handling pending interrupts

However, in one embodiment, the interrupt chain is available through the IRET instruction and is only available if:

implement shadow register set (SRSCtl)_HSS！＝0)

Enabling external interrupt controller mode (Config 3)_VEIC＝1，IntCtl_VS！＝0，Cause_IV＝1，and Status_BEV＝0)

·IntCtl_ICE＝1

FIG. 2 illustrates the layout and naming of the IntCtl register in what is referred to above as system 200, according to one embodiment of the present invention. Figures 3A-3L illustrate the naming and function of fields within the IntCtl register in the system 300 shown in figure 2, according to one embodiment of the invention. For example, fig. 3A, 3B, and 3C illustrate IPTI, IPPCI, and IPFDC fields for interrupt compatibility and vector interrupt mode, respectively. Fig. 3D illustrates the PF field for enabling the vector pre-fetch function. FIG. 3E illustrates the ICE field of an IRET instruction for enabling an interrupt chain. Fig. 3F illustrates the StkDec field used in the IAP feature function that determines the number of words reduced from the value of the stack pointer 113, e.g., GPR 29. FIG. 3G illustrates the ClrEXL field used in the IAP function and an IRET instruction that determines whether the KSU/ERL/EXL field is cleared. Fig. 3H illustrates the APE field that determines whether the IAP function is enabled. Fig. 3I illustrates the UseKStk field that selects which stack to use during IAP. Fig. 3J and 3L illustrate reserved fields, which are undefined. Fig. 3K illustrates the VS field specifying the vector space.

IRET instruction

FIG. 14 illustrates the layout and naming of an instruction referred to above as an IRET instruction according to one embodiment of the present invention. The IRET instruction provides interrupt return with automatic interrupt epilogue processing. The instruction may optionally jump directly to other interrupt vectors without returning to the original return address as described above. The IRET instruction can be implemented in a multiple instruction group structure, for example, two possible numbering and names are shown in fig. 4, with the second group shown as an intervening component.

The IRET instruction automatically performs some of the operations required on return from the interrupt handler, and the operations may be used to replace other instructions at the end of the interrupt handler, such as the ERET. When using shadow register sets and EIC interrupt mode, it is appropriate to use the IRET instruction. Such automatic operation of the instructions can be used to reverse the effect of the automatic operation of the IAP function.

If EIC interrupt mode and interrupt chain functionality are used, the IRET instruction may be used to shorten the time between returning from the current interrupt handler and processing the next requested interrupt.

If the auto prolog program functionality is disabled, then IRET operates exactly the same as ERET.

If Status is set_ERLOr Status_BEVIRET then operates exactly the same as ERET.

If the broken link is disabled:

interrupts are disabled. The COP0 state, SRSCtl and EPC registers are restored from the stack. GPR29 increases due to stack frame size. IRET followed by clearing execution and instruction hazards, conditionally from SRSCtl_PSSRecovery of SRSCtl_CSSAnd returns to the interrupted instruction pointed to by the EPC register upon completion of interrupt processing.

If the broken chain is enabled:

interrupts are disabled. The COP0 status register is restored from the stack. The priority output of the external interrupt controller is compared to the IPL field of the status register.

If Status_IPLHas a higher priority than the external interrupt controller value:

the COP0SRSCtl and EPC are recovered from the stack. GPR29 increases due to stack frame size. IRET followed by clearing execution and instruction hazards, conditionally from SRSCtl_PSSRecovery of SRSCtl_CSSAnd returns to the interrupted instruction pointed to by the EPC register upon completion of interrupt processing.

If Status_IPLHas a lower priority than the external interrupt controller value:

the value of GPR29 is first saved to a temporary register, after which GPR29 is increased by the stack frame size. The EIC is signaled that the next pending interrupt is accepted. This signal tells about the Cause_RIPLAnd SRSCtl_EICSSThe field is updated from the EIC output value. SRSCtl_EICSSFields are copied to SRSCtl_CSSField, simultaneous Cause_RIPLFields are copied to Status_IPLA field. The saved temporary register is copied to GPR29 of the current SRS. The KSU and EXL fields of the status register are optionally set to zero. No barrier to execution hazards or instruction hazards is created. IRET is done by jumping to an interrupt vector driven by EIC.

In one embodiment, the IRET instruction does not cause execution of the next instruction (i.e., it does not have a latency gap). Such an instruction may be restarted if an exception occurs during a memory transaction that accesses the stack. All stack memory transactions must complete before Status, SRSCtl, and EPC are modified by the instruction. If an exception occurs before IRET is completed:

1. not updating SRSCtl and EPC registers

2. Only the EXL bit is changed in the status register.

Constraints in IRET instruction

In one embodiment, if the IRET instruction executes in a delayed time interval of a branch or jump instruction, the operation of the processor is UNDEFINED (UNDEFINED).

If the IRET is executed when the shadow register set is not enabled or EIC interrupt mode is not enabled, then the operation of the processor is UNDEFINED.

In one example, if an IRET instruction is placed between LL and SC instructions, such a setting will cause a failure of the SC instruction.

The effective addresses for stack transactions must be naturally aligned. An address error exception occurs if either of the two least significant bits of the address is non-zero.

IRET implements a software barrier that addresses all execution and instruction hazards resulting from coprocessor 0 state changes. The role of this barrier starts with instruction fetch and decode the instruction at the PC where IRET returns.

In another embodiment, if Status_BEV1 or Status_ERLIf 1, then IRET is not selected from SRSCtl_PSSRecovery of SRSCtl_CSSBecause Status will be_ERLAny exception set to 1 (reset, software reset, NMI, or cache error) is not in SRSCtl_PSSIn-store SRSCtl_CSS. If the software will Status_ERLSet to 1, it must know the operation of the IRET that may be performed subsequently.

The stack transaction operates as a separate LW operation with respect to exception reporting.

If access to coprocessor 0 is not enabled, a coprocessor unavailable exception is signaled.

To enable a complete transition from exception mode to non-exception mode, all COP0 register modifications and stack pointer modifications must be done as if such instructions were atomic. That is, interrupts are not accepted while the operation of such instructions is being handled. As previously described, memory transactions that are part of such instructions may cause address errors, bus errors, parity/ECC, TLB miss/invalidation/write exceptions.

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

table 3: IRET pseudo code

IX. method

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

Software embodiment

For example, in addition to implementations using hardware (e.g., within or coupled to a central processing unit ("CPU"), microprocessor, microcontroller, digital signal processor, exception logic, 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 configured in any form, such as source, object, or machine language), for example, in a computer usable (e.g., readable) medium configured to store the software. Such software may enable, for example, the function, fabrication, modeling, simulation, illustration, and/or testing of the apparatus and methods described herein. This may be accomplished, for example, using general programming languages (e.g., C, C + +), Hardware Description Languages (HDL) including Verilog HDL, VHDL, system C Register Transfer Level (RTL), etc., 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.). Such software can also be stored as a computer data signal embodied in a computer usable (e.g., readable) medium (e.g., including any other medium that is based on digital, optical, or analog media). Thus, the software may 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 that the apparatus and method embodiments described herein may be transformed to hardware in the production of integrated circuits. Furthermore, the apparatus and methods described herein may be embodied as a combination of hardware and software.

Conclusion XI

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

The embodiments herein are 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 can 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 can, by applying current knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments without undue experimentation and without departing from the basic concept of the present invention. Therefore, such changes 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 following claims and their equivalents.

Claims (23)

1. A processing system, comprising:

a processor, comprising:

interrupting the pin;

a plurality of registers configured to store a plurality of processor state values;

a stack pointer; and

an auto-interrupt system configured, when a first interrupt is detected on the interrupt pin and an exception mode is ready to be entered, to cause:

a first interrupt vector is obtained and a first interrupt vector is obtained,

the stack pointer is updated, and

the plurality of processor state values are read from the plurality of registers in parallel and stored to a plurality of memory locations specified by the updated stack pointer prior to execution of the interrupt service routine.

2. The processing system of claim 1, wherein the parallel reading from the plurality of registers and the updating of the stack pointer are done in the same cycle.

3. The processing system of claim 1, further comprising:

a speculative acquisition system configured to speculatively acquire an interrupt vector.

4. The processing system of claim 1, wherein the processor state values comprise values in EPC registers, values in status registers, and values in shadow register set control registers.

5. The processing system of claim 1, wherein in preparation for returning to a non-exception mode, the auto-interrupt system concurrently restores the plurality of processor state values stored in the memory location specified by the updated stack pointer into the plurality of registers.

6. The processing system of claim 5, further comprising:

an interrupt chain system configured to process the received second interrupt before restoring the processor state value.

7. The processing system of claim 6, wherein obtaining the second interrupt vector does not include flushing the pipeline to return to a non-exception mode or flushing the pipeline a second time to enter an exception mode.

8. A method of processor interrupt handling, comprising:

receiving a first interrupt request;

acquiring a first interrupt vector;

reading a plurality of processor state values in parallel;

updating the stack pointer with the value from the shadow register; and

storing the plurality of processor state values in a plurality of memory locations specified by the updated stack register in preparation for entering the exception mode and prior to executing the interrupt service routine.

9. The method of claim 8, wherein the parallel reading of processor state values and the updating of the stack pointer are done in the same cycle.

10. The method of claim 8, wherein said obtaining a first interrupt vector is done speculatively.

11. The method of claim 8, wherein the processor status values comprise a value in an EPC register, a value in a status register, and a value in a shadow register set control register.

12. The method of claim 8, further comprising restoring the plurality of processor state values stored in the memory location specified by the updated stack pointer in parallel to the plurality of registers in preparation for returning to the non-exception mode.

13. The method of claim 12, further comprising:

processing the received second interrupt before restoring the processor state value.

14. The method of claim 13, wherein obtaining the second interrupt vector does not include flushing the pipeline to return to a non-exception mode or flushing the pipeline a second time to enter an exception mode.

15. A non-transitory computer-readable storage medium having computer-readable program code embodied thereon for generating a processor, the computer-readable program code comprising:

computer readable code for generating an interrupt pin;

computer readable code for generating a plurality of registers configured to store a plurality of processor state values;

computer readable code for generating a stack pointer; and

computer readable code for generating an auto-interrupt system, the auto-interrupt system configured to detect a first interrupt on the interrupt pin,

wherein a first interrupt vector is obtained and,

the stack pointer is updated, and

wherein the plurality of processor state values are read in parallel from the plurality of registers and stored to a plurality of memory locations specified by the updated stack pointer prior to execution of an interrupt service routine.

16. The non-transitory computer readable storage medium of claim 15, wherein the parallel reading from the plurality of registers and the updating of the stack pointer are completed in a same cycle.

17. The non-transitory computer readable storage medium of claim 15, further comprising:

computer readable code for generating a speculative acquisition system configured to speculatively acquire interrupt vectors.

18. The non-transitory computer readable storage medium of claim 15, wherein the processor state values comprise values in EPC registers, values in status registers, and values in shadow register set control registers.

19. The non-transitory computer readable storage medium of claim 15, wherein in preparation for returning to a non-exception mode, the auto-interrupt system concurrently restores the plurality of processor state values stored in the memory location specified by the updated stack pointer into the plurality of registers.

20. The non-transitory computer readable storage medium of claim 15, further comprising:

computer readable code for generating an interrupt chain system configured to process a received second interrupt before restoring the processor state value.

21. The non-transitory computer readable storage medium of claim 15, wherein obtaining the second interrupt vector does not include flushing the pipeline to return to the non-exception mode or flushing the pipeline a second time to enter the exception mode.

22. A method of interrupt handling, comprising:

determining a privilege level associated with the first interrupt;

updating a first stack pointer register with the value copied from the first fixed register;

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

not allowing 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.

23. The method of claim 22, further comprising:

determining a privilege level of the second interrupt;

updating a second stack pointer register with a value copied from a third stack pointer register associated with interrupt processing 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 at a location in a second memory address identified by the second stack pointer register.