M32C CPU Dependent Source. More...
Go to the source code of this file.
Data Structures | |
| 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 | CPU_Interrupt_frame |
| This defines the set of integer and processor state registers that must be saved during an interrupt. More... | |
Macros | |
| #define | RTEMS_USE_16_BIT_OBJECT |
| #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_CONTEXT_FP_SIZE 0 |
| #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 TRUE |
| 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 __attribute__ ((aligned (2))) |
| 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)->sp |
| This macro returns the stack pointer associated with _context. 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. More... | |
| #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 (2048L) |
| Should be large enough to run all RTEMS tests. More... | |
| #define | CPU_SIZEOF_POINTER 2 |
| #define | CPU_ALIGNMENT 2 |
| CPU's worst alignment requirement for data types on a byte boundary. More... | |
| #define | CPU_HEAP_ALIGNMENT 4 |
| 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_ISR_Set_level(_new_level) |
| This routine and _CPU_ISR_Get_level Map the interrupt level in task mode onto the hardware that the CPU actually provides. 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) |
| This routine performs CPU dependent 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_Thread_Idle_body (uintptr_t ignored) |
| This routine is the CPU dependent IDLE thread body. 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_Exception_frame_print (const CPU_Exception_frame *frame) |
| Prints the exception frame via printk(). More... | |
| CPU_Counter_ticks | _CPU_Counter_read (void) |
Detailed Description
M32C CPU Dependent Source.
Macro Definition Documentation
◆ _CPU_Context_Initialize_fp
| #define _CPU_Context_Initialize_fp | ( | _destination | ) |
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 | |||
| ) |
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 2 |
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 "M32C_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 4 |
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 TRUE |
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 __attribute__ ((aligned (2))) |
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
