Intel M32R CPU Dependent Source. More...

#include <rtems/score/types.h>
#include <rtems/score/m32r.h>

Include dependency graph for cpu.h:

This graph shows which files directly or indirectly include this file:

Data Structures
struct	CPU_Per_CPU_control
	The CPU specific per-CPU control. More...

struct	Context_Control
	This defines the minimal set of integer and processor state registers that must be saved during a voluntary context switch from one thread to another. More...

struct	Context_Control_fp
	This defines the complete set of floating point registers that must be saved during any context switch from one thread to another. More...

struct	CPU_Interrupt_frame
	This defines the set of integer and processor state registers that must be saved during an interrupt. More...

Macros
#define	CPU_INLINE_ENABLE_DISPATCH FALSE
	Should the calls to _Thread_Enable_dispatch be inlined? More...

#define	CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
	Does RTEMS manage a dedicated interrupt stack in software? More...

#define	CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
	Does the CPU follow the simple vectored interrupt model? More...

#define	CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE
	Does this CPU have hardware support for a dedicated interrupt stack? More...

#define	CPU_ALLOCATE_INTERRUPT_STACK TRUE
	Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager? More...

#define	CPU_ISR_PASSES_FRAME_POINTER 0
	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)? More...

#define	CPU_HARDWARE_FP FALSE
	Does the CPU have hardware floating point? More...

#define	CPU_SOFTWARE_FP FALSE
	Does the CPU have no hardware floating point and GCC provides a software floating point implementation which must be context switched? More...

#define	CPU_ALL_TASKS_ARE_FP TRUE
	Are all tasks RTEMS_FLOATING_POINT tasks implicitly? More...

#define	CPU_IDLE_TASK_IS_FP FALSE
	Should the IDLE task have a floating point context? More...

#define	CPU_USE_DEFERRED_FP_SWITCH TRUE
	Should the saving of the floating point registers be deferred until a context switch is made to another different floating point task? More...

#define	CPU_PROVIDES_IDLE_THREAD_BODY FALSE
	Does this port provide a CPU dependent IDLE task implementation? More...

#define	CPU_STACK_GROWS_UP TRUE
	Does the stack grow up (toward higher addresses) or down (toward lower addresses)? More...

#define	CPU_STRUCTURE_ALIGNMENT
	The following is the variable attribute used to force alignment of critical RTEMS structures. More...

#define	CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE

#define	CPU_BIG_ENDIAN TRUE
	Define what is required to specify how the network to host conversion routines are handled. More...

#define	CPU_LITTLE_ENDIAN FALSE
	Define what is required to specify how the network to host conversion routines are handled. More...

#define	CPU_MODES_INTERRUPT_MASK 0x00000001
	The following defines the number of bits actually used in the interrupt field of the task mode. More...

#define	CPU_PER_CPU_CONTROL_SIZE 0

#define	_CPU_Context_Get_SP(_context) (_context)->r15_sp
	This macro returns the stack pointer associated with _context. More...

#define	CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
	The size of the floating point context area. More...

#define	CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
	Amount of extra stack (above minimum stack size) required by MPCI receive server thread. More...

#define	CPU_INTERRUPT_NUMBER_OF_VECTORS 32
	This defines the number of entries in the _ISR_Vector_table managed by RTEMS. More...

#define	CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
	This defines the highest interrupt vector number for this port.

#define	CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
	This is defined if the port has a special way to report the ISR nesting level. More...

#define	CPU_STACK_MINIMUM_SIZE (1024)
	Should be large enough to run all RTEMS tests. More...

#define	CPU_SIZEOF_POINTER 4

#define	CPU_ALIGNMENT 8
	CPU's worst alignment requirement for data types on a byte boundary. More...

#define	CPU_HEAP_ALIGNMENT CPU_ALIGNMENT
	This number corresponds to the byte alignment requirement for the heap handler. More...

#define	CPU_PARTITION_ALIGNMENT CPU_ALIGNMENT
	This number corresponds to the byte alignment requirement for memory buffers allocated by the partition manager. More...

