summaryrefslogtreecommitdiffstats
path: root/cpu_supplement
diff options
context:
space:
mode:
authorAmar Takhar <amar@rtems.org>2016-01-18 00:37:40 -0500
committerAmar Takhar <verm@darkbeer.org>2016-05-02 20:51:24 -0400
commitd389819eea3a84e388935153e3be847342809da3 (patch)
tree15cfe55f41281cead805ce87f66c5d7248caa9ce /cpu_supplement
parent11e1a6f969dc0b255dd7aed12509484cf7c7ed60 (diff)
downloadrtems-docs-d389819eea3a84e388935153e3be847342809da3.tar.bz2
Convert all Unicode to ASCII(128)
Diffstat (limited to 'cpu_supplement')
-rw-r--r--cpu_supplement/atmel_avr.rst4
-rw-r--r--cpu_supplement/blackfin.rst4
-rw-r--r--cpu_supplement/index.rst2
-rw-r--r--cpu_supplement/intel_amd_x86.rst20
-rw-r--r--cpu_supplement/lattice_micro32.rst6
-rw-r--r--cpu_supplement/m68xxx_and_coldfire.rst16
-rw-r--r--cpu_supplement/mips.rst4
-rw-r--r--cpu_supplement/port.rst16
-rw-r--r--cpu_supplement/powerpc.rst30
-rw-r--r--cpu_supplement/sparc.rst38
-rw-r--r--cpu_supplement/sparc64.rst28
-rw-r--r--cpu_supplement/superh.rst4
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.