[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