#define	CPU_STACK_ALIGNMENT 0
	This number corresponds to the byte alignment requirement for the stack. More...

#define	_CPU_Initialize_vectors()
	Support routine to initialize the RTEMS vector table after it is allocated. More...

#define	_CPU_ISR_Disable(_isr_cookie)
	Disable all interrupts for an RTEMS critical section. More...

#define	_CPU_ISR_Enable(_isr_cookie)
	Enable interrupts to the previous level (returned by _CPU_ISR_Disable). More...

#define	_CPU_ISR_Flash(_isr_cookie)
	This temporarily restores the interrupt to _isr_cookie before immediately disabling them again. More...

#define	_CPU_Context_Fp_start(_base, _offset) ( (void *) _Addresses_Add_offset( (_base), (_offset) ) )
	The purpose of this macro is to allow the initial pointer into a floating point context area (used to save the floating point context) to be at an arbitrary place in the floating point context area. More...

#define	_CPU_Context_Initialize_fp(_destination)
	This routine initializes the FP context area passed to it to. More...

#define	_CPU_Fatal_halt(_source, _error)
	This routine copies _error into a known place – typically a stack location or a register, optionally disables interrupts, and halts/stops the CPU. More...

#define	CPU_USE_GENERIC_BITFIELD_CODE TRUE
	This definition is set to TRUE if the port uses the generic bitfield manipulation implementation.

#define	CPU_USE_GENERIC_BITFIELD_DATA TRUE
	This definition is set to TRUE if the port uses the data tables provided by the generic bitfield manipulation implementation. More...

#define	_CPU_Bitfield_Find_first_bit(_value, _output)
	This routine sets _output to the bit number of the first bit set in _value. More...

#define	_CPU_Priority_Mask(_bit_number) ( 1 << (_bit_number) )
	This routine builds the mask which corresponds to the bit fields as searched by _CPU_Bitfield_Find_first_bit. More...

#define	_CPU_Priority_bits_index(_priority) (_priority)
	This routine translates the bit numbers returned by _CPU_Bitfield_Find_first_bit into something suitable for use as a major or minor component of a priority. More...

#define	CPU_swap_u16(value) (((value&0xff) << 8) \| ((value >> 8)&0xff))
	This routine swaps a 16 bir quantity. More...

Typedefs
typedef CPU_Interrupt_frame	CPU_Exception_frame

typedef uint32_t	CPU_Counter_ticks

Functions
uint32_t	_CPU_ISR_Get_level (void)
	Return the current interrupt disable level for this task in the format used by the interrupt level portion of the task mode. More...

void	_CPU_Context_Initialize (Context_Control the_context, uint32_t stack_base, size_t size, uint32_t new_level, void entry_point, bool is_fp, void tls_area)
	Initialize the context to a state suitable for starting a task after a context restore operation. More...

void	_CPU_Context_Restart_self (Context_Control *the_context)
	This routine is responsible for somehow restarting the currently executing task. More...

void	_CPU_Initialize (void)
	CPU initialization. More...

void	_CPU_ISR_install_raw_handler (uint32_t vector, proc_ptr new_handler, proc_ptr *old_handler)
	This routine installs a "raw" interrupt handler directly into the processor's vector table. More...

void	_CPU_ISR_install_vector (uint32_t vector, proc_ptr new_handler, proc_ptr *old_handler)
	This routine installs an interrupt vector. More...

void	_CPU_Install_interrupt_stack (void)
	This routine installs the hardware interrupt stack pointer. More...

void	_CPU_Context_switch (Context_Control run, Context_Control heir)
	This routine switches from the run context to the heir context. More...

void	_CPU_Context_restore (Context_Control *new_context)
	This routine is generally used only to restart self in an efficient manner. More...

void	_CPU_Context_save_fp (Context_Control_fp **fp_context_ptr)
	This routine saves the floating point context passed to it. More...

void	_CPU_Context_restore_fp (Context_Control_fp **fp_context_ptr)
	This routine restores the floating point context passed to it. More...

void	_CPU_Exception_frame_print (const CPU_Exception_frame *frame)
	Prints the exception frame via printk(). More...

