[rtems commit] porting: Fix code-block markup

[Joel Sherrill]

Module:    rtems
Branch:    master
Commit:    b0f29772e22edbf3b2adf2e058fc445da4419e2c
Changeset: http://git.rtems.org/rtems/commit/?id=b0f29772e22edbf3b2adf2e058fc445da4419e2c

Author:    Joel Sherrill <joel at rtems.org>
Date:      Thu Oct 27 20:01:47 2016 -0500

porting: Fix code-block markup

---

 porting/code_tuning.rst     | 12 ++++++------
 porting/cpu_init.rst        |  4 ++--
 porting/idle_thread.rst     | 10 +++++-----
 porting/interrupts.rst      | 48 ++++++++++++++++++++++-----------------------
 porting/miscellanous.rst    | 14 ++++++-------
 porting/priority_bitmap.rst | 12 ++++++------
 porting/task_context.rst    | 42 +++++++++++++++++++--------------------
 7 files changed, 71 insertions(+), 71 deletions(-)

diff --git a/porting/code_tuning.rst b/porting/code_tuning.rst
index a4fb2af..5fd664e 100644
--- a/porting/code_tuning.rst
+++ b/porting/code_tuning.rst
@@ -21,7 +21,7 @@ unless you are in an interrupt handler and that interrupt handler invokes
 the executive.] When not inlined something calls _Thread_Enable_dispatch
 which in turns calls _Thread_Dispatch.  If the enable dispatch is inlined,
 then one subroutine call is avoided entirely.]
-.. code:: c
+.. code-block:: c
 
     #define CPU_INLINE_ENABLE_DISPATCH       FALSE
 
@@ -44,7 +44,7 @@ the loop body.  In this case, it might be desirable to unroll the loop.
 It is important to note that on some CPUs, this code is the longest
 interrupt disable period in RTEMS.  So it is necessary to strike a balance
 when setting this parameter.
-.. code:: c
+.. code-block:: c
 
     #define CPU_UNROLL_ENQUEUE_PRIORITY      TRUE
 
@@ -79,7 +79,7 @@ currently uses this feature.
 The following illustrates how the CPU_STRUCTURE_ALIGNMENT is defined on
 ports which require no special alignment for optimized access to data
 structures:
-.. code:: c
+.. code-block:: c
 
     #define CPU_STRUCTURE_ALIGNMENT
 
@@ -97,7 +97,7 @@ account the requirements for the stack.
 The following sets the CPU_ALIGNMENT macro to 8 which indicates that there
 is a basic C data type for this port which much be aligned to an 8 byte
 boundary.
-.. code:: c
+.. code-block:: c
 
     #define CPU_ALIGNMENT              8
 
@@ -116,7 +116,7 @@ use by high level language routines.
 The following example illustrates how the CPU_HEAP_ALIGNMENT macro is set
 when the required alignment for elements from the heap is the same as the
 basic CPU alignment requirements.
-.. code:: c
+.. code-block:: c
 
     #define CPU_HEAP_ALIGNMENT         CPU_ALIGNMENT
 
@@ -140,7 +140,7 @@ The following example illustrates how the CPU_PARTITION_ALIGNMENT macro is
 set when the required alignment for elements from the RTEMS Partition
 Manager is the same as the basic CPU alignment requirements.
 
-.. code:: c
+.. code-block:: c
 
     #define CPU_PARTITION_ALIGNMENT    CPU_ALIGNMENT
 
