V850 CPU Department 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 | 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 TRUE |
| Should the calls to _Thread_Enable_dispatch be inlined? More... | |
| #define | CPU_HAS_SOFTWARE_INTERRUPT_STACK TRUE |
| Does RTEMS manage a dedicated interrupt stack in software? More... | |
| #define | CPU_SIMPLE_VECTORED_INTERRUPTS FALSE |
| Does the CPU follow the simple vectored interrupt model? More... | |
| #define | CPU_HAS_HARDWARE_INTERRUPT_STACK FALSE |
| 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_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 FALSE |
| 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 FALSE |
| 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_INT64_INLINE TRUE |
| The v850 should use 64-bit timestamps and inline them. | |
| #define | CPU_BIG_ENDIAN FALSE |
| Define what is required to specify how the network to host conversion routines are handled. More... | |
| #define | CPU_LITTLE_ENDIAN TRUE |
| 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)->r3_stack_pointer |
| This macro returns the stack pointer associated with _context. More... | |
| #define | CPU_CONTEXT_FP_SIZE 0 |
| 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_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*4) |
| 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 4 |
| This number corresponds to the byte alignment requirement for the stack. 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_Restart_self(_the_context) _CPU_Context_restore( (_the_context) ); |
| This routine is responsible for somehow restarting the currently executing task. 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... | |
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, uint32_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_Initialize (void) |
| CPU initialize. 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) |
| Returns the current CPU counter value. More... | |
Detailed Description
V850 CPU Department Source.
This include file contains information pertaining to the v850 processor.
Macro Definition Documentation
◆ _CPU_Context_Restart_self
| #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:
On the v850, we require a special entry point to restart a task.
◆ _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:
Move the error code into r10, disable interrupts and halt.
◆ 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:
There is no apparent reason why this should be larger than 8.
◆ CPU_ALL_TASKS_ARE_FP
| #define CPU_ALL_TASKS_ARE_FP FALSE |
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:
This should be false until it has been demonstrated that gcc for the v850 generates FPU code when it is unexpected. But even this would not matter since there are no FP specific registers or bits which would be corrupted if an FP operation occurred in an integer only thread.
◆ 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 "V850_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 FALSE |
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:
The v850 does not have support for a hardware interrupt stack.
◆ CPU_HAS_SOFTWARE_INTERRUPT_STACK
| #define CPU_HAS_SOFTWARE_INTERRUPT_STACK TRUE |
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:
The v850 does not have support for a hardware interrupt stack.
◆ 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:
There is no apparent reason why this should be larger than CPU_ALIGNMENT.
◆ 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:
The IDLE thread should not be using the FPU. Leave this off.
◆ CPU_INLINE_ENABLE_DISPATCH
| #define CPU_INLINE_ENABLE_DISPATCH TRUE |
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:
The v850 is a RISC CPU which typically has enough memory to justify the inlining of this method.
◆ 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:
There is no apparent reason why this should be larger than CPU_ALIGNMENT.
◆ 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:
There does not appear to be a reason for the v850 port itself to provide a special idle task.
◆ CPU_SIMPLE_VECTORED_INTERRUPTS
| #define CPU_SIMPLE_VECTORED_INTERRUPTS FALSE |
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:
This port uses the Progammable Interrupt Controller interrupt model.
◆ 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:
Some v850 models do have IEEE hardware floating point support but they do not have any special registers to save or bit(s) which determine if the FPU is enabled. In short, there appears to be nothing related to the floating point operations which impact the RTEMS thread context switch. Thus from an RTEMS perspective, there is really no FPU to manage.
◆ CPU_STACK_ALIGNMENT
| #define CPU_STACK_ALIGNMENT 4 |
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:
The v850 has enough RAM where alignment to 16 may be desirable depending on the cache properties. But this remains to be demonstrated.
◆ CPU_STACK_GROWS_UP
| #define CPU_STACK_GROWS_UP FALSE |
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:
The v850 stack grows from high addresses to low addresses.
◆ 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:
Until proven otherwise, use the compiler default.
◆ 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:
See earlier comments. There is no FPU state to manage.
