How to handle float-point operations

[priyaranjan]

Hello Arun,


On Wed, Jul 8, 2015 at 1:26 PM, Arun KS <getarunks at gmail.com> wrote:
> Hello Priyaranjan,
>
> On Mon, Jul 6, 2015 at 1:13 PM, priyaranjan <priyaranjan45678 at gmail.com> wrote:
>> On Wed, Jul 01, 2015 at 01:58:30PM +0530, priyaranjan wrote:
>>> Hi Arun,
>>>
>>>
>>> >On Thu, Jun 25, 2015 at 2:33 PM, Arun KS <getarunks at gmail.com> wrote:
>>> >Hello Mudongliang,
>>> >
>>> >
>>> > >On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd at gmail.com> wrote:
>>> > >>
>>> > >> I know there are rarely float-point operations! What's the exception?
>>> > > In the linux kernel, how does it handle the float-point operations in
>>> > the >userland?
>>> >
>>> > >>Most of the userspace programs do not use FP instructions. So by
>>> > >>default floating point engine is turned off during a context switch.
>>> > >>When a process executes floating point instruction, an undefined
>>> > >>exception is generated. Exception handler enables the floating point
>>> > >>engine and jump back to the same instruction which caused the
>>> > >>exception so that it will get re executed with FP engine on.
>>> >
>>> > Is this somehow related to the platform in which linux runs? If the FP
>>> > operations are valid, then will that still generate the exception or it
>>> > does a context switch, turns on FP engine and re-executed?
>
> Usually kernel code never uses FP instructions. In case if kernel uses
> FP, it has to save and restore the FP registers.
>
> FP engine is turned off when a process starts to execute. When a
> process encounters FP instruction for the first time, it results in an
> undefined exception(because FP engine is off). Now the control jumps
> into kernel undefined exception handler. Here kernel check the op-code
> which resulted in undefined exception. Why? Because kernel need to
> verify that it is a co processsor instruction or is it really an
> undefined instruction. In the later case, kernel kills the task. In
> the former case, the kernel enables the corresponding co processor(in
> our case FP engine) and jumps back to user space and re-execute the
> same instruction(this time with co processor turned on). From now on
> all the FP instruction will not result in undef exception. Now when
> kernel decides to move this task away from cpu, it saves the FP
> registers in thread_info of that corresponding task and disables the
> FP engine. The explained scenario is for SMP kernel where same task
> can migrate to different cpus. For single cpu systems, FP register
> saving is done in lazy manner.
>
> This is how ARM handles the FP instructions. I think other
> architectures also does it in similar manner.
>
> Thanks,
> Arun
>

Thanks a lot !

Is this explained anywhere? I guess, I need to dig into kernel docs.

>>> >
>>
>>>Hi Priyaranjan,
>>
>>>Your email got mangled. Please don't send HTML attachments in your >emails to
>>>the Linux Kernel mailing lists.
>>
>>>Try again to reply to Arun.
>>
>>>Thanks,
>>>Luis
>>
>> Sent in plain text format