diff --git a/porting/cpu_init.rst b/porting/cpu_init.rst
index 39a27ed..c4f7e7d 100644
--- a/porting/cpu_init.rst
+++ b/porting/cpu_init.rst
@@ -16,7 +16,7 @@ Initializing the CPU
 ====================
 
 The _CPU_Initialize routine performs processor dependent initialization.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Initialize(
     void            (*thread_dispatch)  /* may be ignored */
@@ -32,7 +32,7 @@ limitation on these systems.
 
 If you encounter this problem save the entry point in a CPU dependent
 variable as shown below:
-.. code:: c
+.. code-block:: c
 
     _CPU_Thread_dispatch_pointer = thread_dispatch;
 
diff --git a/porting/idle_thread.rst b/porting/idle_thread.rst
index c0a350a..317cf2a 100644
--- a/porting/idle_thread.rst
+++ b/porting/idle_thread.rst
@@ -22,7 +22,7 @@ required to preempt the IDLE task from an interrupt because the floating
 point context must be saved as part of the preemption.
 
 The following illustrates how to set this macro:
-.. code:: c
+.. code-block:: c
 
     #define CPU_IDLE_TASK_IS_FP      FALSE
 
@@ -56,7 +56,7 @@ The order of precedence for selecting the IDLE thread body is:
 # generic (if no BSP and no CPU dependent)
 
 The following illustrates setting the CPU_PROVIDES_IDLE_THREAD_BODY macro:
-.. code:: c
+.. code-block:: c
 
     #define CPU_PROVIDES_IDLE_THREAD_BODY    TRUE
 
@@ -71,7 +71,7 @@ wishes to include a CPU dependent IDLE thread body.  If the port includes
 a CPU dependent implementation of the IDLE thread body, then the
 CPU_PROVIDES_IDLE_THREAD_BODY macro should be defined to TRUE.  This
 routine is prototyped as follows:
-.. code:: c
+.. code-block:: c
 
     void *_CPU_Thread_Idle_body( uintptr_t );
 
@@ -80,7 +80,7 @@ thread body be provided as part of the port.  If
 CPU_PROVIDES_IDLE_THREAD_BODY is defined to FALSE, then the CPU
 independent algorithm is used.  This algorithm consists of a "branch to
 self" which is implemented in a routine as follows.
-.. code:: c
+.. code-block:: c
 
     void *_Thread_Idle_body( uintptr_t ignored )
     {
@@ -91,7 +91,7 @@ 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
 in an infinite loop as the CPU will have to reexecute this instruction
 each time the IDLE thread is dispatched.
-.. code:: c
+.. code-block:: c
 
     void *_CPU_Thread_Idle_body( uintptr_t ignored )
     {
diff --git a/porting/interrupts.rst b/porting/interrupts.rst
index 00013ed..d8580ce 100644
--- a/porting/interrupts.rst
+++ b/porting/interrupts.rst
@@ -28,7 +28,7 @@ The CPU_MODES_INTERRUPT_MASK macro defines the number of bits actually used in t
 The following illustrates how the CPU_MODES_INTERRUPT_MASK is set on a CPU
 family like the Intel i386 where the CPU itself only recognizes two
 interrupt levels - enabled and disabled.
-.. code:: c
+.. code-block:: c
 
     #define CPU_MODES_INTERRUPT_MASK   0x00000001
 
@@ -36,7 +36,7 @@ Obtaining the Current Interrupt Level
 -------------------------------------
 
 The _CPU_ISR_Get_level function returns the current interrupt level.
-.. code:: c
+.. code-block:: c
 
     uint32_t _CPU_ISR_Get_level( void )
 
@@ -54,14 +54,14 @@ manage a programmable interrupt controller via the rtems_task_mode
 directive.
 
 The following is a dummy implementation of the _CPU_ISR_Set_level routine:
-.. code:: c
+.. code-block:: c
 
     #define _CPU_ISR_Set_level( new_level ) \\
     { \\
     }
 
 The following is the implementation from the Motorola M68K:
-.. code:: c
+.. code-block:: c
 
     XXX insert m68k implementation here
 
@@ -84,7 +84,7 @@ manipulate.  It is typically the contents of the processor status
 register.  It is NOT the same format as manipulated by the
 _CPU_ISR_Get_level and _CPU_ISR_Set_level routines. The following is a
 dummy implementation that simply sets the previous level to 0.
-.. code:: c
+.. code-block:: c
 
     #define _CPU_ISR_Disable( _isr_cookie ) \\
     { \
@@ -92,7 +92,7 @@ dummy implementation that simply sets the previous level to 0.
     }
 
 The following is the implementation from the Motorola M68K port:
-.. code:: c
+.. code-block:: c
 
     XXX insert m68k port here
 
@@ -105,14 +105,14 @@ RTEMS critical section to reenable interrupts.  The parameter _level is
 not modified but indicates that level that interrupts should be enabled
 to.  The following illustrates a dummy implementation of the
 _CPU_ISR_Enable routine:
-.. code:: c
+.. code-block:: c
 
     #define _CPU_ISR_Enable( _isr_cookie )  \\
     { \\
     }
 
 The following is the implementation from the Motorola M68K port:
-.. code:: c
+.. code-block:: c
 
     XXX insert m68k version here
 
@@ -126,14 +126,14 @@ preceded by a call to _CPU_ISR_Disable and followed by a call to
 _CPU_ISR_Enable.  The parameter _level is not modified.
 
 The following is a dummy implementation of the _CPU_ISR_Flash routine:
-.. code:: c
+.. code-block:: c
 
     #define _CPU_ISR_Flash( _isr_cookie ) \\
     { \\
     }
 
 The following is the implementation from the Motorola M68K port:
-.. code:: c
+.. code-block:: c
 
     XXX insert m68k version here
 
@@ -179,12 +179,12 @@ in the Interrupt Manager, then the macro CPU_ALLOCATE_INTERRUPT_STACK
 should be set to TRUE.
 
 NOTE: This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
-.. code:: c
+.. code-block:: c
 
     #define CPU_ALLOCATE_INTERRUPT_STACK TRUE
 
 If the CPU_HAS_SOFTWARE_INTERRUPT_STACK macro is set to TRUE, then RTEMS automatically allocates the stack memory in the initialization of the Interrupt Manager and the switch to that stack is performed in ``_ISR_Handler`` on the outermost interrupt.  The _CPU_Interrupt_stack_low and _CPU_Interrupt_stack_high variables contain the addresses of the the lowest and highest addresses of the memory allocated for the interrupt stack.  Although technically only one of these addresses is required to switch to the interrupt stack, by always providing both addresses, the port has more options avaialble to it without requiring modifications to the portable parts of the executive.  Whether the stack  grows up or down, this give the CPU dependent code the option of picking the version it wants to use.
-.. code:: c
+.. code-block:: c
 
     SCORE_EXTERN void               *_CPU_Interrupt_stack_low;
     SCORE_EXTERN void               *_CPU_Interrupt_stack_high;
@@ -200,7 +200,7 @@ The _CPU_Install_interrupt_stack routine XXX
 This routine installs the hardware interrupt stack pointer.
 
 NOTE:  It need only be provided if CPU_HAS_HARDWARE_INTERRUPT_STAC is TRUE.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Install_interrupt_stack( void )
 
@@ -211,7 +211,7 @@ Install a Raw Interrupt Handler
 -------------------------------
 
 The _CPU_ISR_install_raw_handler XXX
-.. code:: c
+.. code-block:: c
 
     void _CPU_ISR_install_raw_handler(
       unsigned32  vector,
@@ -235,7 +235,7 @@ by this CPU model.  The second macro is the
 CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER.  Since the table is zero-based, this
 indicates the highest vector number which can be looked up in the table
 and mapped into a user provided handler.
-.. code:: c
+.. code-block:: c
 
     #define CPU_INTERRUPT_NUMBER_OF_VECTORS      32
     #define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER \\
@@ -251,7 +251,7 @@ XXX Input parameters:
 vector      - interrupt vector number
 old_handler - former ISR for this vector number
 new_handler - replacement ISR for this vector number
-.. code:: c
+.. code-block:: c
 
     void _CPU_ISR_install_vector(
       unsigned32  vector,
@@ -259,20 +259,20 @@ new_handler - replacement ISR for this vector number
       proc_ptr   *old_handler
     )
 
-.. code:: c
+.. code-block:: c
 
     *old_handler = _ISR_Vector_table[ vector ];
 
 If the interrupt vector table is a table of pointer to isr entry points,
 then we need to install the appropriate RTEMS interrupt handler for this
 vector number.
-.. code:: c
+.. code-block:: c
 
     _CPU_ISR_install_raw_handler( vector, new_handler, old_handler );
 
 We put the actual user ISR address in _ISR_vector_table.  This will be
 used by the ``_ISR_Handler`` so the user gets control.
-.. code:: c
+.. code-block:: c
 
     _ISR_Vector_table[ vector ] = new_handler;
 
@@ -290,7 +290,7 @@ results in the saving of registers which are NOT preserved across
 subroutine calls as well as any special interrupt state.  A port should
 define the ``CPU_Interrupt_frame`` structure so that application code can
 examine the saved state.
-.. code:: c
+.. code-block:: c
 
     typedef struct {
       unsigned32 not_preserved_register_1;
@@ -301,7 +301,7 @@ Interrupt Dispatching
 ---------------------
 
 The ``_ISR_Handler`` routine provides the RTEMS interrupt management.
-.. code:: c
+.. code-block:: c
 
     void _ISR_Handler()
 
@@ -333,7 +333,7 @@ hardware does not provide this information, then the assembly portion of
 RTEMS for this port will contain a set of distinct interrupt entry points
 which somehow place the vector number in a known place (which is safe if
 another interrupt nests this one) and branches to ``_ISR_Handler``.
-.. code:: c
+.. code-block:: c
 
     save some or all context on stack
     may need to save some special interrupt information for exit
@@ -372,7 +372,7 @@ ISR Invoked with Frame 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
+.. code-block:: c
 
     #define CPU_ISR_PASSES_FRAME_POINTER 0
 
@@ -390,7 +390,7 @@ variable can be optionally defined by the CPU porter and contains the
 address of the routine _Thread_Dispatch.  This can make it easier to
 invoke that routine at the end of the interrupt sequence (if a dispatch is
 necessary).
-.. code:: c
+.. code-block:: c
 
     void (*_CPU_Thread_dispatch_pointer)();
 
diff --git a/porting/miscellanous.rst b/porting/miscellanous.rst
index 0af22b2..be208a4 100644
--- a/porting/miscellanous.rst
+++ b/porting/miscellanous.rst
@@ -10,7 +10,7 @@ The ``_CPU_Fatal_halt`` routine is the default fatal error handler. This
 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
+.. code-block:: c
 
     void _CPU_Fatal_halt(
     unsigned32 _error
@@ -23,7 +23,7 @@ The test case ``sptests/spcontext01`` ensures that the context switching and
 interrupt processing works.  This test uses two support functions provided by
 the CPU port.  These two functions are only used for this test and have no
 other purpose.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_volatile_clobber( uintptr_t pattern );
     void _CPU_Context_validate( uintptr_t pattern );
@@ -72,7 +72,7 @@ set to specify the endian
 format used by this microprocessor.  These macros should not be set to the
 same value.  The following example illustrates how these macros should be
 set on a processor family that is big endian.
-.. code:: c
+.. code-block:: c
 
     #define CPU_BIG_ENDIAN                           TRUE
     #define CPU_LITTLE_ENDIAN                        FALSE
@@ -82,7 +82,7 @@ stack space above the minimum thread stack space required by the MPCI
 Receive Server Thread.  This macro is needed because in a multiprocessor
 system the MPCI Receive Server Thread must be able to process all
 directives.
-.. code:: c
+.. code-block:: c
 
     #define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
 
@@ -108,7 +108,7 @@ 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
 integer into four byte-wide quantities and reassemblying them.
-.. code:: c
+.. code-block:: c
 
     static inline unsigned int CPU_swap_u32(
     unsigned int value
@@ -133,7 +133,7 @@ family of routines.
 Most microprocessor families have rotate instructions which can be used to
 greatly improve the ``CPU_swap_u32`` routine.  The most common
 way to do this is to:
-.. code:: c
+.. code-block:: c
 
     swap least significant two bytes with 16-bit rotate
     swap upper and lower 16-bits
@@ -150,7 +150,7 @@ 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
 should provide a better implementation if possible.
-.. code:: c
+.. code-block:: c
 
     #define CPU_swap_u16( value ) \\
     (((value&0xff) << 8) | ((value >> 8)&0xff))
diff --git a/porting/priority_bitmap.rst b/porting/priority_bitmap.rst
index 4ce89cb..0a9a3f0 100644
--- a/porting/priority_bitmap.rst
+++ b/porting/priority_bitmap.rst
@@ -54,7 +54,7 @@ Find First Bit Routine
 
 The _CPU_Bitfield_Find_first_bit routine sets _output to the bit number of
 the first bit set in ``_value``.  ``_value`` is of CPU dependent type``Priority_bit_map_Control``.  A stub version of this routine is as follows:
-.. code:: c
+.. code-block:: c
 
     #define _CPU_Bitfield_Find_first_bit( _value, _output ) \
     { \
@@ -100,7 +100,7 @@ in software:
 
 - 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:
 
-  .. code:: c
+  .. code-block:: c
 
       _number = 0 if _value > 0x00ff
       _value >>=8
@@ -116,7 +116,7 @@ This can be used temporarily during the porting process to avoid writing
 these routines until the end.  This results in a functional although lower
 performance port.  This is perfectly acceptable during development and
 testing phases.
-.. code:: c
+.. code-block:: c
 
     #define CPU_USE_GENERIC_BITFIELD_CODE TRUE
     #define CPU_USE_GENERIC_BITFIELD_DATA TRUE
@@ -126,7 +126,7 @@ written since they dramatically impact the performance of blocking
 operations.  However they may take advantage of instructions which are not
 available on all models in the CPU family.  In this case, one might find
 something like this stub example did:
-.. code:: c
+.. code-block:: c
 
     #if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
     #define _CPU_Bitfield_Find_first_bit( _value, _output ) \
@@ -144,7 +144,7 @@ that routine for more details.
 
 The following is a typical implementation when the
 _CPU_Bitfield_Find_first_bit searches for the most significant bit set:
-.. code:: c
+.. code-block:: c
 
     #if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
     #define _CPU_Priority_Mask( _bit_number ) \\
@@ -169,7 +169,7 @@ would be bit 16 or 17.
 This routine allows that unwieldy form to be converted
 into a normalized form that is easier to process and use
 as an index.
-.. code:: c
+.. code-block:: c
 
     #if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
     #define _CPU_Priority_bits_index( _priority ) \\
diff --git a/porting/task_context.rst b/porting/task_context.rst
index c9cf53a..9b8dec2 100644
--- a/porting/task_context.rst
+++ b/porting/task_context.rst
@@ -23,7 +23,7 @@ should be set to TRUE.  Otherwise, it should be set to FALSE to indicate
 that the stack grows downward toward smaller addresses.
 
 The following illustrates how the CPU_STACK_GROWS_UP macro is set:
-.. code:: c
+.. code-block:: c
 
     #define CPU_STACK_GROWS_UP               TRUE
 
@@ -45,7 +45,7 @@ tend to require larger stacks as do Ada tasks.
 
 The following illustrates setting the minimum stack size to 4 kilobytes
 per task.
-.. code:: c
+.. code-block:: c
 
     #define CPU_STACK_MINIMUM_SIZE          (1024*4)
 
@@ -60,7 +60,7 @@ CPU_ALIGNMENT is strict enough for the stack, then this should be set to
 
 The following illustrates how the CPU_STACK_ALIGNMENT macro should be set
 when there are no special requirements:
-.. code:: c
+.. code-block:: c
 
     #define CPU_STACK_ALIGNMENT        0
 
@@ -88,7 +88,7 @@ interrupt level context structure is discussed in the XXX.
 
 Additionally, if the GNU debugger gdb is to be made aware of RTEMS tasks
 for this CPU, then care should be used in designing the context area.
-.. code:: c
+.. code-block:: c
 
     typedef struct {
     unsigned32 special_interrupt_register;
@@ -118,7 +118,7 @@ entry as for tasks in this case.
 The Context_Control data structure should be defined such that the order
 of elements results in the simplest, most efficient implementation of XXX.
 A typical implementation starts with a definition such as the following:
-.. code:: c
+.. code-block:: c
 
     typedef struct {
     unsigned32 some_integer_register;
@@ -146,7 +146,7 @@ Generally, this involves:
 This routine generally does not set any unnecessary register in the
 context.  The state of the "general data" registers is undefined at task
 start time. The _CPU_Context_initialize routine is prototyped as follows:
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_Initialize(
       Context_Control *_the_context,
@@ -183,7 +183,7 @@ Performing a Context Switch
 
 The _CPU_Context_switch performs a normal non-FP context switch from the
 context of the current executing thread to the context of the heir thread.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_switch(
     Context_Control  *run,
@@ -222,7 +222,7 @@ to make room for this context information before the
 information is written.  Otherwise, an interrupt could
 occur writing over the context data.  The following is
 an example of an *INCORRECT* sequence:
-.. code:: c
+.. code-block:: c
 
     save part of context beyond current top of stack
     interrupt pushes context -- overwriting written context
@@ -236,7 +236,7 @@ The _CPU_Context_restore routine is generally used only to restart the
 currently executing thread (i.e. self) in an efficient manner.  In many
 ports, it can simply be a label in _CPU_Context_switch. It may be
 unnecessary to reload some registers.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_restore(
       Context_Control *new_context
@@ -255,7 +255,7 @@ self conflicts with the stack frame assumptions of restoring a context.
 
 The following is an implementation of _CPU_Context_Restart_self that can
 be used when no special handling is required for this case.
-.. code:: c
+.. code-block:: c
 
     #define _CPU_Context_Restart_self( _the_context ) \
       _CPU_Context_restore( (_the_context) )
@@ -282,7 +282,7 @@ determines whether every POSIX thread has a floating point context.
 
 The following example illustrates how the CPU_HARDWARE_FP (XXX macro name
 is varying) macro is set based on the CPU family dependent macro.
-.. code:: c
+.. code-block:: c
 
     #if ( THIS_CPU_FAMILY_HAS_FPU == 1 ) /* where THIS_CPU_FAMILY */
                                          /* might be M68K */
@@ -333,7 +333,7 @@ port would not have to have this option set to TRUE.
 The following example illustrates how the CPU_ALL_TASKS_ARE_FP is set on
 the PowerPC.  On this CPU family, this macro is set to TRUE if the CPU
 model has hardware floating point.
-.. code:: c
+.. code-block:: c
 
     #if (CPU_HARDWARE_FP == TRUE)
     #define CPU_ALL_TASKS_ARE_FP     TRUE
@@ -382,7 +382,7 @@ task, the FP context will never be saved or restored.
 The following illustrates setting the CPU_USE_DEFERRED_FP_SWITCH macro on
 a processor family such as the M68K or i386 which can use deferred
 floating point context switches.
-.. code:: c
+.. code-block:: c
 
     #define CPU_USE_DEFERRED_FP_SWITCH       TRUE
 
@@ -404,7 +404,7 @@ 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
 information for RTEMS, it is probably not enough for a debugger such as
 gdb.  But that is another problem.
-.. code:: c
+.. code-block:: c
 
     typedef struct {
     double      some_float_register;
@@ -423,7 +423,7 @@ 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
 bytes of the required size in this case.
-.. code:: c
+.. code-block:: c
 
     #define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
 
@@ -436,7 +436,7 @@ This is a common implementation of the _CPU_Context_Fp_start routine which
 is suitable for many processors.  In particular, RISC processors tend to
 use this implementation since the floating point context is saved as a
 sequence of store operations.
-.. code:: c
+.. code-block:: c
 
     #define _CPU_Context_Fp_start( _base, _offset ) \
       ( (void *) _Addresses_Add_offset( (_base), (_offset) ) )
@@ -445,7 +445,7 @@ In contrast, the m68k treats the floating point context area as a stack
 which grows downward in memory.  Thus the following implementation of
 _CPU_Context_Fp_start is used in that port:
 
-.. code:: c
+.. code-block:: c
 
     XXX insert m68k version here
 
@@ -466,7 +466,7 @@ _CPU_Null_fp_context.  Then all that is required to initialize a floating
 point context is to copy _CPU_Null_fp_context to the destination floating
 point context passed to it.  The following example implementation shows
 how to accomplish this:
-.. code:: c
+.. code-block:: c
 
     #define _CPU_Context_Initialize_fp( _destination ) \
     { \
@@ -475,7 +475,7 @@ how to accomplish this:
     }
 
 The _CPU_Null_fp_context is optional.  A port need only include this variable when it uses the above mechanism to initialize a floating point context.  This is typically done on CPUs where it is difficult to generate an "uninitialized" FP context.  If the port requires this variable, then it is declared as follows:
-.. code:: c
+.. code-block:: c
 
     Context_Control_fp  _CPU_Null_fp_context;
 
@@ -490,7 +490,7 @@ Sometimes a macro implementation of this is in cpu.h which dereferences
 the ** and a similarly named routine in this file is passed something like
 a (Context_Control_fp *).  The general rule on making this decision is to
 avoid writing assembly language.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_save_fp(
       void **fp_context_ptr
@@ -507,7 +507,7 @@ Sometimes a macro implementation of this is in cpu.h which dereferences
 the ** and a similarly named routine in this file is passed something like
 a (Context_Control_fp *).  The general rule on making this decision is to
 avoid writing assembly language.
-.. code:: c
+.. code-block:: c
 
     void _CPU_Context_restore_fp(
     void **fp_context_ptr