diff options
Diffstat (limited to 'cpukit/score/cpu/bfin/include/rtems/score/cpu.h')
| -rw-r--r-- | cpukit/score/cpu/bfin/include/rtems/score/cpu.h | 185 |
1 files changed, 5 insertions, 180 deletions
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpu.h b/cpukit/score/cpu/bfin/include/rtems/score/cpu.h index 9307305743..893a3ae359 100644 --- a/cpukit/score/cpu/bfin/include/rtems/score/cpu.h +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpu.h @@ -54,121 +54,15 @@ extern "C" { */ #define CPU_ISR_PASSES_FRAME_POINTER TRUE -/** - * @def CPU_HARDWARE_FP - * - * 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_HARDWARE_FP FALSE -/** - * @def CPU_SOFTWARE_FP - * - * 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 - */ -#if ( BLACKFIN_CPU_HAS_FPU == 1 ) -#define CPU_HARDWARE_FP TRUE -#else -#define CPU_HARDWARE_FP FALSE -#endif -#define CPU_SOFTWARE_FP FALSE +#define CPU_SOFTWARE_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 @ref CPU_HARDWARE_FP is FALSE, then this should be FALSE as well. - * - * Port Specific Information: - * - * XXX document implementation including references if appropriate - */ -#define CPU_ALL_TASKS_ARE_FP FALSE +#define CPU_ALL_TASKS_ARE_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_IDLE_TASK_IS_FP FALSE +#define CPU_IDLE_TASK_IS_FP FALSE -/** - * 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 - */ -#define CPU_USE_DEFERRED_FP_SWITCH TRUE +#define CPU_USE_DEFERRED_FP_SWITCH FALSE #define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE @@ -290,15 +184,6 @@ typedef struct { (_context)->register_sp /** - * This defines the complete set of floating point registers that must - * be saved during any context switch from one thread to another. - */ -typedef struct { - /* FPU registers are listed here */ - /* Blackfin has no Floating Point */ -} Context_Control_fp; - -/** * This defines the set of integer and processor state registers that must * be saved during an interrupt. This set does not include any which are * in @ref Context_Control. @@ -321,29 +206,6 @@ typedef struct { /** @{ **/ /** @} **/ -/* - * Nothing prevents the porter from declaring more CPU specific variables. - * - * Port Specific Information: - * - * XXX document implementation including references if appropriate - */ - -/* XXX: if needed, put more variables here */ - -/** - * @addtogroup RTEMSScoreCPUBfinCPUContext - * The size of the floating point context area. On some CPUs this - * will not be a "sizeof" because the format of the floating point - * area is not defined -- only the size is. This is usually on - * CPUs with a "floating point save context" instruction. - * - * Port Specific Information: - * - * XXX document implementation including references if appropriate - */ -#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp ) - #endif /* ASM */ /** @@ -618,9 +480,6 @@ void _CPU_Context_Initialize( #define _CPU_Context_Restart_self( _the_context ) \ _CPU_Context_restore( (_the_context) ); -#define _CPU_Context_Initialize_fp( _destination ) \ - memset( *( _destination ), 0, CPU_CONTEXT_FP_SIZE ); - /* end of Context handler macros */ /* Fatal Error manager macros */ @@ -714,40 +573,6 @@ void _CPU_Context_restore( Context_Control *new_context ) RTEMS_NO_RETURN; -/** - * This routine saves the floating point context passed to it. - * - * @param[in] fp_context_ptr is a pointer to a pointer to a floating - * point context area - * - * @return on output @a *fp_context_ptr will contain the address that - * should be used with @ref _CPU_Context_restore_fp to restore this context. - * - * Port Specific Information: - * - * XXX document implementation including references if appropriate - */ -void _CPU_Context_save_fp( - Context_Control_fp **fp_context_ptr -); - -/** - * This routine restores the floating point context passed to it. - * - * @param[in] fp_context_ptr is a pointer to a pointer to a floating - * point context area to restore - * - * @return on output @a *fp_context_ptr will contain the address that - * should be used with @ref _CPU_Context_save_fp to save this context. - * - * Port Specific Information: - * - * XXX document implementation including references if appropriate - */ -void _CPU_Context_restore_fp( - Context_Control_fp **fp_context_ptr -); - /** @} */ /* FIXME */ |