This section gives helpful information to system programmers who understand MIPS assembly language.
The MIPS Assembly Language Interface is described in relation to the following:
System calls to the pSOS+/MIPS kernel are made by executing the system call (syscall) instruction. The pSOS+/MIPS kernel expects all system call arguments, as well as a function code indicating which system call is being made, to be located in the CPU registers before the syscall instruction is executed. Figure 4. ``System Call Argument Transfer" illustrates the argument transfer.
| $t0 | Function Code |
| $t1 | Number of Parameters |
| $a0 | Argument 1 |
| $a1 | Argument 2 |
| $a2 | Argument 3 |
| $a3 | Argument 4 |
| $t2 | Argument 5 |
| $t3 | Argument 6 |
| $t4 | Argument 7 |
| $t5 | Argument 8 |
The CPU register $t0 must contain a code indicating which system call is being made, and register $t1 must contain the number of arguments for the function code. Function codes are listed in "pSOSystem Function Codes" on page B-5. Normally, a special assembly language module (known as a bindings module) sets up the CPU and executes the syscall instruction.
As a result of the syscall instruction, the processor initiates system call exception processing, transferring control to the corresponding vector code. The vector code must allocate a small stack frame, save some registers, and transfer control to the pSOS+ kernel's system call entry point. This is described in detail below.
In contrast to the pSOS+/MIPS kernel, pSOSystem/MIPS components (e.g. pNA+) expect the system call arguments and function code to be located on the stack before the syscall instruction is executed. Figure 5. illustrates the component call stack frame.
The pSOS+ kernel is initialized by passing control to its initialization entry point, which is located at offset 0x40 from the start of the kernel code.
When a system call is made, control must be passed to the system call entry point, located at offset 0x48 from the start of the kernel code. Upon entry, the top of the stack must contain a pSOSystem stack frame. The next frame on the stack (pointed to by the back chain pointer) must be set up as described in "System Call Conventions" on page B-1.
As soon as possible, an interrupt service routine (ISR) should call the pSOS+ i_enter() routine. Normally this is done immediately after allocating a pSOSystem stack frame and saving a few registers in the frame.
Upon return from i_enter(), the ISR should do whatever is necessary to service the interrupt. When the interrupt has been serviced, the ISR must complete by calling the pSOS+ i_return() entry.
The pSOS+ i_enter() entry point is located at offset 0x60 from the beginning of the pSOS+ kernel code. It should be called via the MIPS jal instruction. The interface is as follows:
This service routine gives the pSOS+ kernel a chance to perform interrupt entry operations. It must be called at the beginning of an interrupt handler before the interrupt is re-enabled.
The address of i_enter() is kept in a structure called exc_rootptrs, which is set up by pSOSystem on system startup. Register $k0 may be used at all times to access this structure.
The pSOS+ i_return() entry point is located at offset 0x58 from the start of the pSOS+ kernel code. It provides and establishes a standard exit convention for all ISRs.
Almost without exception, i_return() must be used in place of the rfe instruction (ERET instruction for R4600-compatible processors) to exit an ISR. It is absolutely mandatory to exit an ISR with i_return() if i_enter() has been called on entry. Otherwise, the task's stack will not be restored to the value it had when the interrupt occurred. The actions performed by i_return() depend on the type of code executing when the serviced interrupt occurred.
Upon entry to i_return(), the stack pointer should point to the pSOSystem stack frame that was created by the ISR vector code and i_enter(). All of the saved processor's registers will be restored by this routine. A (j) instruction shall be used to transfer control to i_return().
The address of i_return() is kept in a structure called exc_rootptrs, which is set up by pSOSystem on system startup. Register $k0 may be used at all times to access this structure.
pSOSystem maintains a structure called exc_rootptrs, containing the addresses of routines that are essential for the MIPS exception processing. Also, a copy of pSOSystem's PIC and PID global pointers are kept within this structure. The layout of this structure is shown below.
WARNING: Register $k0 is used as a pointer to the exc_rootptrs structure throughout all of the pSOS+ code. It is initialized once by startup code, and must be treated as read-only by all other routines. VIOLATIONS OF THIS RULE WILL DEFINITELY CORRUPT THE SYSTEM!
struct exc_rootptrs {
void (*pSOSIEnter)(); /* Address of pSOS+ i_enter() entry */
void (*pSOSIReturn)(); /* Address of pSOS+ i_return() entry */
void (*pMontIEnter)(); /* Address of pMONT+ i_enter() entry */
void (*pMontIReturn)(); /* Address of pMONT+ i_return() entry */
ulong PICbase; /* PIC relocation register value */
ulong PIDbase; /* PID relocation register value */
};
Upon occurrence of any MIPS exception, either a hardware interrupt or an instruction- caused exception, a piece of special code called an exception dispatcher is executed. The dispatcher allocates a stack frame, saves some minimum number of registers, and then transfers control to the appropriate exception handler. The format of the stack frame it creates is shown in Figure 6. ``pSOSystem Standard Stack Frame", below.
The exception dispatch code saves $sp, $sr, $at, $a0, $a1, $s7, $gp, $ra, and also the contents of the CAUSE, EPC, and BADVADDR registers. The exception type, tlb-miss or general, is also saved here.
The following pages contain a list of pSOSystem function codes.
Copyright © 1996, Integrated Systems, Inc. All rights reserved.