Hello Arun, On Wed, Jul 8, 2015 at 1:26 PM, Arun KS <getarunks@xxxxxxxxx> wrote: > Hello Priyaranjan, > > On Mon, Jul 6, 2015 at 1:13 PM, priyaranjan <priyaranjan45678@xxxxxxxxx> 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@xxxxxxxxx> wrote: >>> >Hello Mudongliang, >>> > >>> > >>> > >On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
