RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

score: Add Thread_Control::is_fp

Browse Source 
Store the floating-point unit property in the thread control block
regardless of the CPU_HARDWARE_FP and CPU_SOFTWARE_FP settings.  Make
sure the floating-point unit is only enabled for the corresponding
multilibs.  This helps targets which have a volatile only floating point
context like SPARC for example.
This commit is contained in:
Sebastian Huber
2015-06-02 21:43:54 +02:00
parent b276507552
commit 335e5caa9a
6 changed files with 17 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
c/src/lib/libcpu/powerpc/new-exceptions/cpu.c
View File

@@ -98,8 +98,6 @@ void _CPU_Context_Initialize(
}
#ifdef PPC_MULTILIB_FPU
msr_value |= MSR_FP;
#else
/*
* The FP bit of the MSR should only be enabled if this is a floating
* point task. Unfortunately, the vfprintf_r routine in newlib
@@ -108,21 +106,7 @@ void _CPU_Context_Initialize(
* of vfprintf.c will be required to avoid this behavior. At this
* time (7 July 1997), this restructuring is not being done.
*/
/* Make sure integer tasks have no FPU access in order to
* catch violations. Gcc may implicitely use the FPU and
* data corruption may happen.
* Since we set the_contex->msr using our current MSR,
* we must make sure MSR_FP is off if (!is_fp)...
* Unfortunately, this means that users of vfprintf_r have to use FP
* tasks or fix vfprintf. Furthermore, users of int-only tasks
* must prevent gcc from using the FPU (currently -msoft-float is the
* only way...)
*/
if ( is_fp )
msr_value |= PPC_MSR_FP;
else
msr_value &= ~PPC_MSR_FP;
msr_value |= MSR_FP;
#endif
#ifdef PPC_MULTILIB_ALTIVEC