CPU_Counter_ticks	_CPU_Counter_read (void)

Variables
SCORE_EXTERN Context_Control_fp	_CPU_Null_fp_context
	This variable is optional. More...

Detailed Description

Intel M32R CPU Dependent Source.

This include file contains information pertaining to the XXX processor.

NOTE: This file is part of a porting template that is intended to be used as the starting point when porting RTEMS to a new CPU family. The following needs to be done when using this as the starting point for a new port:

Anywhere there is an XXX, it should be replaced with information about the CPU family being ported to.
At the end of each comment section, there is a heading which says "Port Specific Information:". When porting to RTEMS, add CPU family specific information in this section

Macro Definition Documentation

◆ _CPU_Context_Initialize_fp

#define _CPU_Context_Initialize_fp ( _destination )

Value:

{ \
   *(*(_destination)) = _CPU_Null_fp_context; \
  }

This routine initializes the FP context area passed to it to.

There are a few standard ways in which to initialize the floating point context. The code included for this macro assumes that this is a CPU in which a "initial" FP context was saved into _CPU_Null_fp_context and it simply copies it to the destination context passed to it.

Other floating point context save/restore models include:

not doing anything, and
putting a "null FP status word" in the correct place in the FP context.

Parameters

[in] _destination is the floating point context area

Port Specific Information:

XXX document implementation including references if appropriate

◆ _CPU_Fatal_halt

#define _CPU_Fatal_halt	(	_source,
		_error
	)

Value:

{ \

}

This routine copies _error into a known place – typically a stack location or a register, optionally disables interrupts, and halts/stops the CPU.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_ALIGNMENT

#define CPU_ALIGNMENT 8

CPU's worst alignment requirement for data types on a byte boundary.

This alignment does not take into account the requirements for the stack.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_ALL_TASKS_ARE_FP

#define CPU_ALL_TASKS_ARE_FP TRUE

Are all tasks RTEMS_FLOATING_POINT tasks implicitly?

If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed. If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.

So far, the only CPUs in which this option has been used are the HP PA-RISC and PowerPC. On the PA-RISC, The HP C compiler and gcc both implicitly used the floating point registers to perform integer multiplies. Similarly, the PowerPC port of gcc has been seen to allocate floating point local variables and touch the FPU even when the flow through a subroutine (like vfprintf()) might not use floating point formats.

If a function which you would not think utilize the FP unit DOES, then one can not easily predict which tasks will use the FP hardware. In this case, this option should be TRUE.

If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_ALLOCATE_INTERRUPT_STACK

#define CPU_ALLOCATE_INTERRUPT_STACK TRUE

Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?

If TRUE, then the memory is allocated during initialization. If FALSE, then the memory is allocated during initialization.

This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_HARDWARE_FP

#define CPU_HARDWARE_FP FALSE

Does the CPU have hardware floating point?

If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported. If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.

If there is a FP coprocessor such as the i387 or mc68881, then the answer is TRUE.

The macro name "M32R_HAS_FPU" should be made CPU specific. It indicates whether or not this CPU model has FP support. For example, it would be possible to have an i386_nofp CPU model which set this to false to indicate that you have an i386 without an i387 and wish to leave floating point support out of RTEMS.

◆ CPU_HAS_HARDWARE_INTERRUPT_STACK

#define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE

Does this CPU have hardware support for a dedicated interrupt stack?

If TRUE, then it must be installed during initialization. If FALSE, then no installation is performed.

If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.

Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is possible that both are FALSE for a particular CPU. Although it is unclear what that would imply about the interrupt processing procedure on that CPU.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_HAS_SOFTWARE_INTERRUPT_STACK

#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE

Does RTEMS manage a dedicated interrupt stack in software?

If TRUE, then a stack is allocated in _ISR_Handler_initialization. If FALSE, nothing is done.

If the CPU supports a dedicated interrupt stack in hardware, then it is generally the responsibility of the BSP to allocate it and set it up.

