9 files changed, 22 insertions, 22 deletions

diff --git a/porting/code_tuning.rst b/porting/code_tuning.rst
index 8090cab..e28bdd7 100644
--- a/porting/code_tuning.rst
+++ b/porting/code_tuning.rst
@@ -87,7 +87,7 @@ Data Alignment Requirements
 Data Element Alignment
 ----------------------
 
-The CPU_ALIGNMENT macro should be set to the CPU’s worst alignment
+The CPU_ALIGNMENT macro should be set to the CPU's worst alignment
 requirement for data types on a byte boundary.  This is typically the
 alignment requirement for a C double. This alignment does not take into
 account the requirements for the stack.
diff --git a/porting/cpu_init.rst b/porting/cpu_init.rst
index 0406c35..f880cab 100644
--- a/porting/cpu_init.rst
+++ b/porting/cpu_init.rst
@@ -38,7 +38,7 @@ During the initialization of the context for tasks with floating point,
 the CPU dependent code is responsible for initializing the floating point
 context.  If there is not an easy way to initialize the FP context during
 Context_Initialize, then it is usually easier to save an "uninitialized"
-FP context here and copy it to the task’s during Context_Initialize.  If
+FP context here and copy it to the task's during Context_Initialize.  If
 this technique is used to initialize the FP contexts, then it is important
 to ensure that the state of the floating point unit is in a coherent,
 initialized state.
diff --git a/porting/cpu_model_variations.rst b/porting/cpu_model_variations.rst
index 797a009..851df1f 100644
--- a/porting/cpu_model_variations.rst
+++ b/porting/cpu_model_variations.rst
@@ -105,8 +105,8 @@ processor families is not enough to address the needs of embedded systems
 developers.  Custom board development is the norm for embedded systems.
 Each of these boards is optimized for a particular project.  The processor
 and peripheral set have been chosen to meet a particular set of system
-requirements.  The tools in the embedded systems developers’ toolbox must
-support their project’s unique board.  RTEMS addresses this issue via the
+requirements.  The tools in the embedded systems developers toolbox must
+support their project's unique board.  RTEMS addresses this issue via the
 Board Support Package.
 
 RTEMS segregates board specific code to make it possible for the embedded
diff --git a/porting/idle_thread.rst b/porting/idle_thread.rst
index 18ac5ce..7bba283 100644
--- a/porting/idle_thread.rst
+++ b/porting/idle_thread.rst
@@ -86,7 +86,7 @@ self" which is implemented in a routine as follows.
     }
 
 If the CPU dependent IDLE thread body is implementation centers upon using
-a "halt", "idle", or "shutdown" instruction, then don’t forget to put it
+a "halt", "idle", or "shutdown" instruction, then don't forget to put it
 in an infinite loop as the CPU will have to reexecute this instruction
 each time the IDLE thread is dispatched.
 .. code:: c
diff --git a/porting/index.rst b/porting/index.rst
index 982d2a6..346a463 100644
--- a/porting/index.rst
+++ b/porting/index.rst
@@ -1,7 +1,7 @@
 ===================
 RTEMS Porting Guide
 ===================
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 
diff --git a/porting/interrupts.rst b/porting/interrupts.rst
index d6958ab..8a69e1a 100644
--- a/porting/interrupts.rst
+++ b/porting/interrupts.rst
@@ -305,7 +305,7 @@ The ``_ISR_Handler`` routine provides the RTEMS interrupt management.
 
 This discussion ignores a lot of the ugly details in a real implementation
 such as saving enough registers/state to be able to do something real.
-Keep in mind that the goal is to invoke a user’s ISR handler which is
+Keep in mind that the goal is to invoke a user's ISR handler which is
 written in C.  That ISR handler uses a known set of registers thus
 allowing the ISR to preserve only those that would normally be corrupted
 by a subroutine call.
@@ -368,7 +368,7 @@ specific wrapper for ``_Thread_Dispatch`` used in this case.
 ISR Invoked with Frame Pointer
 ------------------------------
 
-Does the RTEMS invoke the user’s ISR with the vector number and a pointer
+Does the RTEMS invoke the user's ISR with the vector number and a pointer
 to the saved interrupt frame (1) or just the vector number (0)?
 .. code:: c
 
diff --git a/porting/miscellanous.rst b/porting/miscellanous.rst
index 9bbd712..01073f7 100644
--- a/porting/miscellanous.rst
+++ b/porting/miscellanous.rst
@@ -5,7 +5,7 @@ Fatal Error Default Handler
 ===========================
 
 The ``_CPU_Fatal_halt`` routine is the default fatal error handler. This
-routine copies _error into a known place – typically a stack location or
+routine copies _error into a known place - typically a stack location or
 a register, optionally disables interrupts, and halts/stops the CPU.  It
 is prototyped as follows and is often implemented as a macro:
 .. code:: c
@@ -100,8 +100,8 @@ single instruction (e.g. i486).  It is probably best to avoid an "endian
 swapping control bit" in the CPU.  One good reason is that interrupts
 would probably have to be disabled to insure that an interrupt does not
 try to access the same "chunk" with the wrong endian.  Another good reason
