How to handle float-point operations
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? - mudongliang
Hello Mudongliang, On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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. thanks, Arun
- mudongliang
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Arun,
On Thu, Jun 25, 2015 at 2:33 PM, Arun KS <getarunks@gmail.com> wrote: Hello Mudongliang,
On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@gmail.com> wrote: Hello Mudongliang,
On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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?
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
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@gmail.com> wrote: Hello Mudongliang,
On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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?
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
Hello Priyaranjan, On Mon, Jul 6, 2015 at 1:13 PM, priyaranjan <priyaranjan45678@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@gmail.com> wrote: Hello Mudongliang,
On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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
Hello Arun, On Wed, Jul 8, 2015 at 1:26 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Priyaranjan,
On Mon, Jul 6, 2015 at 1:13 PM, priyaranjan <priyaranjan45678@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@gmail.com> wrote: Hello Mudongliang,
On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@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
Dear sir: How to check if the device can enter into deep idle mode or sleep mode? Thanks!
participants (5)
-
Arun KS -
jinzhao＠wingtech.com -
Luis de Bethencourt -
priyaranjan -
慕冬亮