Sparc v7 manual

This model is compatible with the regular register window model. This is the normal operating mode. Generate output containing library calls for floating point.

You must make your own arrangements to provide suitable library functions for cross-compilation. In particular, you need to compile libgcc. Generate output containing library calls for quad-word long double floating-point instructions. As of this writing, there are no SPARC implementations that have hardware support for the quad-word floating-point instructions.

They all invoke a trap handler for one of these instructions, and then the trap handler emulates the effect of the instruction. Because of the trap handler overhead, this is much slower than calling the ABI library routines.

Thus the -msoft-quad-float option is the default. With -munaligned-doubles , GCC assumes that doubles have 8-byte alignment only if they are contained in another type, or if they have an absolute address. Otherwise, it assumes they have 4-byte alignment.

Specifying this option avoids some rare compatibility problems with code generated by other compilers. It is not the default because it results in a performance loss, especially for floating-point code.

Do not generate code that can only run in supervisor mode. This is relevant only for the casa instruction emitted for the LEON3 processor. With -mfaster-structs , the compiler assumes that structures should have 8-byte alignment. This enables the use of pairs of ldd and std instructions for copies in structure assignment, in place of twice as many ld and st pairs. With -mstd-struct-return , the compiler generates checking code in functions returning structures or unions to detect size mismatches between the two sides of function calls, as per the bit ABI.

Enable Local Register Allocation. Default instruction scheduling parameters are used for values that select an architecture and not an implementation. This adds bit integer and floating-point move instructions, 3 additional floating-point condition code registers and conditional move instructions. The difference from the V8 ABI is that the global and out registers are considered 64 bits wide. The default is -mno-vis. With -mvis2 , GCC generates code that takes advantage of version 2. Setting -mvis2 also sets -mvis.

This CPU has a number of on-board peripherals and was developed by the European Space Agency to target space applications.

RTEMS currently provides support for the following peripherals:. Because the Timer Control Register is write only, we must mirror it in software and insure that writes to one timer do not alter the current settings and status of the other timer. Routines are provided in erc Low power mode is entered during idle loops and is enabled at initialization time.

Each high-level language compiler generates subroutine entry and exit code based upon a set of rules known as the application binary interface ABI calling convention. These rules address the following issues:. An ABI calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level.

It determines also the set of registers to be saved or restored during a context switch and interrupt processing. The SPARC architecture defines thirty-two non-floating point registers directly visible to the programmer. These are divided into four sets:. First, the registers are referred to as r0 through r31 or with the alternate notation r[0] through r[31]. Second, each register is a member of one of the four sets listed above. Finally, some registers have an architecturally defined role in the programming model which provides an alternate name.

The following table describes the mapping between the 32 registers and the register sets:. As mentioned above, some of the registers serve defined roles in the programming model. The following table describes the role of each of these registers:. The registers g2 through g4 are reserved for applications. GCC uses them as volatile registers by default. The register g6 is reserved for the operating system and contains the address of the per-CPU control block of the current processor.

This register is initialized during system start and then remains unchanged. These registers may be viewed as follows:. The floating point status register FSR specifies the behavior of the floating point unit for rounding, contains its condition codes, version specification, and trap information.

Thus the floating point context of a thread is the empty set. The rounding direction is a system global state and must not be modified by threads. A queue of the floating point instructions which have started execution but not yet completed is maintained.

This queue is needed to support the multiple cycle nature of floating point operations and to aid floating point exception trap handlers. Once a floating point exception has been encountered, the queue is frozen until it is emptied by the trap handler.

The floating point queue is loaded by launching instructions. It is emptied normally when the floating point completes all outstanding instructions and by floating point exception handlers with the store double floating point queue stdfq instruction.

The psr contains the condition codes, processor interrupt level, trap enable bit, supervisor mode and previous supervisor mode bits, version information, floating point unit and coprocessor enable bits, and the current window pointer cwp. The cwp field of the psr and wim register are used to manage the register windows in the SPARC architecture.

The register windows are discussed in more detail below. In reality, they are much more complicated. The save instruction is used to obtain a new register window. This instruction decrements the current window pointer, thus providing a new set of registers for use. This register set includes eight fresh local registers for use exclusively by this subroutine. When done with a register set, the restore instruction increments the current window pointer and the previous register set is once again available.

The two primary issues complicating the use of register windows are that 1 the set of register windows is finite, and 2 some registers are shared between adjacent registers windows. This is easily accomplished in a high level language because each subroutine typically performs a save instruction upon entry.

Thus having a subroutine call depth greater than the number of register windows will result in a window overflow condition. The window overflow condition generates a trap which must be handled in software. The window overflow trap handler is responsible for saving the contents of the oldest register window on the program stack. If the restore results in the need for a register window which has previously been written to memory as part of an overflow, then a window underflow condition results.