-is that on some CPUs, the endian bit endianness for ALL fetches – both
-code and data – so the code will be fetched incorrectly.
+is that on some CPUs, the endian bit endianness for ALL fetches - both
+code and data - so the code will be fetched incorrectly.
 
 The following is an implementation of the ``CPU_swap_u32`` routine that will
 work on any CPU.  It operates by breaking the unsigned thirty-two bit
@@ -142,8 +142,8 @@ single instruction (e.g. i486).  It is probably best to avoid an "endian
 swapping control bit" in the CPU.  One good reason is that interrupts
 would probably have to be disabled to insure that an interrupt does not
 try to access the same "chunk" with the wrong endian.  Another good reason
-is that on some CPUs, the endian bit endianness for ALL fetches – both
-code and data – so the code will be fetched incorrectly.
+is that on some CPUs, the endian bit endianness for ALL fetches - both
+code and data - so the code will be fetched incorrectly.
 
 Similarly, here is a portable implementation of the ``CPU_swap_u16``
 routine.  Just as with the ``CPU_swap_u32`` routine, the porter
diff --git a/porting/priority_bitmap.rst b/porting/priority_bitmap.rst
index 36c294b..7b24451 100644
--- a/porting/priority_bitmap.rst
+++ b/porting/priority_bitmap.rst
@@ -85,8 +85,8 @@ major/minor) is the first bit found.
 This entire "find first bit" and mapping process depends heavily on the
 manner in which a priority is broken into a major and minor components
 with the major being the 4 MSB of a priority and minor the 4 LSB.  Thus (0
-<< 4) + 0 corresponds to priority 0 – the highest priority.  And (15 <<
-4) + 14 corresponds to priority 254 – the next to the lowest priority.
+<< 4) + 0 corresponds to priority 0 - the highest priority.  And (15 <<
+4) + 14 corresponds to priority 254 - the next to the lowest priority.
 
 If your CPU does not have a "find first bit" instruction, then there are
 ways to make do without it.  Here are a handful of ways to implement this
@@ -94,7 +94,7 @@ in software:
 
 - a series of 16 bit test instructions
 
-- a "binary search using if’s"
+- a "binary search using if's"
 
 - the following algorithm based upon a 16 entry lookup table.  In this pseudo-code, bit_set_table[16] has values which indicate the first bit set:
 
diff --git a/porting/task_context.rst b/porting/task_context.rst
index 62626ed..ec2d1e0 100644
--- a/porting/task_context.rst
+++ b/porting/task_context.rst
@@ -200,15 +200,15 @@ and ``_CPU_Context_switch`` will return to its caller.
 Care should be exercise when writing this routine.  All
 registers assumed to be preserved across subroutine calls
 must be preserved.  These registers may be saved in
-the task’s context area or on its stack.  However, the
+the task's context area or on its stack.  However, the
 stack pointer and address to resume executing the task
 at must be included in the context (normally the subroutine
 return address to the caller of ``_Thread_Dispatch``.
-The decision of where to store the task’s context is based
+The decision of where to store the task's context is based
 on numerous factors including the capabilities of
 the CPU architecture itself and simplicity as well
 as external considerations such as debuggers wishing
-to examine a task’s context.  In this case, it is
+to examine a task's context.  In this case, it is
 often simpler to save all data in the context area.
 
 Also there may be special considerations
@@ -292,7 +292,7 @@ is varying) macro is set based on the CPU family dependent macro.
 The macro name THIS_CPU_FAMILY_HAS_FPU should be made CPU specific.  It
 indicates whether or not this CPU model has FP support.  For example, the
 definition of the i386ex and i386sx CPU models would set I386_HAS_FPU to
-FALSE to indicate that these CPU models are i386’s without an i387 and
+FALSE to indicate that these CPU models are i386's without an i387 and
 wish to leave floating point support out of RTEMS when built for the
 i386_nofp processor model.  On a CPU with a built-in FPU like the i486,
 this would be defined as TRUE.
@@ -399,7 +399,7 @@ point context is dumped by a "FP save context" type instruction and the
 format is either not completely defined by the CPU documentation or the
 format is not critical for the implementation of the floating point
 context switch routines.  In this case, there is no need to figure out the
-exact format – only the size.  Of course, although this is enough
+exact format - only the size.  Of course, although this is enough
 information for RTEMS, it is probably not enough for a debugger such as
 gdb.  But that is another problem.
 .. code:: c
@@ -416,7 +416,7 @@ Size of Floating Point Context Macro
 
 The CPU_CONTEXT_FP_SIZE macro is set to the size of the floating point
 context area. On some CPUs this will not be a "sizeof" because the format
-of the floating point area is not defined – only the size is.  This is
+of the floating point area is not defined - only the size is.  This is
 usually on CPUs with a "floating point save context" instruction.  In
 general, though it is easier to define the structure as a "sizeof"
 operation and define the Context_Control_fp structure to be an area of