diff options
Diffstat (limited to '')
| -rw-r--r-- | cpu_supplement/atmel_avr.rst | 4 | ||||
| -rw-r--r-- | cpu_supplement/blackfin.rst | 4 | ||||
| -rw-r--r-- | cpu_supplement/index.rst | 2 | ||||
| -rw-r--r-- | cpu_supplement/intel_amd_x86.rst | 20 | ||||
| -rw-r--r-- | cpu_supplement/lattice_micro32.rst | 6 | ||||
| -rw-r--r-- | cpu_supplement/m68xxx_and_coldfire.rst | 16 | ||||
| -rw-r--r-- | cpu_supplement/mips.rst | 4 | ||||
| -rw-r--r-- | cpu_supplement/port.rst | 16 | ||||
| -rw-r--r-- | cpu_supplement/powerpc.rst | 30 | ||||
| -rw-r--r-- | cpu_supplement/sparc.rst | 38 | ||||
| -rw-r--r-- | cpu_supplement/sparc64.rst | 28 | ||||
| -rw-r--r-- | cpu_supplement/superh.rst | 4 |
12 files changed, 86 insertions, 86 deletions
diff --git a/cpu_supplement/atmel_avr.rst b/cpu_supplement/atmel_avr.rst index 98743fb..a075ef1 100644 --- a/cpu_supplement/atmel_avr.rst +++ b/cpu_supplement/atmel_avr.rst @@ -51,7 +51,7 @@ Register Usage -------------- A called function may clobber all registers, except RETS, R4-R7, P3-P5, -FP and SP. It may also modify the first 12 bytes in the callerâs stack +FP and SP. It may also modify the first 12 bytes in the caller's stack frame which is used as an argument area for the first three arguments (which are passed in R0...R3 but may be placed on the stack by the called function). @@ -80,7 +80,7 @@ protection mechanisms are not used. Interrupt Processing ==================== -Discussed in this chapter are the AVR’s interrupt response and +Discussed in this chapter are the AVR's interrupt response and control mechanisms as they pertain to RTEMS. Vectoring of an Interrupt Handler diff --git a/cpu_supplement/blackfin.rst b/cpu_supplement/blackfin.rst index 39f7b4f..5f517e7 100644 --- a/cpu_supplement/blackfin.rst +++ b/cpu_supplement/blackfin.rst @@ -55,7 +55,7 @@ Register Usage -------------- A called function may clobber all registers, except RETS, R4-R7, P3-P5, -FP and SP. It may also modify the first 12 bytes in the callerâs stack +FP and SP. It may also modify the first 12 bytes in the caller's stack frame which is used as an argument area for the first three arguments (which are passed in R0...R3 but may be placed on the stack by the called function). @@ -84,7 +84,7 @@ protection mechanisms are not used. Interrupt Processing ==================== -Discussed in this chapter are the Blackfin’s interrupt response and +Discussed in this chapter are the Blackfin's interrupt response and control mechanisms as they pertain to RTEMS. The Blackfin architecture support 16 kinds of interrupts broken down into Core and general-purpose interrupts. diff --git a/cpu_supplement/index.rst b/cpu_supplement/index.rst index b90e201..070fa21 100644 --- a/cpu_supplement/index.rst +++ b/cpu_supplement/index.rst @@ -2,7 +2,7 @@ RTEMS CPU Architecture Supplement ================================= -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/cpu_supplement/intel_amd_x86.rst b/cpu_supplement/intel_amd_x86.rst index 59db1cd..1ba9498 100644 --- a/cpu_supplement/intel_amd_x86.rst +++ b/cpu_supplement/intel_amd_x86.rst @@ -9,14 +9,14 @@ than being designed for growth. For information on the i386 processor, refer to the following documents: -- *386 Programmer’s Reference Manual, Intel, Order No. 230985-002*. +- *386 Programmer's Reference Manual, Intel, Order No. 230985-002*. - *386 Microprocessor Hardware Reference Manual, Intel, Order No. 231732-003*. -- *80386 System Software Writer’s Guide, Intel, Order No. 231499-001*. +- *80386 System Software Writer's Guide, Intel, Order No. 231499-001*. -- *80387 Programmer’s Reference Manual, Intel, Order No. 231917-001*. +- *80387 Programmer's Reference Manual, Intel, Order No. 231917-001*. CPU Model Dependent Features ============================ @@ -33,7 +33,7 @@ The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that this CPU model has the ``bswap`` instruction which endian swaps a thirty-two bit quantity. This instruction appears to be present in all CPU models -i486’s and above. +i486's and above. Calling Conventions =================== @@ -128,8 +128,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand how the RTEMS interrupt manager is mapped onto the -processor’s unique architecture. Discussed in this chapter are -the the processor’s response and control mechanisms as they +processor's unique architecture. Discussed in this chapter are +the the processor's response and control mechanisms as they pertain to RTEMS. Vectoring of Interrupt Handler @@ -175,7 +175,7 @@ Interrupt Levels ---------------- Although RTEMS supports 256 interrupt levels, the -i386 only supports two – enabled and disabled. Interrupts are +i386 only supports two - enabled and disabled. Interrupts are enabled when the interrupt-enable flag (IF) in the extended flags (EFLAGS) is set. Conversely, interrupt processing is inhibited when the IF is cleared. During a non-maskable @@ -225,7 +225,7 @@ System Reset An RTEMS based application is initiated when the i386 processor is reset. When the i386 is reset, -- The EAX register is set to indicate the results of the processor’s +- The EAX register is set to indicate the results of the processor's power-up self test. If the self-test was not executed, the contents of this register are undefined. Otherwise, a non-zero value indicates the processor is faulty and a zero value indicates a successful self-test. @@ -253,7 +253,7 @@ When the i386 is reset, lines are lowered and the processor begins executing in the first megabyte of memory. -Typically, an intersegment JMP to the application’s initialization code is +Typically, an intersegment JMP to the application's initialization code is placed at address 0xFFFFFFF0. Processor Initialization @@ -306,7 +306,7 @@ which is executed before the call to initialize_executive has the following requirements: For more information regarding the i386 data structures and their -contents, refer to Intel’s 386 Programmer’s Reference Manual. +contents, refer to Intel's 386 Programmer's Reference Manual. .. COMMENT: COPYRIGHT (c) 1988-2002. diff --git a/cpu_supplement/lattice_micro32.rst b/cpu_supplement/lattice_micro32.rst index 5947c91..d5dae64 100644 --- a/cpu_supplement/lattice_micro32.rst +++ b/cpu_supplement/lattice_micro32.rst @@ -5,7 +5,7 @@ This chaper discusses the Lattice Mico32 architecture dependencies in this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC architecture "soft" microprocessor, available for free with an open IP core licensing agreement. Although mainly targeted for Lattice FPGA -devices the microprocessor can be implemented on other vendors’ FPGAs, +devices the microprocessor can be implemented on other vendors' FPGAs, too. **Architecture Documents** @@ -192,7 +192,7 @@ handlers are configured or all of them return without taking action to shutdown the processor or reset, a default fatal error handler is invoked. Most of the action performed as part of processing the fatal error are -described in detail in the Fatal Error Manager chapter in the User’s +described in detail in the Fatal Error Manager chapter in the User's Guide. However, the if no user provided extension or BSP specific fatal error handler takes action, the final default action is to invoke a CPU architecture specific function. Typically this function disables @@ -221,7 +221,7 @@ In each of the architecture specific chapters, this section will present a discussion of architecture specific BSP issues. For more information on developing a BSP, refer to BSP and Device Driver Development Guide and the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ diff --git a/cpu_supplement/m68xxx_and_coldfire.rst b/cpu_supplement/m68xxx_and_coldfire.rst index 3ac41f9..e5c9f1b 100644 --- a/cpu_supplement/m68xxx_and_coldfire.rst +++ b/cpu_supplement/m68xxx_and_coldfire.rst @@ -17,9 +17,9 @@ For information on the MC68xxx and Coldfire architecture, refer to the following - *M68000 Family Reference, Motorola, FR68K/D*. -- *MC68020 User’s Manual, Motorola, MC68020UM/AD*. +- *MC68020 User's Manual, Motorola, MC68020UM/AD*. -- *MC68881/MC68882 Floating-Point Coprocessor User’s Manual, +- *MC68881/MC68882 Floating-Point Coprocessor User's Manual, Motorola, MC68881UM/AD*. CPU Model Dependent Features @@ -136,7 +136,7 @@ segmentation on any of the MC68xxx family members. Interrupt Processing ==================== -Discussed in this section are the MC68xxx’s interrupt response and +Discussed in this section are the MC68xxx's interrupt response and control mechanisms as they pertain to RTEMS. Vectoring of an Interrupt Handler @@ -182,7 +182,7 @@ interrupt stacks automatically perform the following actions: installed with the interrupt_catch directive, then the RTEMS interrupt handler will begin execution. The RTEMS interrupt handler saves all registers which are not preserved according to - the calling conventions and invokes the application’s ISR. + the calling conventions and invokes the application's ISR. A nested interrupt is processed similarly by these CPU models with the exception that only a single ISF is placed @@ -339,11 +339,11 @@ the following actions: Processor Initialization ------------------------ -The address of the application’s initialization code should be stored in +The address of the application's initialization code should be stored in the first vector of the EVT which will allow the immediate vectoring to the application code. If the application requires that the VBR be some value besides zero, then it should be set to the required value at this -point. All tasks share the same MC68020’s VBR value. Because interrupts +point. All tasks share the same MC68020's VBR value. Because interrupts are enabled automatically by RTEMS as part of the context switch to the first task, the VBR MUST be set by either RTEMS of the BSP before this occurs ensure correct interrupt vectoring. If processor caching is @@ -351,7 +351,7 @@ to be utilized, then it should be enabled during the reset application initialization code. In addition to the requirements described in the -Board Support Packages chapter of the Applications User’s +Board Support Packages chapter of the Applications User's Manual for the reset code which is executed before the call to initialize executive, the MC68020 version has the following specific requirements: @@ -366,7 +366,7 @@ specific requirements: minimum stack size of MINIMUM_STACK_SIZE bytes is provided for the initialize executive directive. -- Must initialize the MC68020’s vector table. +- Must initialize the MC68020's vector table. .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. diff --git a/cpu_supplement/mips.rst b/cpu_supplement/mips.rst index 9db2bd7..b01b116 100644 --- a/cpu_supplement/mips.rst +++ b/cpu_supplement/mips.rst @@ -74,8 +74,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the MIPS’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MIPS's interrupt response and control mechanisms as they pertain to RTEMS. diff --git a/cpu_supplement/port.rst b/cpu_supplement/port.rst index c59216e..2a9a3b3 100644 --- a/cpu_supplement/port.rst +++ b/cpu_supplement/port.rst @@ -42,7 +42,7 @@ unit or coprocessor. When defining the list of features present on a particular CPU model, one simply notes that floating point hardware is or is not present and defines a single constant appropriately. Conditional compilation is utilized to include the appropriate source -code for this CPU model’s feature set. It is important to note that +code for this CPU model's feature set. It is important to note that this means that RTEMS is thus compiled using the appropriate feature set and compilation flags optimal for this CPU model used. The alternative would be to generate a binary which would execute on all family members @@ -118,7 +118,7 @@ Calling Conventions =================== Each high-level language compiler generates subroutine entry and exit -code based upon a set of rules known as the compiler’s calling convention. +code based upon a set of rules known as the compiler's calling convention. These rules address the following issues: - register preservation and usage @@ -127,7 +127,7 @@ These rules address the following issues: - call and return mechanism -A compiler’s calling convention is of importance when +A compiler's calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level. Even when the high-level language and target processor are the same, different compilers may use @@ -177,7 +177,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. 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 @@ -219,7 +219,7 @@ processors require that an interrupt handler utilize some special control mechanisms to return to the normal processing stream. Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand how the RTEMS interrupt manager is mapped -onto the processor’s unique architecture. +onto the processor's unique architecture. RTEMS supports a dedicated interrupt stack for all architectures. On architectures with hardware support for a dedicated interrupt stack, @@ -243,7 +243,7 @@ to switch to the interrupt stack. In some configurations, RTEMS allocates the interrupt stack from the Workspace Area. The amount of memory allocated for the interrupt stack is user configured and based upon the ``confdefs.h`` parameter``CONFIGURE_INTERRUPT_STACK_SIZE``. This parameter is described -in detail in the Configuring a System chapter of the User’s Guide. +in detail in the Configuring a System chapter of the User's Guide. On configurations in which RTEMS allocates the interrupt stack, during the initialization process, RTEMS will also install its interrupt stack. In other configurations, the interrupt stack is allocated and installed @@ -318,7 +318,7 @@ handlers are configured or all of them return without taking action to shutdown the processor or reset, a default fatal error handler is invoked. Most of the action performed as part of processing the fatal error are -described in detail in the Fatal Error Manager chapter in the User’s +described in detail in the Fatal Error Manager chapter in the User's Guide. However, the if no user provided extension or BSP specific fatal error handler takes action, the final default action is to invoke a CPU architecture specific function. Typically this function disables @@ -414,7 +414,7 @@ In each of the architecture specific chapters, this section will present a discussion of architecture specific BSP issues. For more information on developing a BSP, refer to BSP and Device Driver Development Guide and the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ diff --git a/cpu_supplement/powerpc.rst b/cpu_supplement/powerpc.rst index 2f65bbb..acfcc61 100644 --- a/cpu_supplement/powerpc.rst +++ b/cpu_supplement/powerpc.rst @@ -20,27 +20,27 @@ the following documents available from Motorola and IBM: - *PowerPC Microprocessor Family: The Programming Environment* (Motorola Document MPRPPCFPE-01). -- *IBM PPC403GB Embedded Controller User’s Manual*. +- *IBM PPC403GB Embedded Controller User's Manual*. - *PoweRisControl MPC500 Family RCPU RISC Central Processing Unit Reference Manual* (Motorola Document RCPUURM/AD). -- *PowerPC 601 RISC Microprocessor User’s Manual* +- *PowerPC 601 RISC Microprocessor User's Manual* (Motorola Document MPR601UM/AD). -- *PowerPC 603 RISC Microprocessor User’s Manual* +- *PowerPC 603 RISC Microprocessor User's Manual* (Motorola Document MPR603UM/AD). -- *PowerPC 603e RISC Microprocessor User’s Manual* +- *PowerPC 603e RISC Microprocessor User's Manual* (Motorola Document MPR603EUM/AD). -- *PowerPC 604 RISC Microprocessor User’s Manual* +- *PowerPC 604 RISC Microprocessor User's Manual* (Motorola Document MPR604UM/AD). -- *PowerPC MPC821 Portable Systems Microprocessor User’s Manual* +- *PowerPC MPC821 Portable Systems Microprocessor User's Manual* (Motorola Document MPC821UM/AD). -- *PowerQUICC MPC860 User’s Manual* (Motorola Document MPC860UM/AD). +- *PowerQUICC MPC860 User's Manual* (Motorola Document MPC860UM/AD). Motorola maintains an on-line electronic library for the PowerPC at the following URL: @@ -75,7 +75,7 @@ model specified on the compilation command line. Alignment --------- -The macro PPC_ALIGNMENT is set to the PowerPC model’s worst case alignment +The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment requirement for data types on a byte boundary. This value is used to derive the alignment restrictions for memory allocated from regions and partitions. @@ -411,8 +411,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the PowerPC’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the PowerPC's interrupt response and control mechanisms as they pertain to RTEMS. @@ -468,10 +468,10 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - saves all registers which are not normally preserved - by the calling sequence so the user’s interrupt service + by the calling sequence so the user's interrupt service routine can be written in a high-level language. - if this is the outermost (i.e. non-nested) interrupt, @@ -560,7 +560,7 @@ An RTEMS based application is initiated or re-initiated when the PowerPC processor is reset. The PowerPC architecture defines a Reset Exception, but leaves the details of the CPU state as implementation specific. Please -refer to the User’s Manual for the CPU model in question. +refer to the User's Manual for the CPU model in question. In general, at power-up the PowerPC begin execution at address 0xFFF00100 in supervisor mode with all exceptions disabled. For @@ -579,7 +579,7 @@ observed to prevent some emulators from working properly, so it may be necessary to run with caching disabled to use these emulators. In addition to the requirements described in the*Board Support Packages* chapter of the RTEMS C -Applications User’s Manual for the reset code +Applications User's Manual for the reset code which is executed before the call to ``rtems_initialize_executive``, the PowrePC version has the following specific requirements: @@ -596,7 +596,7 @@ the PowrePC version has the following specific requirements: - Must enable traps so window overflow and underflow conditions can be properly handled. -- Must initialize the PowerPC’s initial Exception Table with default +- Must initialize the PowerPC's initial Exception Table with default handlers. .. COMMENT: COPYRIGHT (c) 1988-2002. diff --git a/cpu_supplement/sparc.rst b/cpu_supplement/sparc.rst index a69beb2..9a0c15b 100644 --- a/cpu_supplement/sparc.rst +++ b/cpu_supplement/sparc.rst @@ -33,7 +33,7 @@ the following documents available from SPARC International, Inc. **ERC32 Specific Information** -The European Space Agency’s ERC32 is a three chip +The European Space Agency's ERC32 is a three chip computing core implementing a SPARC V7 processor and associated support circuitry for embedded space applications. The integer and floating-point units (90C601E & 90C602E) are based on the @@ -56,7 +56,7 @@ browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. - MEC Device Specification -Additionally, the SPARC RISC User’s Guide from Matra +Additionally, the SPARC RISC User's Guide from Matra MHS documents the functionality of the integer and floating point units including the instruction set information. To obtain this document as well as ERC32 components and VHDL models @@ -112,7 +112,7 @@ features present on a particular CPU model, one simply notes that floating point hardware is or is not present and defines a single constant appropriately. Conditional compilation is utilized to include the appropriate source code for this CPU -model’s feature set. It is important to note that this means +model's feature set. It is important to note that this means that RTEMS is thus compiled using the appropriate feature set and compilation flags optimal for this CPU model used. The alternative would be to generate a binary which would execute on @@ -130,7 +130,7 @@ CPU Model Name The macro CPU_MODEL_NAME is a string which designates the name of this CPU model. For example, for the European Space -Agency’s ERC32 SPARC model, this macro is set to the string +Agency's ERC32 SPARC model, this macro is set to the string "erc32". Floating Point Unit @@ -385,7 +385,7 @@ registers windows. Because the set of register windows is finite, it is possible to execute enough save instructions without -corresponding restore’s to consume all of the register windows. +corresponding restore's to consume all of the register 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 @@ -396,7 +396,7 @@ is responsible for saving the contents of the oldest register window on the program stack. Similarly, the subroutines will eventually complete -and begin to perform restore’s. If the restore results in the +and begin to perform restore's. 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 @@ -458,7 +458,7 @@ Call and Return Mechanism The SPARC architecture supports a simple yet effective call and return mechanism. A subroutine is invoked via the call (call) instruction. This instruction places the -return address in the caller’s output register 7 (o7). After +return address in the caller's output register 7 (o7). After the callee executes a save instruction, this value is available in input register 7 (i7) until the corresponding restore instruction is executed. @@ -466,7 +466,7 @@ 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 +instruction - if a register window was allocated by this subroutine. It is important to note that the SPARC subroutine @@ -500,7 +500,7 @@ Parameter Passing ----------------- RTEMS assumes that arguments are placed in the -caller’s output registers with the first argument in output +caller's output registers with the first argument in output register 0 (o0), the second argument in output register 1 (o1), and so forth. Until the callee executes a save instruction, the parameters are still visible in the output registers. After the @@ -534,7 +534,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. 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 @@ -601,8 +601,8 @@ Most processors require that an interrupt handler utilize some special control mechanisms to return to the normal processing stream. Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the SPARC’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the SPARC's interrupt response and control mechanisms as they pertain to RTEMS. @@ -676,7 +676,7 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - insures that a register window is available for subsequent traps, @@ -713,7 +713,7 @@ trap cannot be correctly processed unless (1) traps are enabled and (2) a register window is reserved for traps. Thus, the RTEMS interrupt handler insures that a register window is available for subsequent traps before enabling traps and -invoking the user’s interrupt handler. +invoking the user's interrupt handler. Interrupt Levels ---------------- @@ -792,7 +792,7 @@ execute on the stack of the RTEMS task which they interrupted. This artificially inflates the stack requirements for each task since EVERY task stack would have to include enough space to account for the worst case interrupt stack requirements in -addition to it’s own worst case usage. RTEMS addresses this +addition to it's own worst case usage. RTEMS addresses this problem on the SPARC by providing a dedicated interrupt stack managed by software. @@ -864,7 +864,7 @@ to support a particular processor and target board combination. This chapter presents a discussion of SPARC specific BSP issues. For more information on developing a BSP, refer to the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ @@ -891,14 +891,14 @@ reflect the last trap which occurred before the reset. Processor Initialization ------------------------ -It is the responsibility of the application’s +It is the responsibility of the application's initialization code to initialize the TBR and install trap handlers for at least the register window overflow and register window underflow conditions. Traps should be enabled before invoking any subroutines to allow for register window management. However, interrupts should be disabled by setting the Processor Interrupt Level (pil) field of the psr to 15. -RTEMS installs it’s own Trap Table as part of initialization +RTEMS installs it's own Trap Table as part of initialization which is initialized with the contents of the Trap Table in place when the ``rtems_initialize_executive`` directive was invoked. Upon completion of executive initialization, interrupts are @@ -926,7 +926,7 @@ specific requirements: - Must enable traps so window overflow and underflow conditions can be properly handled. -- Must initialize the SPARC’s initial trap table with at +- Must initialize the SPARC's initial trap table with at least trap handlers for register window overflow and register window underflow. diff --git a/cpu_supplement/sparc64.rst b/cpu_supplement/sparc64.rst index a4325de..ad568cb 100644 --- a/cpu_supplement/sparc64.rst +++ b/cpu_supplement/sparc64.rst @@ -16,7 +16,7 @@ through UltraSPARC IV processors. The following documents were used in developing the SPARC-64 sun4u port: -- UltraSPARC Userâs Manual +- UltraSPARC User's Manual (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) - UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) @@ -104,7 +104,7 @@ Calling Conventions Each high-level language compiler generates subroutine entry and exit code based upon a set of rules known -as the compiler’s calling convention. These rules address the +as the compiler's calling convention. These rules address the following issues: - register preservation and usage @@ -113,7 +113,7 @@ following issues: - call and return mechanism -A compiler’s calling convention is of importance when +A compiler's calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level. Even when the high-level language and target processor are the same, different compilers may use @@ -222,7 +222,7 @@ The SPARC architecture includes a number of special registers: *``Processor State Register (pstate)``* The privileged pstate register contains control fields for the proces- - sorâs current state. Its flag fields include the interrupt enable, privi- + sor's current state. Its flag fields include the interrupt enable, privi- leged mode, and enable FPU. *``Processor Interrupt Level (pil)``* @@ -270,7 +270,7 @@ registers are shared between adjacent registers windows. Because the set of register windows is finite, it is possible to execute enough save instructions without -corresponding restore’s to consume all of the register windows. +corresponding restore's to consume all of the register 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 @@ -281,7 +281,7 @@ is responsible for saving the contents of the oldest register window on the program stack. Similarly, the subroutines will eventually complete -and begin to perform restore’s. If the restore results in the +and begin to perform restore's. 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 @@ -338,7 +338,7 @@ Call and Return Mechanism The SPARC architecture supports a simple yet effective call and return mechanism. A subroutine is invoked via the call (call) instruction. This instruction places the -return address in the caller’s output register 7 (o7). After +return address in the caller's output register 7 (o7). After the callee executes a save instruction, this value is available in input register 7 (i7) until the corresponding restore instruction is executed. @@ -346,7 +346,7 @@ 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 +instruction - if a register window was allocated by this subroutine. It is important to note that the SPARC subroutine @@ -354,7 +354,7 @@ 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. This allows for the compiler to generate leaf-optimized functions -that utilize the callerâs output registers without using save and restore. +that utilize the caller's output registers without using save and restore. Calling Mechanism ----------------- @@ -376,7 +376,7 @@ Parameter Passing ----------------- RTEMS assumes that arguments are placed in the -caller’s output registers with the first argument in output +caller's output registers with the first argument in output register 0 (o0), the second argument in output register 1 (o1), and so forth. Until the callee executes a save instruction, the parameters are still visible in the output registers. After the @@ -410,7 +410,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. 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 @@ -542,7 +542,7 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - switches the processor to trap level 0, @@ -597,7 +597,7 @@ execute on the stack of the RTEMS task which they interrupted. This artificially inflates the stack requirements for each task since EVERY task stack would have to include enough space to account for the worst case interrupt stack requirements in -addition to it’s own worst case usage. RTEMS addresses this +addition to it's own worst case usage. RTEMS addresses this problem on the SPARC by providing a dedicated interrupt stack managed by software. @@ -661,7 +661,7 @@ to support a particular processor and target board combination. This chapter presents a discussion of SPARC specific BSP issues. For more information on developing a BSP, refer to the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. HelenOS and Open Firmware ------------------------- diff --git a/cpu_supplement/superh.rst b/cpu_supplement/superh.rst index 9d62dba..abede7f 100644 --- a/cpu_supplement/superh.rst +++ b/cpu_supplement/superh.rst @@ -84,8 +84,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the MIPS’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MIPS's interrupt response and control mechanisms as they pertain to RTEMS. |