How to handle float-point operations

[Arun KS]

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

>> >
>
>>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