E.4   Architecture Considerations

This section describes the following characteristics of the MIPS architecture that you should keep in mind as you write a VxWorks application:

Gprel Addressing

The VxWorks kernel uses gprel (gp-relative) addressing. However, the VxWorks module loader cannot dynamically load tasks that use gprel addressing.

To keep the loader from returning an error, compile application tasks with the -G 0 option. This option tells the compiler not to use the global pointer.

Reserved Registers

Registers k0 and k1 are reserved for VxWorks kernel use, following standard MIPS usage. The gp register is also reserved for the VxWorks kernel, because only the kernel uses gprel addressing, as discussed in above. Avoid using these registers in your applications.

Floating-Point Support

R4650

For the R4650, single precision hardware floating-point support is included by INCLUDE_HW_FP (which is included by default in the project facility VxWorks view). Double precision floating-point support is provided by software emulation when you use -msoft-float. (Note that INCLUDE_SW_FP is not required with -msoft-float for the R4650.)

R3000 and R4000

If your MIPS board includes a floating-point coprocessor (CP1), we recommend you use it for best performance.

However, if this chip is not available, you can use the GNU compiler -msoft-float option. This option keeps all floating-point values in integer registers (a pair of them for double-precision) and emulates all floating-point arithmetic.

To use this software emulation support, select INCLUDE_SW_FP in the project facility VxWorks view and unselect INCLUDE_HW_FP. Then, in the BSP directory, build VxWorks with the following command:

% make [CPU=cpuType] TOOL=sfgnu

Interrupts

MIPS Interrupts

The MIPS architecture has inputs for six external hardware interrupts and two software interrupts. In cases where the number of hardware interrupts is insufficient, board manufacturers can multiplex several interrupts on one or more interrupt lines.

The MIPS CPU treats exceptions and interrupts in the same way: it branches to a common vector and provides status and cause registers that let system software determine the CPU state. The MIPS CPU does not switch to an interrupt stack or exception stack, nor does it generate an IACK cycle. These functions must be implemented in software or board-level hardware (for example, the VMEbus IACK cycle is a board-level hardware function). VxWorks for MIPS has implemented a single interrupt stack, and uses task stacks for exception conditions.

Because the MIPS CPU does not provide an IACK cycle, your interrupt handler must acknowledge (or clear) the interrupt condition. If the interrupt handler does not acknowledge the interrupt, VxWorks hangs while trying to process the interrupt condition.

VxWorks for MIPS uses a 256-entry table of vectors.  You can attach exception or interrupt handlers to any given vector with the routines intConnect( ) and intVecSet( ). The files installDir/target/h/arch/mips/ivMips.h and bspname.h list the vectors used by VxWorks.

Interrupt Support Routines

Because the MIPS architecture does not use interrupt levels, the intLevelSet( ) routine is not implemented. The six external interrupts and two software interrupts can be masked or enabled by manipulating eight bits in the status register with intDisable( ) and intEnable( ). Be careful to pass correct arguments to these routines, because the MIPS status register controls much more than just interrupt generation.

For interrupt control, the routines intLock( ) and intUnlock( ) are recommended. All interrupts are blocked when calling intLock( ). The routine intVecBaseSet( ) has no meaning on the MIPS; calling it has no effect.

To change the default status register with which all tasks are spawned, use the routine taskSRInit( ). If used, call this routine before kernelInit( ) in sysHwInit( ). taskSRInit( ) is provided in case your BSP must mask interrupts from all tasks. For example, the FPA interrupt must be disabled for all tasks.

VMEbus Interrupt Handling

The processing of VMEbus interrupts is the only case where it is not necessary for an interrupt handler to acknowledge the interrupt condition. If you define the option VME_VECTORED as TRUE in config.h (and rebuild VxWorks), all VMEbus interrupts are acknowledged by the low-level exception/interrupt handling code. The VxWorks interrupt vector number corresponds to the VMEbus interrupt vector returned by the VMEbus IACK cycle. With this interrupt handling scheme, VxWorks for MIPS allows multiple VMEbus boards to share the same VMEbus interrupt level without requiring further decoding by a user-attached interrupt handler.

You can still bind to VMEbus interrupts without vectored interrupts enabled, as long as the VMEbus interrupt condition is acknowledged with sysBusIntAck( ) (as defined in sysLib.c). In this case, there is no longer a direct correlation with the vector number returned during the VMEbus IACK cycle. The vector number used to attach the interrupt handler corresponds to one of the seven VMEbus interrupt levels as defined in bspname.h. The mapping of the seven VMEbus interrupts to a single MIPS interrupt is board-dependent.

Vectored interrupts do not change the handling of any interrupt condition except VMEbus interrupts. All the necessary interrupt-acknowledge routines are provided in either sysLib.c or sysALib.s.


*

CAUTION: Not all boards support VME-vectored interrupts. For more information, see the BSP reference entries.

Virtual Memory Mapping

VxWorks for MIPS operates exclusively in kernel mode and makes use of the kseg0 and kseg1 address spaces. A physical addressing range of 512 MB is available. Use of the on-chip translation lookaside buffer (TLB) is not supported.

  • kseg0 .  
    When the most significant three bits of the virtual address are 100, the 229-byte (512 MB) kernel physical space labeled kseg0 is the virtual address space selected. References to kseg0 are not mapped through the TLB; the physical address selected is defined by subtracting 0x8000 0000 from the virtual address. Caches are always enabled for accesses to these addresses.

  • kseg1..  
    When the most significant three bits of the virtual address are 101, the 229-byte (512 MB) kernel physical space labeled kseg1 is the virtual address space selected. References to kseg1 are not mapped through the TLB; the physical address selected is defined by subtracting 0xa000 0000 from the virtual address. Caches are always disabled for accesses to these addresses; physical memory or memory-mapped I/O device registers are accessed directly.

  • 64-bit Support (R4000 Targets Only)

    With VxWorks for MIPS, real-time applications have access to the MIPS R4000 64-bit registers. This lets applications perform 64-bit math for enhanced performance.

    To specify 64-bit integers in C, declare them as long long. Pointers, integers, and longs are 32-bit quantities in this release of VxWorks.

    Memory Layout

    The memory layout of the MIPS is shown in Figure E-1. The figure contains the following labels:


    Exception Vectors

    Table of exception/interrupt vectors.

    SM Anchor

    Anchor for the shared memory network (if there is shared memory on the board).

    Boot Line

    ASCII string of boot parameters.

    Exception Message

    ASCII string of the fatal exception message.

    Initial Stack

    Initial stack for usrInit( ), until usrRoot( ) gets allocated stack.

    System Image

    Entry point for VxWorks.

    Host Memory Pool

    Memory allocated by host tools. The size depends on the system image and is defined in the macro WDB_POOL_SIZE. Modify WDB_POOL_SIZE under INCLUDE_WDB.

    Interrupt Stack

    Size is defined by ISR_STACK_SIZE under INCLUDE_KERNEL. Location depends on system image size.

    System Memory Pool

    Size depends on size of system image and interrupt stack. The end of the free memory pool for this board is returned by sysMemTop( ).


    All addresses shown in Figure E-1 depend on the start of memory for a particular target board. The start of memory is defined as LOCAL_MEM_LOCAL_ADRS under INCLUDE_MEMORY_CONFIG for each target.