U.S. patent application number 13/758163 was filed with the patent office on 2013-06-20 for system and method for automatic hardware interrupt handling.
This patent application is currently assigned to MIPS Technologies, Inc.. The applicant listed for this patent is MIPS Technologies, Inc.. Invention is credited to David Lau, Erik K. NORDEN, James H. Robinson.
Application Number | 20130159578 13/758163 |
Document ID | / |
Family ID | 45527871 |
Filed Date | 2013-06-20 |
United States Patent
Application |
20130159578 |
Kind Code |
A1 |
NORDEN; Erik K. ; et
al. |
June 20, 2013 |
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.
Inventors: |
NORDEN; Erik K.; (Munchen,
DE) ; Lau; David; (San Jose, CA) ; Robinson;
James H.; (New York, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MIPS Technologies, Inc.; |
Sunnyvale |
CA |
US |
|
|
Assignee: |
MIPS Technologies, Inc.
Sunnyvale
CA
|
Family ID: |
45527871 |
Appl. No.: |
13/758163 |
Filed: |
February 4, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12847772 |
Jul 30, 2010 |
8392644 |
|
|
13758163 |
|
|
|
|
Current U.S.
Class: |
710/264 |
Current CPC
Class: |
G06F 9/30101 20130101;
G06F 9/4812 20130101; G06F 13/26 20130101; G06F 9/327 20130101;
G06F 9/30116 20130101 |
Class at
Publication: |
710/264 |
International
Class: |
G06F 13/26 20060101
G06F013/26 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] 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
[0002] 1. Field of Invention
[0003] Embodiments of the present invention relate generally to
microprocessors and in particular to interrupt handling.
[0004] 2. Related Art
[0005] 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.
[0006] 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
[0007] 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.
[0008] Therefore, what is needed are methods and systems to service
interrupt requests in a more timely and efficient manner.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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
[0013] 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.
[0014] FIG. 1 is a block diagram of a processing system, according
to an embodiment of the invention.
[0015] FIG. 2 illustrates the format of an interrupt control
register, according to an embodiment of the invention.
[0016] FIGS. 3A-3L present register field descriptions of registers
within an interrupt control register, according to an embodiment of
the present invention.
[0017] FIG. 4 illustrates the format of a status control register,
according to an embodiment of the invention.
[0018] FIGS. 5A-5T present register field descriptions of registers
within a status control register, according to an embodiment of the
present invention.
[0019] FIG. 6 illustrates the format of a SRS control register,
according to an embodiment of the invention.
[0020] FIGS. 7A-7J present register field descriptions of registers
within a SRS control register, according to an embodiment of the
present invention.
[0021] FIG. 8 illustrates the format of a Cause register, according
to an embodiment of the invention.
[0022] FIGS. 9A-9N present register field descriptions of registers
within a Cause register, according to an embodiment of the present
invention.
[0023] FIG. 10 illustrates the format of an Exception Program
Counter register, according to an embodiment of the invention.
[0024] FIG. 11 presents register field descriptions of registers
within an Exception Program Counter register, according to an
embodiment of the present invention.
[0025] FIG. 12 illustrates the format of a Configuration register,
according to an embodiment of the invention.
[0026] FIGS. 13A-13W presents register field descriptions of
registers within a Configuration register, according to an
embodiment of the present invention.
[0027] FIG. 14 illustrates the layout and naming of an interrupt
return instruction, according to an embodiment of the present
invention.
[0028] FIG. 15 is a flowchart of a method for automatic hardware
interrupt handling, according to an embodiment of the present
invention.
[0029] 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
[0030] 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.
[0031] 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
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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-US-00001 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
-- 1.sup.st Instruction of ISR 24 Total
[0042] 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-US-00002 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 -- 1.sup.st
Instruction of ISR 10 Total
[0043] 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)
[0044] 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.
[0045] In an embodiment, the IAP feature is only available when:
[0046] Shadow Register Sets are implemented (SRSCtl.sub.Hss !=0)
[0047] External Interrupt Controller Mode is enabled
(Config3.sub.VEIC=1, IntCtl.sub.VS !=0, Cause.sub.IV=1, and
Status.sub.BEV=0) [0048] IntCtl.sub.APE=1
[0049] 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.
[0050] 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: [0051] 1. If IntCtl.sub.UseKStk is zero, then
TempStackPointer is updated with the value from GPR 29 of the
Previous Shadow Register Set. If IntCtl.sub.UseKStk is one, go to
Step A. (see below). [0052] 2. TempStackPointer is decremented by
the value specified by the IntCtl.sub.StkDec register field. [0053]
3. The value in COP0 EPC register is stored to external memory
using virtual address [TempStackPointer]+0x0. [0054] 4. The value
in COP0 Status register is stored to external memory using virtual
address [TempStackPointer]+0x4. [0055] 5. The value in COP0 SRSCtl
register is stored to external memory using virtual address
[TempStackPointer]+0x8. [0056] 6. GPR 29 of the Current Shadow
Register Set is written with the value of TempStackPointer. [0057]
7. Status.sub.IPL register field is updated with the value in
Cause.sub.RIPL. [0058] 8. If IntCtl.sub.ClrEXL is set, then KSU,
ERL, and EXL fields of the Status register are cleared to zero.
[0059] The only sequence dependencies are (Implementations must
maintain these dependencies): [0060] Step 2 is dependent on Step 1
(or Step A below). [0061] Steps 3-5 are dependent on Step 2. [0062]
Steps 7 & 8 are dependent on Step 4. [0063] Steps 6-8 are
dependent on Steps 3-5 reaching a stage at which no further
exceptions can be generated.
[0064] 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.
[0065] In more complicated environments where multiple stack
pointers are used, e.g., user-mode and kernel-mode, the
IntCtl.sub.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.sub.UseKStk is one. [0066] 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. [0067] B) Go to Step 2 (above).
[0068] 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
[0069] 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: [0070] The Cause.sub.ExcCode register field reports the
exception type. [0071] Cause.sub.AP register bit is set. [0072] EPC
is unchanged; points to the instruction which was originally
interrupted. [0073] 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. [0074] 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). [0075] The Shadow Register Set designated by the
SRSCtl.sub.ESS register field is used for the memory exception.
[0076] The exception handler returns to the original code PC
location, which is held in C0_EPC. [0077] 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.
[0078] 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)
[0079] 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: [0080] Shadow Register
Sets are implemented (SRSCtl.sub.HSS !=0) [0081] External Interrupt
Controller Mode is enabled (Config3.sub.VEIC=1, IntCtl.sub.VS !=0,
Cause.sub.IV=1, and Status.sub.BEV=0)
[0082] 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
[0083] 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: [0084] The Cause.sub.ExcCode
register field reports the exception type [0085] EPC is updated to
the IRET instruction location. [0086] 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. [0087] 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). [0088] The Shadow Register Set designated by the
SRSCtl.sub.ESS register field is used for the memory exception.
[0089] The exception handler jumps to the IRET instruction, which
is held in C0_EPC. [0090] 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.
[0091] 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
[0092] 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.
[0093] 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.sub.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: [0094] 1.
Flushing the pipeline in return to non-exception mode [0095] 2.
Clearing the Status.sub.EXL bit [0096] 3. Returning to the EPC
address [0097] 4. Flushing the pipeline a second time to enter
exception mode.
[0098] 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: [0099]
Loading saved EPC and SRSCtl values from the stack before returning
to the EPC instruction [0100] Saving Status, EPC and SRSCtl values
to the stack before processing the pending interrupt
[0101] However, in an embodiment, Interrupt Chaining is made
available through the IRET instruction and is only available when:
[0102] Shadow Register Sets are implemented (SRSCtl.sub.HSS !=0)
[0103] External Interrupt Controller Mode is enabled
(Config3.sub.VEIC=1, IntCtl.sub.VS !=0, Cause.sub.IV=1, and
Status.sub.BEV0) [0104] IntCtl.sub.ICE=1
[0105] 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
[0106] 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.
[0107] 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.
[0108] 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.
[0109] If the Automated Prologue feature is disabled, then IRET
behaves exactly like ERET.
[0110] If either the Status.sub.ERL or Status.sub.BEV bits are set,
then IRET behaves exactly like ERET.
[0111] If Interrupt Chaining is disabled: [0112] 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.sub.CSS from SRSCtl.sub.PSS, and returns at the
completion of interrupt processing to the interrupted instruction
pointed to by the EPC register.
[0113] If Interrupt Chaining is enabled: [0114] 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.
[0115] If Status.sub.IPL has a higher priority than the External
Interrupt Controller value: [0116] 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.sub.CSS from SRSCtl.sub.PSS, and
returns to the interrupted instruction pointed to by the EPC
register at the completion of interrupt processing.
[0117] If Status.sub.IPL has a lower priority than the External
Interrupt Controller value: [0118] 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.sub.RIPL and SRSCtl.sub.EICSS fields from the EIC output
values. The SRSCtl.sub.EICSS field is copied to the SRSCtl.sub.CSS
field, while the Cause.sub.RIPL field is copied to the
Status.sub.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.
[0119] 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: [0120] 1. the SRSCtl and EPC registers are not updated
[0121] 2. only the EXL bit has been changed in the Status
register.
VIII. RESTRICTION IN THE IRET INSTRUCTION
[0122] 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.
[0123] 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.
[0124] 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.
[0125] 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.
[0126] 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.
[0127] In another embodiment, IRET does not restore SRSCtl.sub.CSS
from SRSCtl.sub.PSS if Status.sub.BEV=1 or Status.sub.ERL=1,
because any exception that sets Status.sub.ERL to 1 (Reset, Soft
Reset, NMI, or cache error) does not save SRSCtl.sub.CSS in
SRSCtl.sub.PSS. If software sets Status.sub.ERL to 1, it must be
aware of the operation of an IRET that may be subsequently
executed.
[0128] The stack transactions behave as individual LW operations
with respect to exception reporting.
[0129] A Coprocessor Unusable Exception is signaled if access to
Coprocessor 0 is not enabled.
[0130] 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.
[0131] Table 3 below represents pseudo code associated with the
operation of the IRET instruction as follows:
TABLE-US-00003 TABLE 3 IRET Pseudo code if IsCoprocessorEnabled(0)
then if (( IntCtl.sub.APE == 0) | (Status.sub.ERL == 1) |
(Status.sub.BEV== 1)) Act as ERET // read Operation section of ERET
description else if (ISAMode) EPC .rarw. PC.sub.31..1 || 1 // in
case of memory exception else EPC .rarw. PC // in case of memory
exception endif temp .rarw. 0x4 + GPR[29] tempStatus .rarw.
LoadStackWord(temp) ClearHazards( ) if ( (IntCtl.sub.ICE == 0) |
((IntCtl.sub.ICE == 1) & (tempStatus.sub.IPL >
EIC.sub.RIPL)) ) temp .rarw. 0x8 + GPR[29] tempSRSCtl .rarw.
LoadStackWord(temp) temp .rarw. 0x0 + GPR[29] tempEPC .rarw.
LoadStackWord(temp) endif // Only modify COP0 registers after no
further possible exceptions Status .rarw. tempStatus if (
(IntCtl.sub.ICE == 0) | ((IntCtl.sub.ICE == 1) &
(tempStatus.sub.IPL > EIC.sub.RIPL)) ) GPR[29] .rarw. GPR[29] +
DecodedValue(IntCtl.sub.StkDec) SRSCtl .rarw. tempSRSCtl EPC .rarw.
tempEPC temp .rarw. EPC Status.sub.EXL .rarw. 0 if
(ArchitectureRevision .gtoreq. 2) and (SRSCtl.sub.HSS > 0) and
(Status.sub.BEV = 0) then SRSCtl.sub.CSS .rarw. SRSCtl.sub.PSS
endif if IsMicroMIPSImplemented( ) then PC .rarw. temp.sub.31..1 ||
0 ISAMode .rarw. temp0 else PC .rarw. temp endif LLbit .rarw. 0
Cause.sub.IC .rarw. 0 ClearHazards( ) else
Signal_EIC_for_Next_Interrupt( ) (wait for EIC outputs to update)
Cause.sub.RIPL .rarw. EIC.sub.RIPL SRSCtl.sub.EICSS .rarw.
EIC.sub.SS temp29 .rarw. GPR[29] GPR[29] .rarw. GPR[29] +
DecodedValue(IntCtl.sub.StkDec) Status.sub.IPL .rarw.
Cause.sub.RIPL SRSCtl.sub.CSS .rarw. SRSCtl.sub.EICSS NewShadowSet
.rarw. SRSCtl.sub.EICSS GPR[29] .rarw. temp29 if (IntCtl.sub.ClrEXL
== 1) Status.sub.EXL .rarw. 0 Status.sub.KSU .rarw. 0 endif
Cause.sub.IC .rarw. 1 ClearHazards( ) PC .rarw. CalcIntrptAddress(
) endif endif else SignalException(CoprocessorUnusable, 0) endif
function LoadStackWord(vaddr) if vAddr.sub.1..0 .noteq. 0.sup.2
then SignalException(AddressError) endif (pAddr, CCA) .rarw.
AddressTranslation (vAddr, DATA, LOAD) memword .rarw. LoadMemory
(CCA, WORD, pAddr, vAddr, DATA) LoadStackWord .rarw. memword
endfunction LoadStack Word function CalcIntrptAddress( ) if
StatusBEV = 1 vectorBase .rarw. 0xBFC0.0200 else if
(ArchitectureRevision .gtoreq. 2) vectorBase .rarw.
EBase.sub.31..12 || 0.sup.11) else vectorBase .rarw. 0x8000.0000
endif endif if (Cause.sub.IV = 0) vectorOffset = 0x180 else if
(Status.sub.BEV = 1) or (IntCtl.sub.VS = 0) vectorOffset = 0x200
else if (Config3.sub.VEIC = 1 and EIC_Option=1) VectorNum =
CauseRIPL elseif (Config3.sub.VEIC = 1 and EIC_Option=2) VectorNum
= EIC_VectorNum elseif (Config3.sub.VEIC = 0 ) VectorNum =
VIntPriorityEncoder( ) endif if (Config3.sub.VEIC = 1 and
EIC_Option=3) vectorOffset = EIC_VectorOffset else vectorOffset =
0x200 + (VectorNum .times. (IntCtl.sub.VS || 0.sup.5)) endif endif
endif CalcIntrptAddress = vectorBase | vectorOffset endfunction
CalcIntrptAddress
IX. METHOD
[0132] 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
[0133] 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.
[0134] 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
[0135] 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.
[0136] 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.
[0137] 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.
[0138] 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.
* * * * *