summaryrefslogtreecommitdiffstats
path: root/porting
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 /porting
parent11e1a6f969dc0b255dd7aed12509484cf7c7ed60 (diff)
downloadrtems-docs-d389819eea3a84e388935153e3be847342809da3.tar.bz2
Convert all Unicode to ASCII(128)
Diffstat (limited to 'porting')
-rw-r--r--porting/code_tuning.rst2
-rw-r--r--porting/cpu_init.rst2
-rw-r--r--porting/cpu_model_variations.rst4
-rw-r--r--porting/idle_thread.rst2
-rw-r--r--porting/index.rst2
-rw-r--r--porting/interrupts.rst4
-rw-r--r--porting/miscellanous.rst10
-rw-r--r--porting/priority_bitmap.rst6
-rw-r--r--porting/task_context.rst12
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