Just like the window overflow, the window underflow condition must be handled in software by a trap handler. The window underflow trap handler is responsible for reloading the contents of the register window requested by the restore instruction from the program stack.

The Window Invalid Mask wim and the Current Window Pointer cwp field in the psr are used in conjunction to manage the finite set of register windows and detect the window overflow and underflow conditions. The cwp contains the index of the register window currently in use. The save instruction decrements the cwp modulo the number of register windows.

Similarly, the restore instruction increments the cwp modulo the number of register windows. Each bit in the wim represents represents whether a register window contains valid information. The value of 0 indicates the register window is valid and 1 indicates it is invalid. When a save instruction causes the cwp to point to a register window which is marked as invalid, a window overflow condition results.

Conversely, the restore instruction may result in a window underflow condition. Other than the assumption that a register window is always available for trap i. This makes the maximum possible number of register windows available to the user while still meeting the requirement that window overflow and underflow conditions can be detected.

The window overflow and window underflow trap handlers are a critical part of the run-time environment for a SPARC application. The SPARC architectural specification allows for the number of register windows to be any power of two less than or equal to This results in the cwp ranging in value from 0 to 7 on most implementations. The second complicating factor is the sharing of registers between adjacent register windows. While each register window has its own set of local registers, the input and output registers are shared between adjacent windows.

The output registers for register window N are the same as the input registers for register window N - 1 modulo RW where RW is the number of register windows. An alternative way to think of this is to remember how parameters are passed to a subroutine on the SPARC.

The caller loads values into what are its output registers. Then after the callee executes a save instruction, those parameters are available in its input registers.

This is a very efficient way to pass parameters as no data is actually moved by the save or restore instructions. A subroutine is invoked via the call call instruction. After the callee executes a save instruction, this value is available in input register 7 i7 until the corresponding restore instruction is executed. The callee returns to the caller via a jmp to the return address. There is a delay slot following this instruction which is commonly used to execute a restore instruction - if a register window was allocated by this subroutine.

It is important to note that the SPARC subroutine call and return mechanism does not automatically save and restore any registers. This is accomplished via the save and restore instructions which manage the set of registers windows. In case a floating-point unit is supported, then floating-point return values appear in the floating-point registers.

Otherwise, these are scratch registers. Due to this the hardware and software floating-point ABIs are incompatible. As discussed above, the call instruction does not automatically save any registers. The save and restore instructions are used to allocate and deallocate register windows. When a register window is allocated, the new set of local registers are available for the exclusive use of the subroutine which allocated this register set.

Until the callee executes a save instruction, the parameters are still visible in the output registers. After the callee executes a save instruction, the parameters are visible in the corresponding input registers.

The following pseudo-code illustrates the typical sequence used to call a RTEMS directive with three 3 arguments:. A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems.

RTEMS does not support segmentation or virtual memory of any kind. The appropriate memory model for RTEMS provided by the targeted processor and related characteristics of that model are described in this chapter.

Each address is represented by a bit value and is byte addressable. The address may be used to reference a single byte, half-word 2-bytes , word 4 bytes , or doubleword 8 bytes. The following table lists the alignment requirements for a variety of data accesses:.

Doubleword load and store operations must use a pair of registers as their source or destination. This pair of registers must be an adjacent pair of registers with the first of the pair being even numbered.

For example, a valid destination for a doubleword load might be input registers 0 and 1 i0 and i1. The pair i1 and i2 would be invalid. In this case, the assembler assumes that what the programmer meant was to use the even-odd pair which ends at the specified register. This may or may not have been a correct assumption. Different types of processors respond to the occurrence of an interrupt in its own unique fashion.

In addition, each processor type provides a control mechanism to allow for the proper handling of an interrupt. The processor dependent response to the interrupt modifies the current execution state and results in a change in the execution stream.

Most processors require that an interrupt handler utilize some special control mechanisms to return to the normal processing stream. RTEMS and associated documentation uses the terms interrupt and vector. The terms will be used interchangeably in this manual. Asynchronous traps occur when an external event interrupts the processor. These traps are not associated with any instruction executed by the processor and logically occur between instructions.

The instruction currently in the execute stage of the processor is allowed to complete although subsequent instructions are annulled. The return address reported by the processor for asynchronous traps is the pair of instructions following the current instruction. Synchronous traps are caused by the actions of an instruction. The trap stimulus in this case either occurs internally to the processor or is from an external signal that was provoked by the instruction.

These traps are taken immediately and the instruction that caused the trap is aborted before any state changes occur in the processor itself. The return address reported by the processor for synchronous traps is the instruction which caused the trap and the following instruction. Trap processing on the SPARC has two features which are noticeably different than interrupt processing on other architectures.

First, the value of psr register in effect immediately before the trap occurred is not explicitly saved. Instead only reversible alterations are made to it.