[PATCH 01/21] score: Remove superfluous FP types/defines
Sebastian Huber
sebastian.huber at embedded-brains.de
Mon Dec 16 14:28:06 UTC 2019
Update #3835.
---
cpukit/score/cpu/arm/include/rtems/score/cpu.h | 6 -
cpukit/score/cpu/bfin/include/rtems/score/cpu.h | 185 +--------------------
.../score/cpu/epiphany/include/rtems/score/cpu.h | 106 +-----------
cpukit/score/cpu/lm32/include/rtems/score/cpu.h | 92 +---------
cpukit/score/cpu/moxie/include/rtems/score/cpu.h | 138 +--------------
cpukit/score/cpu/nios2/include/rtems/score/cpu.h | 2 -
cpukit/score/cpu/or1k/include/rtems/score/cpu.h | 122 +-------------
cpukit/score/cpu/v850/include/rtems/score/cpu.h | 144 +---------------
cpukit/score/cpu/x86_64/include/rtems/score/cpu.h | 31 +---
9 files changed, 33 insertions(+), 793 deletions(-)
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
index a537a4a4b6..b7b48a3ac3 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
@@ -121,8 +121,6 @@
#define CPU_MODES_INTERRUPT_MASK 0x1
-#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
-
#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
@@ -239,10 +237,6 @@ typedef struct {
#endif
} Context_Control;
-typedef struct {
- /* Not supported */
-} Context_Control_fp;
-
static inline void _ARM_Data_memory_barrier( void )
{
#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
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
@@ -289,15 +183,6 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_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
@@ -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 */
diff --git a/cpukit/score/cpu/epiphany/include/rtems/score/cpu.h b/cpukit/score/cpu/epiphany/include/rtems/score/cpu.h
index 6b1b4fbfe8..462ffab040 100644
--- a/cpukit/score/cpu/epiphany/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/epiphany/include/rtems/score/cpu.h
@@ -63,91 +63,15 @@ extern "C" {
#define CPU_ISR_PASSES_FRAME_POINTER TRUE
-/*
- * 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 "epiphany_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.
- *
- * The CPU_SOFTWARE_FP 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.
- *
- * epiphany Specific Information:
- *
- * At this time there are no implementations of Epiphany that are
- * expected to implement floating point.
- */
-
-#define CPU_HARDWARE_FP FALSE
-#define CPU_SOFTWARE_FP FALSE
+#define CPU_HARDWARE_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.
- *
- * If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
- *
- */
+#define CPU_SOFTWARE_FP FALSE
-#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.
- *
- */
+#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.
- *
- */
-
-#define CPU_USE_DEFERRED_FP_SWITCH FALSE
+#define CPU_USE_DEFERRED_FP_SWITCH FALSE
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
@@ -270,25 +194,8 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->r[13]
-typedef struct {
- /** FPU registers are listed here */
- double some_float_register;
-} Context_Control_fp;
-
typedef Context_Control CPU_Interrupt_frame;
-/*
- * 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.
- *
- * epiphany Specific Information:
- *
- */
-
-#define CPU_CONTEXT_FP_SIZE 0
-
/*
* Amount of extra stack (above minimum stack size) required by
* MPCI receive server thread. Remember that in a multiprocessor
@@ -516,9 +423,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 */
diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpu.h b/cpukit/score/cpu/lm32/include/rtems/score/cpu.h
index d00d40505f..13f8f36194 100644
--- a/cpukit/score/cpu/lm32/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/lm32/include/rtems/score/cpu.h
@@ -52,43 +52,9 @@ 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
- */
-#define CPU_HARDWARE_FP FALSE
-#define CPU_SOFTWARE_FP FALSE
+#define CPU_SOFTWARE_FP FALSE
/**
* Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
@@ -293,13 +259,6 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->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 {
-} 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
@@ -355,19 +314,6 @@ extern Context_Control_fp _CPU_Null_fp_context;
/* XXX: if needed, put more variables here */
-/**
- * @addtogroup RTEMSScoreCPUlm32Context
- * 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 )
-
/**
* @addtogroup RTEMSScoreCPUlm32Interrupt
* Amount of extra stack (above minimum stack size) required by
@@ -758,40 +704,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 */
diff --git a/cpukit/score/cpu/moxie/include/rtems/score/cpu.h b/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
index 07b5185f5f..318650ea3f 100644
--- a/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
@@ -52,88 +52,15 @@ extern "C" {
*/
#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
-/*
- * 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 "MOXIE_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.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_HARDWARE_FP FALSE
+#define CPU_HARDWARE_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.
- *
- * If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_ALL_TASKS_ARE_FP FALSE
+#define CPU_SOFTWARE_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.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_IDLE_TASK_IS_FP FALSE
+#define CPU_ALL_TASKS_ARE_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.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_USE_DEFERRED_FP_SWITCH TRUE
+#define CPU_IDLE_TASK_IS_FP FALSE
+
+#define CPU_USE_DEFERRED_FP_SWITCH FALSE
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
@@ -241,34 +168,10 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->sp
-typedef struct {
- double some_float_register[2];
-} Context_Control_fp;
-
typedef struct {
uint32_t special_interrupt_register;
} CPU_Interrupt_frame;
-/*
- * Nothing prevents the porter from declaring more CPU specific variables.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-
-/*
- * 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.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
-
/*
* Amount of extra stack (above minimum stack size) required by
* system initialization thread. Remember that in a multiprocessor
@@ -503,9 +406,6 @@ uint32_t _CPU_ISR_Get_level( void );
#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 */
@@ -580,32 +480,6 @@ void _CPU_Context_restore(
Context_Control *new_context
) RTEMS_NO_RETURN;
-/*
- * _CPU_Context_save_fp
- *
- * This routine saves the floating point context passed to it.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-void _CPU_Context_save_fp(
- Context_Control_fp **fp_context_ptr
-);
-
-/*
- * _CPU_Context_restore_fp
- *
- * This routine restores the floating point context passed to it.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-void _CPU_Context_restore_fp(
- Context_Control_fp **fp_context_ptr
-);
-
/**
* @brief The set of registers that specifies the complete processor state.
*
diff --git a/cpukit/score/cpu/nios2/include/rtems/score/cpu.h b/cpukit/score/cpu/nios2/include/rtems/score/cpu.h
index 0b32b75e09..d98b0c5c35 100644
--- a/cpukit/score/cpu/nios2/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/nios2/include/rtems/score/cpu.h
@@ -43,8 +43,6 @@ extern "C" {
#define CPU_SOFTWARE_FP FALSE
-#define CPU_CONTEXT_FP_SIZE 0
-
#define CPU_ALL_TASKS_ARE_FP FALSE
#define CPU_IDLE_TASK_IS_FP FALSE
diff --git a/cpukit/score/cpu/or1k/include/rtems/score/cpu.h b/cpukit/score/cpu/or1k/include/rtems/score/cpu.h
index 917cb35601..39920bebc3 100644
--- a/cpukit/score/cpu/or1k/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/or1k/include/rtems/score/cpu.h
@@ -50,93 +50,15 @@ extern "C" {
#define CPU_ISR_PASSES_FRAME_POINTER TRUE
-/*
- * 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 "OR1K_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.
- *
- * The CPU_SOFTWARE_FP 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.
- *
- * Or1k Specific Information:
- *
- * At this time there are no implementations of Or1k that are
- * expected to implement floating point. More importantly, the
- * floating point architecture is expected to change significantly
- * before such chips are fabricated.
- */
+#define CPU_HARDWARE_FP FALSE
-#define CPU_HARDWARE_FP FALSE
-#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.
- *
- * If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
- *
- */
+#define CPU_ALL_TASKS_ARE_FP FALSE
-#define CPU_ALL_TASKS_ARE_FP FALSE
+#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.
- *
- */
-
-#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.
- *
- */
-
-#define CPU_USE_DEFERRED_FP_SWITCH TRUE
+#define CPU_USE_DEFERRED_FP_SWITCH TRUE
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
@@ -255,25 +177,8 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->r1
-typedef struct {
- /** FPU registers are listed here */
- double some_float_register;
-} Context_Control_fp;
-
typedef Context_Control CPU_Interrupt_frame;
-/*
- * 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.
- *
- * Or1k Specific Information:
- *
- */
-
-#define CPU_CONTEXT_FP_SIZE 0
-
/*
* Amount of extra stack (above minimum stack size) required by
* MPCI receive server thread. Remember that in a multiprocessor
@@ -508,23 +413,6 @@ void _CPU_Context_Initialize(
#define _CPU_Context_Restart_self( _the_context ) \
_CPU_Context_restore( (_the_context) );
-/*
- * This routine is responsible to initialize the FP context.
- *
- * The FP area pointer is passed by reference 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.
- *
- * This is necessary because some FP units are designed to have
- * their context saved as a stack which grows into lower addresses.
- * Other FP units can be saved by simply moving registers into offsets
- * from the base of the context area. Finally some FP units provide
- * a "dump context" instruction which could fill in from high to low
- * or low to high based on the whim of the CPU designers.
- */
-#define _CPU_Context_Initialize_fp( _fp_area_p ) \
- memset( *( _fp_area_p ), 0, CPU_CONTEXT_FP_SIZE )
-
/* end of Context handler macros */
/* Fatal Error manager macros */
diff --git a/cpukit/score/cpu/v850/include/rtems/score/cpu.h b/cpukit/score/cpu/v850/include/rtems/score/cpu.h
index 0ce838806e..0ab1d68ba7 100644
--- a/cpukit/score/cpu/v850/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/v850/include/rtems/score/cpu.h
@@ -41,126 +41,15 @@ extern "C" {
*/
#define CPU_SIMPLE_VECTORED_INTERRUPTS FALSE
-/**
- * @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 "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.
- */
+#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:
- *
- * 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.
- */
-#define CPU_HARDWARE_FP FALSE
-#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:
- *
- * 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.
- */
-#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:
- *
- * The IDLE thread should not be using the FPU. Leave this off.
- */
-#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:
- *
- * See earlier comments. There is no FPU state to manage.
- */
-#define CPU_USE_DEFERRED_FP_SWITCH TRUE
+#define CPU_USE_DEFERRED_FP_SWITCH FALSE
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
@@ -275,15 +164,6 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->r3_stack_pointer
-/**
- * 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 */
- double some_float_register;
-} 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
@@ -297,20 +177,6 @@ typedef struct {
uint32_t special_interrupt_register;
} CPU_Interrupt_frame;
-/**
- * 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:
- *
- * The v850 does not need a floating point context but this needs to be
- * defined so confdefs.h.
- */
-/* #define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp ) */
-#define CPU_CONTEXT_FP_SIZE 0
-
/** @} */
/**
diff --git a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
index e6fa8b7881..e3da0aa524 100644
--- a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
@@ -45,12 +45,11 @@ extern "C" {
#define CPU_SIMPLE_VECTORED_INTERRUPTS FALSE
#define CPU_ISR_PASSES_FRAME_POINTER FALSE
-// XXX: Enable FPU support
-#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_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 FALSE
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
#define CPU_STACK_GROWS_UP FALSE
@@ -89,17 +88,6 @@ typedef struct {
#define _CPU_Context_Get_SP( _context ) \
(_context)->rsp
-typedef struct {
- /* XXX: MMX, XMM, others?
- *
- * All x87 registers are caller-saved, so callees that make use of the MMX
- * registers may use the faster femms instruction
- */
-
- /** FPU registers are listed here */
- double some_float_register;
-} Context_Control_fp;
-
/*
* Caller-saved registers for interrupt frames
*/
@@ -152,7 +140,6 @@ typedef struct {
);
#endif
-#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
#define CPU_STACK_MINIMUM_SIZE (1024*4)
@@ -295,14 +282,6 @@ void _CPU_Context_restore(
Context_Control *new_context
) RTEMS_NO_RETURN;
-void _CPU_Context_save_fp(
- Context_Control_fp **fp_context_ptr
-);
-
-void _CPU_Context_restore_fp(
- Context_Control_fp **fp_context_ptr
-);
-
typedef struct {
uint32_t processor_state_register;
uint32_t integer_registers [1];
--
2.16.4
More information about the devel
mailing list