If the CPU does not support a dedicated interrupt stack, then the porter has two options: (1) execute interrupts on the stack of the interrupted task, and (2) have RTEMS manage a dedicated interrupt stack.

If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.

Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is possible that both are FALSE for a particular CPU. Although it is unclear what that would imply about the interrupt processing procedure on that CPU.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_HEAP_ALIGNMENT

#define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT

This number corresponds to the byte alignment requirement for the heap handler.

This alignment requirement may be stricter than that for the data types alignment specified by CPU_ALIGNMENT. It is common for the heap to follow the same alignment requirement as CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict enough for the heap, then this should be set to CPU_ALIGNMENT.

NOTE: This does not have to be a power of 2 although it should be a multiple of 2 greater than or equal to 2. The requirement to be a multiple of 2 is because the heap uses the least significant field of the front and back flags to indicate that a block is in use or free. So you do not want any odd length blocks really putting length data in that bit.

On byte oriented architectures, CPU_HEAP_ALIGNMENT normally will have to be greater or equal to than CPU_ALIGNMENT to ensure that elements allocated from the heap meet all restrictions.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_IDLE_TASK_IS_FP

#define CPU_IDLE_TASK_IS_FP FALSE

Should the IDLE task have a floating point context?

If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task and it has a floating point context which is switched in and out. If FALSE, then the IDLE task does not have a floating point context.

Setting this to TRUE negatively impacts the time required to preempt the IDLE task from an interrupt because the floating point context must be saved as part of the preemption.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_INLINE_ENABLE_DISPATCH

#define CPU_INLINE_ENABLE_DISPATCH FALSE

Should the calls to _Thread_Enable_dispatch be inlined?

If TRUE, then they are inlined. If FALSE, then a subroutine call is made.

This conditional is an example of the classic trade-off of size versus speed. Inlining the call (TRUE) typically increases the size of RTEMS while speeding up the enabling of dispatching.

NOTE: In general, the _Thread_Dispatch_disable_level will only be 0 or 1 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.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_ISR_PASSES_FRAME_POINTER

#define CPU_ISR_PASSES_FRAME_POINTER 0

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)?

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_PARTITION_ALIGNMENT

#define CPU_PARTITION_ALIGNMENT CPU_ALIGNMENT

This number corresponds to the byte alignment requirement for memory buffers allocated by the partition manager.

This alignment requirement may be stricter than that for the data types alignment specified by CPU_ALIGNMENT. It is common for the partition to follow the same alignment requirement as CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict enough for the partition, then this should be set to CPU_ALIGNMENT.

NOTE: This does not have to be a power of 2. It does have to be greater or equal to than CPU_ALIGNMENT.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_PROVIDES_IDLE_THREAD_BODY

#define CPU_PROVIDES_IDLE_THREAD_BODY FALSE

Does this port provide a CPU dependent IDLE task implementation?

If TRUE, then the routine _CPU_Thread_Idle_body must be provided and is the default IDLE thread body instead of _CPU_Thread_Idle_body.

If FALSE, then use the generic IDLE thread body if the BSP does not provide one.

This is intended to allow for supporting processors which have a low power or idle mode. When the IDLE thread is executed, then the CPU can be powered down.

The order of precedence for selecting the IDLE thread body is:

BSP provided
CPU dependent (if provided)
generic (if no BSP and no CPU dependent)

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_SIMPLE_VECTORED_INTERRUPTS

#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE

Does the CPU follow the simple vectored interrupt model?

If TRUE, then RTEMS allocates the vector table it internally manages. If FALSE, then the BSP is assumed to allocate and manage the vector table

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_SOFTWARE_FP

#define CPU_SOFTWARE_FP FALSE

Does the CPU have no hardware floating point and GCC provides a software floating point implementation which must be context switched?

This feature conditional is used to indicate whether or not there is software implemented floating point that must be context switched. The determination of whether or not this applies is very tool specific and the state saved/restored is also compiler specific.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_STACK_ALIGNMENT

#define CPU_STACK_ALIGNMENT 0

This number corresponds to the byte alignment requirement for the stack.

