FP contexts

[Joel Sherrill]

Till Straumann wrote:
> Leon Pollak wrote:
>   
>> Hello, all.
>>
>> A small question:
>>
>> I have VERY small amount of FP calculations (which occur also rare) in my
>> application.
>>
>> Is it safe not to create tasks with FP attribute, but to surround FP
>> calculations with disable/enable interrupts?
>>
>>     
> If you only have one single task that uses the FPU
> then you're OK without disabling/enabling interrupts.
>
> If there is at least one other, FP-enabled task then
> disabling/enabling interrupts may still result in corruption
> (if your target does lazy FP-context switching).
>
> In general, I consider this very bad practice. IMO, FP-disabled
> tasks should execute with the FPU hardware disabled.
> So should exception handlers and ISRs (unless they save-restore
> FP regs).
>   
>   
I can't swear that every architecture RTEMS has been
ported to implements this but I know it is a design
goal and should be true on at least the PowerPC and
SPARC.  It is much better to have the FPU disabled
when it is not supposed to be used.
> Here's one lesson I learned:
>
> I have seen gcc versions which would silently/implicitly
> use the FPU so that making all tasks FP tasks was the only
> solution. With this gcc version (don't remember which one it
> was) I occasionally had problems with gcc implicitly generating
> FP code in ISRs. Only my paranoia (I have the FPU *only* enabled
> when FP tasks execute, disabled during exceptions, non-FP tasks
> etc.) saved me (I got a trap/exception instead of mysterious
> corruption and could then figure out a work-around)...
>
>   
The old case we always saw was printf declaring a FP
local variable.  Even if you never printed a FP number,
on some architectures, the presence of that declaration
was enough to use the FP. 

The first time I saw GCC use FP instructions for integer
operations was on the HP PA-RISC where FP multiply
was preferred over integer multiply for array indexing!!
This was in the 1993-4 time frame.
> FWIW
> -- Till
>   
>> Thanks ahead.
>>
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985