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


Go to the source code of this file.
| #define _CPU_Context_Initialize_fp | ( | _destination | ) |
Value:
{ \
*(*(_destination)) = _CPU_Null_fp_context; \
}
Other floating point context save/restore models include:
| [in] | _destination | is the floating point context area |
XXX document implementation including references if appropriate
| #define _CPU_Context_Restart_self | ( | _the_context | ) | _CPU_Context_restore( (_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
Referenced by _Thread_Restart_self().
| #define _CPU_Fatal_halt | ( | _error | ) |
Value:
{ \
}
Port Specific Information:
XXX document implementation including references if appropriate
| #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. See the discussion for that routine.
Port Specific Information:
XXX document implementation including references if appropriate
| #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
Referenced by _Addresses_Is_aligned().
| #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
| #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
| #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 "NO_CPU_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.
| #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
| #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
| #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.
Port Specific Information:
XXX document implementation including references if appropriate
| #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
| #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.
XXX document implementation including references if appropriate
| #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
| #define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0 |
Amount of extra stack (above minimum stack size) required by MPCI receive server thread. Remember that in a multiprocessor system this thread must exist and be able to process all directives.
Port Specific Information:
XXX document implementation including references if appropriate
| #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.
XXX document implementation including references if appropriate
| #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:
Port Specific Information:
XXX document implementation including references if appropriate
| #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
| #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
| #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.
XXX document implementation including references if appropriate
Referenced by _Stack_Adjust_size().
| #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
| #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)))
XXX document implementation including references if appropriate
| #define CPU_UNROLL_ENQUEUE_PRIORITY TRUE |
Should the body of the search loops in _Thread_queue_Enqueue_priority be unrolled one time? In unrolled each iteration of the loop examines two "nodes" on the chain being searched. Otherwise, only one node is examined per iteration.
If TRUE, then the loops are unrolled. If FALSE, then the loops are not unrolled.
The primary factor in making this decision is the cost of disabling and enabling interrupts (_ISR_Flash) versus the cost of rest of the body of the loop. On some CPUs, the flash is more expensive than one iteration of 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.
Port Specific Information:
XXX document implementation including references if appropriate
| #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
| void _CPU_Initialize | ( | void * | thread_dispatch | ) |
This routine performs CPU dependent initialization.
| [in] | thread_dispatch | is the address of _Thread_Dispatch |
XXX document implementation including references if appropriate
| void* _CPU_Thread_Idle_body | ( | uint32_t | ) |
This routine is the CPU dependent IDLE thread body.
XXX document implementation including references if appropriate
| SCORE_EXTERN Context_Control_fp _CPU_Null_fp_context |
This variable is optional. It is used on CPUs on which it is difficult to generate an "uninitialized" FP context. It is filled in by _CPU_Initialize and copied into the task's FP context area during _CPU_Context_Initialize.
Port Specific Information:
XXX document implementation including references if appropriate
1.5.6