This alignment requirement may be stricter than that for the data types alignment specified by CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict enough for the stack, then this should be set to 0.

NOTE: This must be a power of 2 either 0 or greater than CPU_ALIGNMENT.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_STACK_GROWS_UP

#define CPU_STACK_GROWS_UP TRUE

Does the stack grow up (toward higher addresses) or down (toward lower addresses)?

If TRUE, then the grows upward. If FALSE, then the grows toward smaller addresses.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_STRUCTURE_ALIGNMENT

#define CPU_STRUCTURE_ALIGNMENT

The following is the variable attribute used to force alignment of critical RTEMS structures.

On some processors it may make sense to have these aligned on tighter boundaries than the minimum requirements of the compiler in order to have as much of the critical data area as possible in a cache line.

The placement of this macro in the declaration of the variables is based on the syntactically requirements of the GNU C "__attribute__" extension. For example with GNU C, use the following to force a structures to a 32 byte boundary.

__attribute__ ((aligned (32)))

NOTE: Currently only the Priority Bit Map table uses this feature. To benefit from using this, the data must be heavily used so it will stay in the cache and used frequently enough in the executive to justify turning this on.

Port Specific Information:

XXX document implementation including references if appropriate

◆ CPU_USE_DEFERRED_FP_SWITCH

#define CPU_USE_DEFERRED_FP_SWITCH TRUE

Should the saving of the floating point registers be deferred until a context switch is made to another different floating point task?

If TRUE, then the floating point context will not be stored until necessary. It will remain in the floating point registers and not disturned until another floating point task is switched to.

If FALSE, then the floating point context is saved when a floating point task is switched out and restored when the next floating point task is restored. The state of the floating point registers between those two operations is not specified.

If the floating point context does NOT have to be saved as part of interrupt dispatching, then it should be safe to set this to TRUE.

Setting this flag to TRUE results in using a different algorithm for deciding when to save and restore the floating point context. The deferred FP switch algorithm minimizes the number of times the FP context is saved and restored. The FP context is not saved until a context switch is made to another, different FP task. Thus in a system with only one FP task, the FP context will never be saved or restored.

Port Specific Information:

XXX document implementation including references if appropriate

Function Documentation

◆ _CPU_Context_Restart_self()

void _CPU_Context_Restart_self ( Context_Control * the_context )

This routine is responsible for somehow restarting the currently executing task.

If you are lucky, then all that is necessary is restoring the context. Otherwise, there will need to be a special assembly routine which does something special in this case. For many ports, simply adding a label to the restore path of _CPU_Context_switch will work. On other ports, it may be possibly to load a few arguments and jump to the restore path. It will not work if restarting self conflicts with the stack frame assumptions of restoring a context.

Port Specific Information:

XXX document implementation including references if appropriate

Data Structures

Macros

Typedefs

Functions

Variables

Detailed Description

Macro Definition Documentation

◆ _CPU_Context_Initialize_fp

◆ _CPU_Fatal_halt

◆ CPU_ALIGNMENT

◆ CPU_ALL_TASKS_ARE_FP

◆ CPU_ALLOCATE_INTERRUPT_STACK

◆ CPU_HARDWARE_FP

◆ CPU_HAS_HARDWARE_INTERRUPT_STACK

◆ CPU_HAS_SOFTWARE_INTERRUPT_STACK

◆ CPU_HEAP_ALIGNMENT

◆ CPU_IDLE_TASK_IS_FP

◆ CPU_INLINE_ENABLE_DISPATCH

◆ CPU_ISR_PASSES_FRAME_POINTER

◆ CPU_PARTITION_ALIGNMENT

◆ CPU_PROVIDES_IDLE_THREAD_BODY

◆ CPU_SIMPLE_VECTORED_INTERRUPTS

◆ CPU_SOFTWARE_FP

◆ CPU_STACK_ALIGNMENT

◆ CPU_STACK_GROWS_UP

◆ CPU_STRUCTURE_ALIGNMENT

◆ CPU_USE_DEFERRED_FP_SWITCH

Function Documentation

◆ _CPU_Context_Restart_self()