FloatPoint in ISR

Manuel Pedro Coutinho manuelpedrocoutinho at hotmail.com
Mon Apr 25 19:26:51 UTC 2005


Thanks to all of you for your collaboration!
For the time being, i'll not use float point... the operation needed is too 
simple and i've already implemented it using long and ints (sorry for your 
trouble). Nevertheless, thanks for your help and I have expectations that 
the "float point operation" will become more and more complex so in the 
future there may be no solution but to enable the FPU.

Thanks for explaning this!
Manuel Coutinho

>From: "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com>
>Reply-To: joel.sherrill at OARcorp.com
>To: Till Straumann <strauman at slac.stanford.edu>
>CC: Manuel Pedro Coutinho <manuelpedrocoutinho at hotmail.com>,  
>rtems-users at rtems.com
>Subject: Re: FloatPoint in ISR
>Date: Mon, 25 Apr 2005 13:41:19 -0500
>
>Till Straumann wrote:
>>Manuel Pedro Coutinho wrote:
>>
>>>
>>>Hello again!
>>>
>>>I'm now in need of float point operations inside an interuption handler 
>>>in the pc386 BSP. I've seen that the initial task has to have float point 
>>>but apparently this isn't enough... All my tasks now have float point 
>>>attributes but the ISR just blocks after performing the first float point 
>>>operation.
>>>
>>>Can float point operations be done inside an ISR? and if so, can anyone 
>>>tell me how to allow this?
>>
>>
>>An ISR is not operating in any task context - therefore it doesn't matter 
>>if tasks are FP enabled.
>>
>>RTEMS has to save the register context before dispatching an ISR and for 
>>sake of performance
>>the FP registers are usually *not* saved. In order to detect illegal FP 
>>usage by ISRs, the FPU
>>should be disabled during execution of ISRs (I'm more familiar with PPC 
>>than with the i386 BSP
>>- a problem with the PPC BSPs I recently discovered was just that the FP 
>>context was not saved
>>but the FPU was not disabled either --> corruption by an ISR was hard to 
>>detect. I suspect the
>>i386 BSP is better in that regard and possibly disables the FPU prior to 
>>dispatching to your ISR.)
>>
>>That said, here's what you have to do if you want to use the FPU from an 
>>ISR:
>>
>>ISR {
>>
>>enable_FPU();
>>save_caller_saved_FP_registers();
>>
>>your_fp_routine();
>>
>>restore_caller_saved_FP_registers();
>>disable_FPU();
>>}
>>
>>Call your 'real' routine as a subroutine from the 'wrapper'
>>so you only have to save/restore the 'caller-saved' FP registers
>>(according to the x86 ABI - don't know by heart) any others are
>>been taken care of by the compiler.
>
>You should be able to use the internal RTEMS FP save/restore
>routines to help out here.
>
>FWIW I have seen the same discussion and similar example code in
>more than one RTOS manual.  It is a relatively common issue.  In general, 
>FP operations are too heavy to allow them for all ISRs
>but for the case where you need the FPU, it becomes your ISRs
>responsibility to be a good citizen.
>
>>HTH
>>
>>-- Till
>>
>>>
>>>
>>>Many Thanks
>>>Manuel Coutinho
>>>
>>>_________________________________________________________________
>>>MSN Busca: fácil, rápido, direto ao ponto.  http://search.msn.com.br
>>>
>>
>>
>>
>
>
>--
>Joel Sherrill, Ph.D.             Director of Research & Development
>joel at OARcorp.com                 On-Line Applications Research
>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>

_________________________________________________________________
MSN Busca: fácil, rápido, direto ao ponto.  http://search.msn.com.br




More information about the users mailing list