Re: [Patch ,gcc/MIPS] add an build-time/runtime option to disable madd.fmt

Re: [Patch ,gcc/MIPS] add an build-time/runtime option to disable madd.fmt

[Maciej W. Rozycki]

On Fri, 23 Dec 2016, Yunqiang Su wrote:

> > 3, kernel: the emulation  when a float exception taken.
> 
> The big problem is that Loongson use the same encode for (unfused) 
> madd.fmt to (fused) madd.fmt. We cannot trap this in kernel.

 Why is that a problem?  Just add a setting like `cpu_has_fused_madd' to 
<asm/cpu-features.h>, switch processing in the emulator accordingly and 
initialise the setting early on in bootstrap as processor features are 
determined.  We'd have to do it likewise for the R8000 MIPS IV CPU Richard 
referred to previously if we had full support for this processor (unlikely 
to happen).

 Cc-ing <linux-mips@linux-mips.org> in case you want to discuss it further 
with the kernel developers; arguably it's a kernel bug already that the 
FPU as perceived by user software has different semantics on FPU Loongson 
hardware depending on whether or not the `nofpu' kernel parameter has been 
set (I don't know if denormals are handled by Loongson FPU hardware or 
trap with an Unimplemented Operation exception, but if the former, then 
this inconsistency applies for such data in the regular FPU mode as well).

 HTH,

  Maciej

Re: [Patch ,gcc/MIPS] add an build-time/runtime option to disable madd.fmt

[Maciej W. Rozycki]

On Fri, 23 Dec 2016, Yunqiang Su wrote:

> > 3, kernel: the emulation  when a float exception taken.
> 
> The big problem is that Loongson use the same encode for (unfused) 
> madd.fmt to (fused) madd.fmt. We cannot trap this in kernel.

 Why is that a problem?  Just add a setting like `cpu_has_fused_madd' to 
<asm/cpu-features.h>, switch processing in the emulator accordingly and 
initialise the setting early on in bootstrap as processor features are 
determined.  We'd have to do it likewise for the R8000 MIPS IV CPU Richard 
referred to previously if we had full support for this processor (unlikely 
to happen).

 Cc-ing <linux-mips@linux-mips.org> in case you want to discuss it further 
with the kernel developers; arguably it's a kernel bug already that the 
FPU as perceived by user software has different semantics on FPU Loongson 
hardware depending on whether or not the `nofpu' kernel parameter has been 
set (I don't know if denormals are handled by Loongson FPU hardware or 
trap with an Unimplemented Operation exception, but if the former, then 
this inconsistency applies for such data in the regular FPU mode as well).

 HTH,

  Maciej