| |
|
|
|
|
|
Interrupt Handling The Rational Exec kernel is responsible for low-level interrupt handling. It in turn provides support for the higher level and more portable interrupt handling constructs described in Writing Interrupt Handlers. Different processors provide different mechanisms for generating and handling interrupts, and targets may incorporate external interrupt handlers as well. For this reason, Rational Exec interrupt handling is highly configurable.
This chapter describes Rational Exec interrupt handling on each supported processor in general and describes configuration options that can be used to customize it to support targets incorporating those processors:
- Exception and Interrupt Processing on the PowerPC
- Exception, Interrupt, and Trap Processing on the MIPS
- Interrupt Support on the RH32
- Interrupt Processing on the M68000 Family
- Interrupt Processing on the i386 Family
Exception and Interrupt Processing on the PowerPCThe following sections first give an overview of the default steps of handling exceptions and external interrupts. Then the details are filled in by describing how the hardware exception vector table is set up, how the software-maintained Interrupt_Vector_Table works, and detailed descriptions of the different pieces of the routines involved in exception and interrupt processing.
- PowerPC Exceptions and Interrupts
- PowerPC Exception and Interrupt Processing
- PowerPC Interrupt_Vector_Table
- PowerPC Chaining ISR Routines
- PowerPC Completing the Interrupt Servicing
- PowerPC Context Record
- V_Exception_Name Handlers
- Sharing the Exception Vector Table with TDM
- Kernel Calls - V_Exception_Decode_System_Call
- V_Level1_Program: Program Exceptions:
- V_Level1_External: Processing External Interrupts
- V_Level1_Normal: Processing Execution Exceptions
- V_Complete_External: Reset External Interrupt Hardware
- Default_Trap
- The Kernel's Enter_From_User Handler
- Floating Point Exception Handling
- General Machine Code Precautions
PowerPC Exceptions and Interrupts
For an explanation of the PowerPC's exception processing refer to the PowerPC Microprocessor Family: The Programming Environment (Chapter 6, "Exceptions") and the supplement provided for each PowerPC processor.
The PowerPC classifies exceptions into types. For example, an interrupt from any external device is type 5. Each exception type has an address in the exception vector table. When an exception occurs, the processor determines the type and jumps to the assigned address. There must be instructions located at this vector address to handle the exception. So, unlike some processors, the PowerPC exception vector table is not a jump table.
The first three columns of Table 9 lay out the PowerPC exception vector table. The fourth column gives the name of the Rational-supplied kernel configuration routine, V_Exception_Name, that is placed at that vector address by default (V_Exception_Reset, V_Exception_Machine_Check, etc.).
Table 10 PowerPC 603/604 Specific Exception Vector
The value of the IP bit in the MSR register determines the exact location of the PowerPC vector. Let x_xxxx be the vector address from one of the above tables. If msr.IP is cleared, the vector address is 16#000x_xxxx#. If msr.IP is set, the vector address is 16#FFFx_xxxx#.
Layered on top of the PowerPC hardware exception processing, the Apex embedded development system supports an exception and interrupt model with a conventional jump table called the Interrupt_Vector_Table. It is in this table where TDM, the kernel, and applications put the address of interrupt service routines (see V_Interrupts.Attach_Isr).
PowerPC Exception and Interrupt Processing
Figure 15 illustrates the flow of an exception from the Level 0 handler in the processor's exception vector area to a Level 1 handler where decoding and mapping of the exception occurs. Following the figure is a step by step description of the flow of exceptions and interrupts.
Figure 15 PowerPC Exception Vectoring
- 1 . The PowerPC hardware classifies the exception and begins execution at the routine V_Exception_Name as described in the two tables in PowerPC Exceptions and Interrupts.
- 2 . Almost every V_Exception_Name routine pushes a context record onto the stack and fills in a minimum number of fields. The routines do some exception-specific machine state manipulation. The routines load an Interrupt_Vector_Table index into r0 and call one of the following more general routines (from v_krn_conf.2.ada).
- 3 . The next step depends on the level 1 handlers called. Enter_From_User is part of the VADS Exec kernel and begins executing a kernel service. The other three routines jump indirectly through the Interrupt_Vector_Table using the index that was passed in r0 or a computed index.
- 4 . The interrupt service routine (ISR) whose address is in the Interrupt_Vector_Table executes and then returns.
- 5 . The V_Level1_External and V_Level1_Normal routines optionally chain to the next exception or interrupt service routine until there are no more.
- 6 . V_Level1_External calls a Complete_External handler if one of the ISRs has filled in the Complete_External field of the context record.
- 7 . V_Level1_External calls V_Krn_Conf_I.Isr_Complete to let the kernel know that interrupt processing is finished. If the ISR caused a higher priority task to become ready to run, Isr_Complete switches to that task.
- 8 . V_Level1_External and V_Level1_Normal routines call V_Restore_EF (EF stands for Exception Frame, referring to the Context Record) to return to the interrupted code. V_Level1_Program returns to the instruction after the trap that caused the exception.
The following table describes the connection between each hardware interrupt vector and the level 1 handlers. The column labelled Interrupt Vector Table Index gives the name of the constant from v_cpu_conf.1.ada in the rts_interface.power.* view. This constant is passed in r0 as a parameter from the routine in the V_Exception_Name to the routine in the action column.
PowerPC Interrupt_Vector_Table
The Interrupt_Vector_Table is a software-maintained jump table. It is an array of interrupt service routine addresses. It is statically initialized in v_krn_conf.2.ada. The table is set up to parallel the PowerPC hardware exception vector. For example, PowerPC exception type 5, external interrupt, maps to slot 5 in the Interrupt_Vector_Table which is initialized with the address of V_Decode_External. The Interrupt_Vector_Table provides a familiar organization for all exception and external interrupt service routines. It also provides a framework for uniform application access using V_Interrupt utilities. The Interrupt_Vector_Table is declared as follows:
The value of Last_Trap is found in io_conf.1.ada from the view corresponding to your board.The value of Last_Trap is board-specific. If you are doing a configuration for a custom board, set this value to match the characteristics of your board. The value depends on how your configuration decodes external hardware interrupts. For example, the Rational-supplied configuration for the Motorola MVME1603 board, io_conf.1.ada is in the view board_common.power.rx_ppc.mvme1603.ada95.x.y.z.rel.
Entries in the Interrupt_Vector_Table can be changed dynamically by using the V_Interrupts package in the VADS Exec services (for example, V_Interrupts.Attach_Isr).
The following table gives the layout of the default Interrupt_Vector_Table:
External Interrupts In the Interrupt_Vector_Table
Many microprocessors have hardware support for external interrupts, for example, the Motorola MC680*0. External interrupts supply a 3 or 4 bit priority code which the microprocessor maps to a range of 8 or 16 slots in the interrupt vector table. The PowerPC only has one external interrupt, exception 5. Mapping external interrupts to different ISR entries is done by a combination of external hardware such as an interrupt controller and software such as V_Decode_External. Because this mapping depends on hardware external to the PowerPC microprocessor, it is board-specific. Therefore the external interrupt entries in the Interrupt Vector Table are also board-specific. It is useful to study the board configurations supplied with this product.
For the Motorola MVME1603 board, these are initially set as follows:
80..95 irq0_interrupt..irq15_interrupt Untouchable_Trap_Handler
The routine V_Decode_External for the MVME1603 board gets an interrupt number in the range 0..15 from the Intel 8259a priority interrupt controller. This is added to First_External_Interrupt (value: 80), which is declared in io_conf.1.ada (for example in the view board_common.power.rx_ppc.mvme1603.ada95.x.y.z.rel) and is defined as follows:
-- v_cpu_conf.1.ada (view rational.power.rx_ppc.ada95.x.y.z.rel) -- -- Last_Predefined_Trap is the last in a chain -- of constant definitions in v_cpu_conf.1.ada, see the -- source for more info -- Last_Predefined_Trap : constant := Last_Software_Trap; -- io_conf.1.ada -- (view board_common.power.rx_ppc.mvme1603.ada95.x.y.z.rel) -- First_External_Interrupt : constant := \ V_Cpu_Conf.Last_Predefined_Trap + 1;
First_External_Interrupt is set up to point to the base of the external hardware interrupt section of the Interrupt_Vector_Table.
The file i8259a.1.ada and its companion V_Decode_External provide a good example of how to map external logic into interrupt vector indices.
Most entries in the Interrupt_Vector_Table are initialized to point to Untouchable_Trap_Handler, a routine in v_krn_conf.2.ada that jumps to TDM by default. Some of the V_Level1_Name routines map a pointer to Untouchable_Trap_Handler into a more specific routine name. These routines are also in v_krn_conf.2.ada.
PowerPC Chaining ISR Routines
The routines V_Level1_External and V_Level1_Normal support ISR chaining. If one ISR wants to chain to another, the first ISR sets the Context.Next_Id field to the index of the next ISR in the Interrupt_Vector_Table. This chaining mechanism is used, for example, by V_Decode_External for the Motorola MVME1603. External hardware is examined to obtain an index which is then added to First_External_Interrupt. The result is saved in the Next_Id field and V_Decode_External returns. V_Level1_External loads Next_Id field into R3 and sees that it is non-zero, so it zeros out the Next_Id field and then loops back around to index into the Interrupt_Exception_Vector again.
V_Level1_External always zeros Next_Id at the beginning of interrupt processing, so if it is not changed, there is no chaining.
For more information about ISRs, see Classic Runtime System Interrupt Service Routines (ISR)s.
There are six 32-bit fields in the context record that can be used for communication between the V_Decode_External and the ISR routine. The fields are named board_conf_0, board_conf_1, ..., board_conf_5. Global variables should not be used for this communication as there is risk that nested interrupts will corrupt the values.
There is one additional advantage to the chaining algorithm: it can be used as a testbed for ISRs. A chained-to ISR is invoked in exactly the same situation as if it were the first ISR called. So the ISR can be execution tested a little in its actual environment simply by chaining to it. For external interrupts, the ISR for the decrement timer (exception 9) could be used to chain to other ISRs. Naturally, you would want to disable any external device manipulation prior to such testing.
PowerPC Completing the Interrupt Servicing
It is possible to identify a Complete_External procedure that is executed before leaving the kernel to program the external circuitry to allow additional interrupts. The ISR should set the Complete_External field of the context to the address of a routine to call once all ISR processing is complete. The procedure V_Complete_External is a template used to complete the interrupt processing, if required.
Fill it in with board-specific logic to deal with the interrupt hardware on your board. The conditions going into this routine are that PowerPC interrupts are enabled and msr.EE is 1. When the routine returns, msr.EE should be 0.
V_Level1_External always zeros the Complete_External field of the context at the beginning of interrupt processing, so if it is not changed, there is no call on a Complete_External routine.
There are six 32-bit fields in the context record that can be used for communication between V_Decode_External, the ISR and the V_Complete_External routine. The fields are named board_conf_0, board_conf_1, ..., board_conf_5. Global variables should not be used for such communication as there is risk that nested interrupts will corrupt the values.
PowerPC Context Record
As described in step 1 in the section PowerPC Exception and Interrupt Processing, the first step of almost every V_Exception_Name routine allocates a context record on the stack. The purpose of a context record is to save the state of the interrupted task (for example, registers values), to support nested interrupts, and to communicate data among ISR routines.
The context record is type Context_T defined in v_cpu_conf.1.ada (for example, in the view rational.power.rx_ppc.ada95.x.y.z.rel).
V_Exception_Name Handlers
As described in PowerPC Exception and Interrupt Processing, The V_Exception_Name instructions are the first executed when a hardware exception or external interrupt occurs. The source code for each of these routines, one per file, is in the kernel configuration view, for example krn_conf.power.rx_ppc.mvme1603.ada95.x.y.z.rel.
This section uses pseudo code to describe what these routines do. The MSR register is restored to its values before the exception except for the EE bit in an external exception which remains 0 so additional interrupts do not occur.
V_Exception_name: r1 := r1 - CONTEXT_SIZE; (r1) := old_r1; -- STM instruction r1:context.r0 := r0; -- save R0 to context r0 := srr0; -- srr0 has interrupted PC r1:context.pc := r0; -- save interrupted PC r0 := srr1; -- srr1 has interrupted msr r1:context.msr := r0; -- save interrupted msr #if name = program then EE := 0; -- disable external interrupts FE0, FE1 := 0; -- disable floating point exceptions SE, BE := 0; -- no single step or branch trace enable r0 := r0[17..19,24..31]; #elsif name = external then EE := 0; -- disable external interrupts SE, BE := 0; -- no single step or branch trace enable r0 := r0[17..20,23..31]; #else SE, BE := 0; -- no single step or branch trace enable r0 := r0[16..20,23..31]; #end if; msr := r0; r0 := I_EXCEPTION; ba, level1_handler (V_Level1_Normal, V_Level1_External, \ or v_level1_Program);Sharing the Exception Vector Table with TDM
The PowerPC processor's exception vector table is located at 0 or 16#fff0_0000#, depending on the setting of msr.IP. Either TDM or the kernel can have code in this table. A procedure is written for each entry in the hardware exception vector table (V_Exception_Name). The linker option file is used to place each of these procedures in a different image group. Image groups are used to keep data in ROM that is copied into RAM during execution. During TDM and kernel initialization the code is copied from the image groups to the exception vector table. TDM copies code into all of the processor's exceptions at initialization and each time the program is re-run. During initialization, the kernel can overwrite any of the exceptions it wishes to handle. Normally the kernel takes all of the entries in the processor's exception vector table and passes the decoded exceptions that are for TDM through entry 0.
Kernel Calls - V_Exception_Decode_System_Call
The System_Call hardware exception occurs when the System Call (sc) instruction is executed. Unlike most of the other V_Exception_Name exception handling routines, V_Exception_Decode_System_Call simply restores the msr.EE bit to the saved value and then jumps to V_Krn_Conf_I.Enter_From_User_Trap_Handler. There is no indirect jump through the Interrupt_Exception_Vector.
V_Exception_Decode_System_Call is located at 16#fff0_0c000# or 16#0000_0c00#.
Inside the kernel, a system call is invoked with an environment similar to a procedure. Specifically:
- The lr register contains the return address
- r0..r12 are volatile registers
- r3..r10 (actually r3..r4) are parameters
- A normal link area is available on the stack
This environment is set up prior to the execution of the sc instruction by the routine Trap_To_Krn found in the user configuration (v_usr_conf). V_Exception_Decode_System_Call leaves all of the registers untouched except r0 (used as a temporary). It then branches to Enter_From_User in the kernel.
V_Level1_Program: Program Exceptions:
Program exceptions occur due to trap instructions, floating point enabled exceptions, and illegal instructions. The routine V_Level1_Program does the following:
- Saves the register state used in V_Level1_Program
- Decodes the program exception and initializes r0 with the index into the interrupt vector table.
- Restores the register state
- Branches to V_Level1_Normal, V_Level1_Break, or V_Level1_External.
V_Level1_Program decodes the exceptions in the following way:
- Looks for a debugger breakpoint trap
- Looks for a stack overflow in a subprogram prologue
- Looks for a stack overflow in a subprogram body
- Looks for a twi instruction
V_Level1_Program further decodes twi instructions into 32 possible entries in the exception vector table. These are subdivided into four groups based on the following general criteria:
- 1 . Interrupt/No Interrupt
- 2 . Return to Next Instruction/Return to Same Instruction
If you wanted to place a trap in an application and get the effect of one of these combinations, look in the file v_cpu_conf.1.ada in the view rational.power.rx_ppc.ada95.x.y.z.rel. There are 32 twi instructions defined representing the 4 groups. They are Twi0_instruction .. Twi31_instruction. TDM, Code coverage (Testmate/CCA), taskdeb, and tracepoints each have a trap reserved for their usage.
No interrupt/Return To Next Instruction
These are assumed to be additional system call type operations so the entire register context is not saved/restored. Instead these are treated like subprogram calls into the kernel. These are used to save/restore the floating point state from a floating point ISR wrapper.
Interrupt/Return to Next Instruction
Simulate an interrupt. save/restore entire context.
No interrupt/Return To Same Instruction
Used for CCA type traps. Save/restore entire context.
Interrupt/Return To Same Instruction
Not currently used, simulate an interrupt, save/restore entire context.
V_Level1_External: Processing External Interrupts
Warning: Board Configuration required.
V_Level1_External implements the external interrupt model supported by VADS Exec. Here is the algorithm:
- 1 . Reserve space for context record
- 2 . Context.Complete_External := 0
- 3 . r3 := r0 (for example, r0 was set to 5 by V_Exception_External prior to calling V_Level1_External).
- 4 . If this is an outer interrupt (for example, not a nested interrupt), then switch to an interrupt stack.
- 5 . Chain_Loop: While r3 /= 0 loop
- a .
Context.Next_Id := 0- b .
r12 := Interrupt_Vector_Table(r3).- c .
If r12 = Untouchable_Trap_Handler then r12 := Untouchable_External- d .
jump through r12 (move r12 to ctr register; bctrl).- e .
r3 := Context.Next_Id- 6 . End Loop;
- 7 . If Context.Complete_External /= 0 then call that routine
- 8 . call V_Krn_Conf_I.Isr_Complete
- 9 . jump to V_Restore_EF
If V_Level1_External is called from V_Exception_External, r0 is be set to 5. So the first time through Chain_Loop, r3 is 5 and the loop calls Interupt_Vector_Table(5), which is initialized to V_Decode_External. There is a template for V_Decode_External in v_krn_conf.2.ada, for example in the view krn_conf.power.rx_ppc.board.ada95.x.y.z.rel. You can also look at a version that talks to real hardware in the view krn_conf.power.rx_ppc.mvme1603.ada95.x.y.z.rel.
V_Decode_External is board specific. It examines the external hardware (8259a interrupt controller in the case of the Motorola MVME1603 board) and calculate a new index into the Interrupt_Vector_Table. It puts this value into Context.Next_Id and return to V_Level1_External. The fact that Context.Next_Id is not zero causes the Chain_Loop to go around one more time, this time calling the ISR for the specific external device. V_Decode_Interrupt should also turn on the msr.EE bit so that other external interrupts can be delivered.
This Interrupt_Vector_Table scheme supported by V_Level1_External and V_Level1_Normal. allows application software to call standard utilities (for example, in V_Interrupt) to manipulate the Interrupt_Vector_Table. This allows simpler porting of applications to and from other microprocessor architectures, such as the Motorola 680x0, where the interrupt controller could be hooked right to the microprocessor to provide vectoring directly through a hardware-supported Interrupt_Vector_Table.
If further manipulation of the I/O devices is required at the end of interrupt servicing (for example, after Chain_Loop), this should be done by the Complete_External routine. The address of the Complete_External routine field of the Context record should be set by either V_Decode_External or the ISR itself. In the case of the Motorola MVME1603, V_Decode_External polls the 8259a and leaves it up to V_Complete_External to restore interrupt processing after the ISR has completed.
V_Level1_Normal: Processing Execution Exceptions
Execution exceptions occur when a program does something that cannot be supported by the processor. Examples are divide-by-0, accessing unaligned data, referencing non-existent memory, or any of the exceptions in Figure 15 with V_Level1_Normal as the action field. Upon entry to V_Level1_Normal, R0 contains the Interrupt_Vector_Table index shown in the Exception-Action Table. So the corresponding routine in the Interrupt_Vector_Table is be called by V_Level1_Normal.
V_Level1_Normal is identical to V_Level1_External except:
- 1 . V_Level1_Normal does not switch to an interrupt stack
- 2 . V_Level1_Normal maps Untouchable_Trap_Handler to Untouchable_Normal
- 3 . V_Level1_Normal does not call Complete_External
- 4 . V_Level1_Normal does not call V_Krn_Conf_I.Isr_Complete. V_Level1_Normal does have a Chain_Loop, just like V_Level1_External.
V_Decode_External: Decoding External Interrupts
The procedure V_Decode_External is used to interrogate the external interrupt hardware to figure out which ISR should be called. The hardware should yield a number in the range 0..N-1, where N is the number of interrupt priorities supported by external logic. The number is added to First_External_Interrupt (whose default value is defined in io_conf.1.ada) and the result stored in the Next_Id field of the context record. V_Decode_External then returns to V_Exception_External. There should be an Interrupt Service Routine installed in the Interrupt_Vector_Table for each value that can be returned by V_Decode_External. For more information see V_Exception_External and also the hardware interrupt section of the Interrupt_Vector_Table.
procedure V_Decode_External( trap_Id : vector_Id_t; context : a_context_t)
The Trap_Id is the Interrupt_Vector_Table index of the V_Exception_Name routine that fielded the hardware exception. For external interrupts this would be I_External. For the decrement exception this would be I_Decrement. This is most easily understood by looking at the exception-action table for the exceptions with V_Level1_External as an action.
The context is a pointer to the context record.
V_Complete_External: Reset External Interrupt Hardware
The procedure V_Complete_External is typically called to reset external hardware after interrupt processing is complete. Refer to the description of V_Level1_External for more information.
V_Complete_External is not called by default. It is up to the logic in either V_Decode_External or the ISR for the hardware to set the Complete_External field of the Context Record if calling V_Complete_External is required. The code in V_Complete_External is board specific.
procedure V_Complete_External( context : a_context_t)
The context is a pointer to the context record and can used to access the board_0, board_1, ..., board_5, set by V_Decode_External or the ISR.
Default_Trap
The Io_Conf.Default_Trap entry of the Interrupt_Vector_Table, for example, Interrupt_Vector_Table(Io_Conf.Default_Trap), is used whenever a trap can not be correctly decoded. If TDM is present the Interrupt_Vector_Table entry for Default_Trap should be initialized with Untouchable_Trap_Handler to allow TDM to field these traps.
The Kernel's Enter_From_User Handler
This handler is used to field tasking service requests to the kernel. It resides in krn_liba.var. It assumes an interface like a subprogram call, it does not save any registers that are not be saved during a subprogram call.
Floating Point Exception Handling
The PowerPC has an integrated floating point unit that executes concurrently with the other execution units.
General Machine Code Precautions
A hardware exception can occur at any time. The hardware exception processing code assumes that it can allocate a context save area on the stack when the exception occurs. Thus, sp must always point to a valid memory area and must always be double word (8 byte) aligned.
Certain machine code insertions which reference memory cause more than one instruction to be generated. For example, the machine code insertion:
This allocation of extra registers can cause problems in routines such as trap handlers which depend on knowing exactly which registers get modified.
Exception, Interrupt, and Trap Processing on the MIPS
- Definitions for Exceptions, Interrupts and Traps
- Interrupt Support
- Floating Point Trap Handlers
- Machine Exception Handling
- Machine Code Precautions: Stack Alignment
- Interrupt Vector Table (IVT)
- Apex Interrupt Handlers
Definitions for Exceptions, Interrupts and Traps
The MIPS architecture uses it own unique definitions for exceptions, interrupts and traps. The term "exception" is used by MIPS to encompass all events which cause the CPU to vector to the kernel for special processing. An exception can be a normal or abnormal event. The following is a list of exceptions:
Interrupts are a sub-class of exceptions. They are either external or internal. The external ones, Intr5..0, occur asynchronously by hardware assertion of the INT5..0 lines. The internal ones, Sw1 and Sw0, are synchronously caused by software setting the Sw1 or Sw0 bits in the CP0 cause register.
For the MIPS I Family, traps only occur in the FPC and cause an external interrupt (the board designer decides which interrupt to use).
For the MIPS II/III/IV/64 Family, traps are also a subclass of exceptions. They occur as a result of executing a trap instruction when its condition is met.
See also Interrupt Support.
On the MIPS II/III/IV/64, a floating point exception comes into the processor with its own exception ID unlike on the MIPS I where the exception comes in on an interrupt line and appears to be an interrupt.
In the MIPS architecture, FPC exceptions are recommended to be precise. All current implementations do it this way. Precise exceptions are those which the processor can determine the address of the faulting FPC operation and is able to re-execute the faulting instructions. Note that Apex Embedded MIPS Family assumes precise exceptions.
The layout of the CP0 Cause register is shown for your reference in Table 15. This figure is taken from the 1988 edition of Gary Kane's MIPS RISC Architecture. It includes a breakdown of the lower two bits of the IP field. We include it for your reference.
Table 15 The MIPS Cause Register
When the exception occurs, the CPU, disables all interrupts and transfers control to address 16#8000_0080# (MIPS I Family) or address 16#8000_0180# (MIPS II/III/IV/64 Family) (except for a TLB miss which uses 16#8000_0000#). At initialization time, V_Start_Program places instructions at these locations to jump to its exception handler procedure called V_Gen_Except in the package V_Krn_Conf. V_Gen_Except then reads the cause register from CP0. The contents of the ExcCode field and, in the case of an interrupt, the contents of the IP[5..0] and Sw fields are used by V_Decode_Exception and V_Decode_Interrupt to create the value of an index into the interrupt vector table.
The vector is then read from the table and control is transferred to it.
The following events have taken place upon entry to an exception handler:
- The processor enters kernel mode (no change since the user program runs in kernel mode anyway)
- Space on the stack is allocated for an exception frame and all relevant non-floating point registers (r1 .. r31, hi, lo, c0_badvaddr, c0_status, c0_cause, c0_epc) are saved in it.
- If an interrupt caused the exception, the kernel switches to using the interrupt stack (if it was not already), sets the Stack_Limit (s7) appropriately, and increments the interrupt depth.
- If an interrupt caused the exception, before transferring control to the routine pointed by the index, interrupts at all higher levels are enabled. For example, if Intr3 caused the exception, Intr4 and Intr5 are enabled. If the event was not caused by an interrupt, all interrupts are enabled.
- Register a0 contains the index into the Interrupt_Vector_Table or IVT, while a1 contains a pointer to the exception frame.
The following events take place upon exiting an interrupt handler:
- All the relevant, non-floating point registers (r1 .. r31, hi, lo, c0_badvaddr, c0_status, c0_cause, c0_epc) are restored.
- The exception frame that was allocated is discarded.
- If a break or SYSCALL instruction caused the exception, the return PC is advanced past that instruction.
- If the interrupt took place in a branch delay slot, the branch delay emulation code is executed, otherwise it simply resumes execution of the interrupted code.
Interrupt Support
The R3xxx has six external hardware interrupts and two internal software interrupts. One external interrupt is typically reserved for the FPC. All interrupts cause the R3xxx to jump to one exception vector defined by the architecture. It is called the general exception vector and is always located at address 16#8000_0080#.
During initialization, the kernel loads the general exception vector with several instructions that cause the processor to jump to the kernel's exception handler, V_Krn_Conv.V_Gen_Except.
V_Gen_Except needs to find out what event caused the exception. There are thirteen possible causes defined by the MIPS R3xxx chips. It uses the contents of the CP0 cause register to do this, and in the case of an interrupt to also find out which interrupt it was. It then maps the interrupt to an entry in the interrupt vector table (IVT).
On many boards, one interrupt can have several different sources. For example, a timer chip, UART, and a memory parity error signal may be connected to one R3xxx interrupt. The kernel's decode routine, V_Krn_Conf.V_Decode_Interrupt, makes a one-to-one association of external interrupts to entries in the IVT. However, Apex Embedded exposes this routine so that you can modify it to a one-to-many association as required. Alternatively, the entry called to handle the external interrupt can return the index of another IVT entry to be called. The interrupt vector table is exposed in V_Krn_Conf with extra user-configurable entries which can be used as necessary.
You can configure the IVT to be initialized with the address of your interrupt handlers, but these handlers need to be linked with the kernel. Alternatively, you can put the address of the interrupt handler into the IVT at runtime from the user program via the Attach_Isr routine in the VADS Exec V_Interrupts package, or by using the standard (but slower) Ada interrupt entries in normal tasks.
Though the MIPS architecture does not dictate the priority of interrupts, the kernel, via software, supplies a default interpretation. From highest to lowest priority, they are: INT5, INT4, INT3, INT2, INT1, INT0, SW1, SW0. Rational Software Corporation exposes this code in the V_Krn_Conf.V_Decode_Interrupt routine and you are free to change it if this interpretation is not suitable.
On MIPS II/III/IV/64, at reset time, INT5 can be programmed (via hardware) to either be connected to an external interrupt or the output of the internal timer compare. Apex Embedded provides an example timer configuration for the kernel using the chip's internal timer (some chip implementations may not have an internal timer).
Floating Point Trap Handlers
Setting the Cu1 bit in the CP0 Status Register enables the MIPS FPC. Tasks are started with the FPC disabled. When a task executes its first floating point instruction, a Coprocessor 1 unusable exception is generated. The handler for this exception enables the FPC (turns on the Cu1 bit), initializes the FPCSR using the kernel's Floating_Point_Control configuration parameter (by default, invalid operation, zero-divide and overflow exceptions are unmasked, and rounding precision is "to nearest"), leaves the FPC registers untouched, allocates memory for the task's FPC save area and marks the task as using the FPC so that a task switch saves the FPC state.
The MIPS I architecture defines a set of floating point operations (FPops) that an FPC implementation may provide. FPops which are not implemented are emulated by the kernel for compatibility. Boards without an FPC generate a coprocessor 1 unusable exception on every execution of a floating point instruction. The coprocessor 1 unusable exception handler is called for every instruction in this case. The emulator runs with interrupts enabled.
Machine Exception Handling
The architecture supports machine exceptions for events such as integer overflow, reserved instruction, coprocessor unusable, address error, etc.
By default, some of these are mapped into Ada exceptions.
The Ov exception is mapped to the Ada Constraint_Error.
Optionally, any or all of Mod, TLBL, TLBS, AdEL. and AdES can be mapped to an Ada Storage_Error by replacing their respective IVT entries with V_Krn_Conf_I.Address_Error_Handler'Address. By default, they cause a trap to TDM or the onboard monitor.
Several of the Bp exceptions are mapped to Ada exceptions as well. Bp exceptions are used for divide-by-zero and are mapped to Constraint_Error. Stack overflow is mapped to Storage_Error and range error is mapped to Constraint_Error.
The default action for an RI exception is to cause a trap to TDM or to the onboard monitor, whichever was active when the kernel was initialized.
By default, a CpU exception for either CP2 or CP3 causes a trap to TDM or to the onboard monitor. A CpU for CP0 never occurs since programs executing in kernel mode are always allowed access to CP0. A CpU for CP1 is used by the runtime for detecting if a particular task is using floating point and thus necessitates saving floating point context during a context switch.
MIPS II, III, IV, and 64 Only
The Tr exception is used for conditionally-raised, predefined Ada exceptions, such as Storage_Error on a stack overflow check.
Since Apex Embedded does not used mapped memory, VCEI and VCED exceptions should never occur. By default, they cause a trap to TDM or the onboard monitor.
The FPE exception is used for processing FPC exceptions. In some cases, this exception is mapped to an Ada Numeric_Error.
The WATCH exception is used by the Apex Embedded debugger to implement a "go until this address is touched" capability.
Machine Code Precautions: Stack Alignment
For the MIPS I Family, since an interrupt can occur at any time unless the interrupt mask is set to zero, the stack pointer must always be word (4 byte) aligned. If you want your code to be compatible with the MIPS II/III/IV/64, the stack pointer must always be doubleword (8 byte) aligned.
For the MIPS II/III/IV/64 Family, since an interrupt can occur at any time unless the interrupt mask is set to zero, the stack pointer must always be doubleword (8 byte) aligned.
Interrupt Vector Table (IVT)
The kernel and TDM programs contain an array of exception handler addresses called the Interrupt Vector Table to avoid confusion with Ada exceptions. Handlers in the table are dispatched via the generalized handler V_Gen_Except.
We call a routine installed in the IVT, an Interrupt Service Routine (ISR), even though they are used to handle MIPS exceptions and FPC traps as well.
All the ISR addresses are placed in a single table to make configuration of the kernel simple. The ordering of the table is ad hoc - according to the constants in the Krn_Cpu_Defs package in rational.ss subsystem.
ISRs installed in the IVT have the following subprogram interface:
procedure handler( id: krn_cpu_defs.vector_id_t; ef: krn_cpu_defs.a_ef_t);
ID contains the index into the Interrupt_Vector_Table used and EF points to the exception frame where all the registers are stored.
Note: The register values in the exception frame should be modified with caution since they are used to restore context upon re-entering the user program.
The exception frame also contains the field, Next_Id. The ISR can update it with the vector ID of the next ISR to be dispatched to. It has been initialized to No_Vector_Id. If the Next_Id points to an Untouchable vector, then the Next_Id is handled in TDM. Using the Next_Id field allows multiple devices in either the user, kernel or TDM programs to share the same interrupt.
Apex Interrupt Handlers
Apex supplies the following interrupt handlers resident in TDM and kernel programs:
- TDM's Interrupt_Handler Generic (used for Control-C get interrupt)
- TDM's Catchall Tdm_Handler (all remaining exceptions and interrupts)
- Kernel's Fp_Save_Init_Handler (index = 49)
- Kernel's Fp_Restore_Handler (index = 50)
- Kernel's Enter_From_User handler
(index = 8)- Kernel's Ntaken_Instr_Handler (used for branch delay slot emulation, index = 35)
- Kernel's Taken_Inst_Handler (used for branch delay slot emulation, index = 36)
- Kernel's Overflow_Handler (index = 12, 38)
- Kernel's Div_By_Zero_Handler (index = 39)
- Kernel's Range_Handler (index = 40)
- Kernel's Stack_Overflow_Handler (index = 41
- Kernel's Bus_Error_Handler (index = 4.5)
- Kernel's Address_Error_Handler (index = 6,7)
- Kernel's Fp_Unusable_Handler (index = 65)
- Kernel's Fp_Exception_Handler
TDM's Interrupt_Handler Generic
The Interrupt_Handler generic is provided for compatibility with other processors. Since V_Gen_Except saves all registers (except floating point) upon entry to the handler, no further processing must be done.
This generic is declared in v_tdm_conf_i.1.ada as follows:
generic with procedure Process_Interrupt (id: krn_cpu_defs.vector_id_t; ef: krn_cpu_defs.a_ef_t); procedure Interrupt_Handler;
This generic surrounds the device specific Process_Interrupt subprogram. The body of this dummy generic is included in v_tdm_conf_i.1.ada. Refer there for further details.
Process_Interrupt is called and returns as a normal Ada procedure. It has the following interface:
procedure Process_Interrupt( id: krn_cpu_defs.vector_id_t; ef: krn_cpu_defs.a_ef_t);
Where ID contains the index into the Interrupt_Vector_Table used and EF points to the exception frame where all the registers are stored.
Note: Do not modify the registers in the exception frame.
TDM's Catchall Tdm_Handler
Tdm_Handler is TDM's handler for all the remaining exception types. It resides in tdm_liba.var with v_tdm_conf_i.1.ada that contains an interface to it.
This handler expects to receive either the debugger's breakpoint break exception or TDM services (cross_io, simple_io, halt) break exception. All other exceptions are not expected and are reported as such back to the host debugger. The debugger's breakpoints use break code 0 and 5 (IVT indexes 32, 37). TDM service's break code is specified by TDM's configuration parameter, Tdm_Break_Code. Break code 16 (IVT index 48) is the default.
Kernel's Fp_Save_Init_Handler
This handler saves the current floating point context and initializes the FPC (or emulator state if there is no floating point hardware). It is invoked by the VADS Exec Float_Wrapper generic.
Kernel's Fp_Restore_Handler
This handler restores the current floating point context. It is invoked by the VADS Exec Float_Wrapper generic.
Kernel's Enter_From_User handler
Enter_From_User handles all the kernel tasking service requests. It is called when a SYSCALL exception is fielded. Because this is a time critical code path, it is optimized so that very little processing is done before Enter_From_User is called:
Upon entering the kernel from the user program, checking for the SYSCALL exception is the first thing that is done.
Since the SYSCALL instruction occurs synchronously and because the compiler's code generator treats it as a procedure call, it is not necessary to save and restore context upon entry and exit.
To further increase speed, the SYSCALL exception is not decoded in the same way as other exceptions. Indeed, the IVT is not used to locate the entry point for the SYSCALL exception (its presence in the kernel's IVT is for documentation purposes only).
Kernel's Ntaken_Instr_Handler
This routine emulates an instruction in a branch delay slot when it is determined the branch is not going to be taken.
Kernel's Taken_Inst_Handler
This routine emulates an instruction in a branch delay slot when it is determined the branch is going to be taken.
Kernel's Overflow_Handler
This routine translates a machine arithmetic overflow exception to an Ada Numeric_Error exception. Also, multiply instructions (MULT, MULTU) resulting in overflow are vectored by software via a break instruction (break code 6).
It modifies the contents of registers on the stack to force the interrupt handler to return to the Ada exception unwinding logic in the user program with a Numeric_Error exception.
Kernel's Div_By_Zero_Handler
This routine is vectored to via a break instruction (break code 7) after software detects an attempt to divide by zero (non-floating point only).
It modifies the contents of registers on the stack to force the interrupt handler to return to the Ada exception unwinding logic in the user program with a Numeric_Error exception.
Kernel's Range_Handler
This routine is vectored to via a break instruction (break code 8) after software detects a constraint or range error.
It modifies the contents of registers on the stack to force the interrupt handler to return to the Ada exception unwinding logic in the user program with a Constraint_Error exception.
Kernel's Stack_Overflow_Handler
This routine is vectored to via a break instruction (break code 9) after software detects an attempt to overflow the user's main or task stack.
It modifies the contents of registers on the stack to force the interrupt handler to return to the Ada exception unwinding logic in the user program with a Storage_Error exception.
Kernel's Bus_Error_Handler
This routine is used as a handler for an IBE or DBE machine exception (indexes 6 and 7). It causes a Storage_Error to be raised in the user's program.
Kernel's Address_Error_Handler
This routine is used as a handler for an AdEL or AdES machine exception (indexes 4 and 5). It causes a Storage_Error to be raised in the user's program.
Kernel's Fp_Unusable_Handler
This routine is vectored to when the processor attempts to execute a coprocessor 1 (FPC) instruction, and the CU1 bit in the CP0 status register is set to false. This handler is used for detecting that a task is using the FPC. Until it detects this condition, it is not necessary to save and restore floating point registers for that task.
Kernel's Fp_Exception_Handler
This routine is vectored to when the FPC encounters a trap. The exception is first signalled through an interrupt line. In the MIPS architecture, the signalling of an FPC exception does not necessarily mean that the operation is invalid, just that the FPC is incapable of handling it correctly.
For an IEEE exception, it modifies the contents of registers on the stack to force the interrupt handler to return to the Ada exception unwinding logic in the user program with a Numeric_Error exception.
Interrupt Support on the RH32The RH32 has eight external hardware interrupts. All interrupts cause the RH32 to jump to a single location, 16#0000_0040#. Traps and hardware exceptions are directed by the hardware to addresses different than the interrupt vector.
This section contains the following:
- Overview
- Floating Point Trap Handlers
- Machine Exception Handling
- Machine Code Precautions: Stack Alignment
- Arithmetic Overflow Exception
Overview
During initialization, the kernel loads the various exception and interrupt vector locations with several instructions that cause the processor to jump to the kernel's exception handlers. These vector locations and the handler names are shown in Table 17.
Although the RH32 hardware dispatches the exceptions listed above by branching to separate, specific locations, the kernel handlers for these events call a common routine, V_Krn_Conf.V_Gen_Exception to process the exception. To make this approach work, the kernel's exception handlers translate each hardware exception (or interrupt) into a software defined exception number; this number is used as an index into a table configured into the kernel, called the Interrupt Vector Table.
The Interrupt Vector Table (IVT) defines more than just the addresses of interrupt handlers; it defines the addresses of handlers for all exceptions and interrupts that are fielded by the kernel. Important IVT indexes (knows as Interrupt Vector Table Id's) are defined in the Krn_Cpu_Defs package.
V_Gen_Exception needs to find out what event caused the exception. There are roughly fifty possible causes defined by the RH32 chip. It uses the contents of the CPU detail register to do this, and in the case of an interrupt to also find out which interrupt it was. It then maps the interrupt to an entry in the interrupt vector table (IVT).
You can configure the IVT to be initialized with the address of your interrupt handlers; these handlers need to be linked with the kernel. Alternatively, you can put the address of the interrupt handler into the IVT at runtime from the user program via the Attach_Isr routine in the VADS Exec V_Interrupts package, or by using the standard (but slower) Ada interrupt entries in normal tasks.
Floating Point Trap Handlers
Although the Floating Point Processor is a separate processor from the CPU, it is an integral part of the RH32 processor architecture. For example, all integer multiply and divide operations are performed in the Floating Point processor. Thus, the FPP state must be saved and restored by the kernel, when switching between tasks.
The FPP can raise a number of different conditions such as divide by zero, overflow, underflow, "tiny" (unormalized) result, and others. The kernel handles the divide by zero, overflow and underflow traps, and raises Ads's Constraint_Error exception at the point those traps occur. The other floating point traps are currently not handled by the kernel.
Machine Exception Handling
The architecture supports machine exceptions for events such as integer overflow, reserved instruction, coprocessor unusable, address error, etc.
Machine Code Precautions: Stack Alignment
For the RH32 CPU, since an interrupt can occur at any time unless the interrupt mask is set to zero, the stack pointer must always be double word (8 byte) aligned.
Arithmetic Overflow Exception
By default, some of these are mapped into Ada exceptions. Specifically, the "fixed overflow" exception is mapped to the Ada Constraint_Error.
Several of the "breakpoint" (RH32 trap instruction with particular encoding) exceptions are mapped to Ada exceptions as well. Breakpoint exceptions are used for divide-by-zero mapped to Constraint_Error, stack overflow mapped to Storage_Error, and range error mapped to Constraint_Error.
The default action for an "illegal instruction" exception is to cause a trap to TDM or to the onboard monitor, whichever was active when the kernel was initialized.
Interrupt Processing on the M68000 FamilyMotorola and Rational Software Corporation use slightly different terminology to refer to events that cause hardware exception processing to be initiated. Both Rational Apex Documentation and Motorola`s documentation for the M68000 family use the term exception to refer in general to these events and the term interrupt to refer specifically to external events. In addition, an internal event that causes exception processing (address error, zero divide, ASSERT instruction) is called an internal exception by Rational Software Corporation.
For historical consistency, we call the routine that is written to handle an exception an Interrupt Service Routine (ISR) or an interrupt handler, regardless of whether it is for an interrupt or an internal exception.
Each of the processors in the M68000 family handles interrupts in a similar manner. This section outlines the events that occur from the point of the interrupt to just prior to the first instruction of the ISR being executed. Refer to the user's manual for your processor for a more detailed discussion.
An interrupt occurs when an event requires attention from the processor. External hardware communicates with the microprocessor by supplying an interrupt priority level (1..7) and then an interrupt vector number.
The processor uses the interrupt priority to determine if it is going to process or ignore the interrupt. Level 7 interrupts are always processed. Levels 1..6 are processed if the interrupt priority maskin the SR register is less than the incoming priority level. For example, if the interrupt priority is 3 and the mask is 0, the interrupt occurs. However, if the priority is 3 and the mask is 4, the interrupt is ignored.
After determining that the interrupt is going to be processed, the processor makes an internal copy of the SR register and then changes the processor state bits of the SR register. In particular, the S bit is set, putting the processor into supervisor state and the interrupt priority mask is updated with the incoming priority.
The processor determines the interrupt vector number. This number is provided by the external hardware that caused the interrupt or the hardware can request that the number be automatically generated by the processor, in which case the vector number is set to 24 + the interrupt priority level.
Next, the current processor context is saved; the PC register and the internal copy of the SR register are pushed onto the active supervisor stack.
Finally, the interrupt vector number is used as an index into the Exception Vector Table (EVT) to load the starting address of the ISR into the program counter. Execution then resumes with the first instruction of the ISR.
Interrupt Processing on the i386 FamilyThe Intel 80386 Programmer's Reference Manual provides a complete discussion of exceptions and interrupts.
External events that cause interrupt processing to occur are called interrupts in the Intel manual. Processor-detected events (such as divide errors, page faults or coprocessor errors) and programmed events (such as an Int n instruction) are called exceptions.
For historical consistency, we call the routine that is written to handle either an exception or an external interrupt an Interrupt Service Routine (ISR) or an interrupt handler.
This section describes the hardware events that occur from the point of an interrupt to just prior to the first instruction of the ISR being executed.
An interrupt occurs when an event requires attention from the i386. External hardware communicates with the microprocessor by supplying an interrupt vector number.
The i386 uses the Interrupt Flag (IF) in the EFLAGS register to determine if it is going to process or ignore the interrupt. If IF is set, the interrupt is processed. If IF is clear, the interrupt is ignored.
Details of the EFLAGS register are in EFLAGS.
After determining that the interrupt is going to be processed, the i386 pushes the interrupt frame, which consists of OLD EIP, OLD CS and OLD EFLAGS, onto the kernel's (privilege level 0) stack. For a privilege transition, the kernel stack pointer (SS:ESP) is set to SS0:ESP0, found in the Task State Segment before the interrupt frame is pushed. SS0 is set to Kernel_Stack_Selector and ESP0 is set to the top of the kernel/ISR stack during kernel startup. For a privilege transition, the OLD SS and OLD ESP are also pushed as part of the interrupt frame. (The kernel and ISRs execute at privilege level 0. The user program executes at privilege level 3. A privilege transition occurs when the user program is interrupted.)
The interrupt vector number is used as an index into the Interrupt Descriptor Table (IDT), which is an array of i386 interrupt gate descriptors.
Details of the IDT are in IDT.
This array is pointed to by the BASE component of the IDTR register. The i386 uses the interrupt vector number as an index into the IDT; the interrupt vector number is multiplied by 8 and added to the IDTR's base. The ISR's initial EIP register is loaded with the offset component; the CS register is loaded with the selector component from the interrupt gate. The selector component for each interrupt gate descriptor is set to the Kernel_Code_Selector. Because the IDT is an array of interrupt gate descriptors, IF is clear (interrupts disabled) when execution begins at the first instruction of the ISR.
| Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
| |
|
|
|
|
|
 |
 |