RTEMS  5.0.0
Data Structures | Macros | Typedefs | Functions
cpu.h File Reference

V850 CPU Department Source. More...

#include <rtems/score/basedefs.h>
#include <rtems/score/v850.h>

Go to the source code of this file.

Data Structures

struct  Context_Control
 Thread register context. More...
 
struct  Context_Control_fp
 SPARC basic context. More...
 
struct  CPU_Interrupt_frame
 Interrupt stack frame (ISF). More...
 

Macros

#define CPU_SIMPLE_VECTORED_INTERRUPTS   FALSE
 
#define CPU_HARDWARE_FP   FALSE
 
#define CPU_SOFTWARE_FP   FALSE
 
#define CPU_ALL_TASKS_ARE_FP   FALSE
 
#define CPU_IDLE_TASK_IS_FP   FALSE
 
#define CPU_USE_DEFERRED_FP_SWITCH   TRUE
 
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH   FALSE
 
#define CPU_STACK_GROWS_UP   FALSE
 
#define CPU_CACHE_LINE_BYTES   32
 
#define CPU_STRUCTURE_ALIGNMENT
 
#define CPU_MODES_INTERRUPT_MASK   0x00000001
 
#define CPU_MAXIMUM_PROCESSORS   32
 
#define _CPU_Context_Get_SP(_context)   (_context)->r3_stack_pointer
 
#define CPU_CONTEXT_FP_SIZE   0
 
#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK   0
 
#define CPU_PROVIDES_ISR_IS_IN_PROGRESS   FALSE
 
#define CPU_STACK_MINIMUM_SIZE   (1024*4)
 
#define CPU_SIZEOF_POINTER   4
 
#define CPU_ALIGNMENT   8
 
#define CPU_HEAP_ALIGNMENT   CPU_ALIGNMENT
 
#define CPU_STACK_ALIGNMENT   4
 
#define CPU_INTERRUPT_STACK_ALIGNMENT   CPU_CACHE_LINE_BYTES
 
#define _CPU_ISR_Disable(_isr_cookie)
 
#define _CPU_ISR_Enable(_isr_cookie)
 
#define _CPU_ISR_Flash(_isr_cookie)
 
#define _CPU_ISR_Set_level(new_level)
 
#define _CPU_Context_Restart_self(_the_context)   _CPU_Context_restore( (_the_context) );
 
#define _CPU_Fatal_halt(_source, _error)
 
#define CPU_USE_GENERIC_BITFIELD_CODE   TRUE
 

Typedefs

typedef CPU_Interrupt_frame CPU_Exception_frame
 
typedef uint32_t CPU_Counter_ticks
 
typedef uintptr_t CPU_Uint32ptr
 

Functions

RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled (uint32_t level)
 Returns true if interrupts are enabled in the specified ISR level, otherwise returns false. More...
 
uint32_t _CPU_ISR_Get_level (void)
 Returns the interrupt level of the executing thread. 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)
 
void _CPU_Initialize (void)
 CPU initialize. This routine performs CPU dependent initialization. More...
 
void * _CPU_Thread_Idle_body (uintptr_t ignored)
 
void _CPU_Context_switch (Context_Control *run, Context_Control *heir)
 CPU switch context. More...
 
void _CPU_Context_restore (Context_Control *new_context) RTEMS_NO_RETURN
 SPARC specific context restore. More...
 
void _CPU_Exception_frame_print (const CPU_Exception_frame *frame)
 Prints the exception frame via printk(). More...
 
uint32_t _CPU_Counter_frequency (void)
 Returns the current CPU counter frequency in Hz. 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 
)
Value:
do { \
__asm__ __volatile__ ( "di" ); \
__asm__ __volatile__ ( "mov %0, r10; " : "=r" ((_error)) ); \
__asm__ __volatile__ ( "halt" ); \
} while (0)

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_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_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_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_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.

Typedef Documentation

◆ CPU_Uint32ptr

typedef uintptr_t CPU_Uint32ptr

Type that can store a 32-bit integer or a pointer.

Function Documentation

◆ _CPU_Context_Initialize()

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. Generally, this involves:

  • setting a starting address
  • preparing the stack
  • preparing the stack and frame pointers
  • setting the proper interrupt level in the context
  • initializing the floating point context
Parameters
[in]the_contextpoints to the context area
[in]stack_baseis the low address of the allocated stack area
[in]sizeis the size of the stack area in bytes
[in]new_levelis the interrupt level for the task
[in]entry_pointis the task's entry point
[in]is_fpis set to TRUE if the task is a floating point task
[in]tls_areais the thread-local storage (TLS) area

NOTE: Implemented as a subroutine for the SPARC port.