Re: Why sysarch(ARM_VFP_FPSCR) only allows changing the rounding mode?

["Richard Earnshaw (home)" <richard.earnshaw%buzzard.freeserve.co.uk@localhost>]

On 3 Mar 2014, at 17:02, Matt Thomas <matt%3am-software.com@localhost> wrote:

> 
> On Mar 3, 2014, at 12:54 AM, minux <minux.ma%gmail.com@localhost> wrote:
> 
>> Hi matt,
>> 
>> On Mon, Mar 3, 2014 at 3:46 AM, Matt Thomas 
>> <matt%3am-software.com@localhost> wrote:
>>> On Mar 2, 2014, at 9:31 PM, minux <minux.ma%gmail.com@localhost> wrote:
>>>> I wonder why sysarch(ARM_VFP_FPSCR) only allows changing the rounding
>>>> mode, but not, for example, the flush to zero mode and the default NaN
>>>> mode?
>>>> (http://nxr.netbsd.org/source/xref/src/sys/arch/arm/arm32/sys_machdep.c#arm32_vfp_fpscr)
>>> 
>>> Because I was playing it safe. :)
>> Makes sense.
>>> I just committed a change that should do the right thing if the VFP supports
>>> it.  For instance, on this cortex-a7 the default value for FPSCR is now 0
>>> since it supports NaN propogation and denormals.
>> Great. I haven't checked the source code, but is ARM1176JZF-S used on
>> Raspberry Pi
>> has initial FPSCR of 0?
> 
> Alas no.
> 
> In ARM1176JZF-S processors when Flush-to-Zero and Default_NaN and 
> Round-to-Nearest are all selected in FPSCR, the coprocessor does not require 
> support code. Otherwise floating point support code is required.
> 
> That's how I choose the default.  If someone wants to write and donate that 
> code then I can change it. 
> 
> 
>>>> Lifting the restriction is easy, for example, the attached patch allows the
>>>> DN and FZ bits to be changed via sysarch(ARM_VFP_FPSCR). I don't think 
>>>> there
>>>> is any security implication in allowing this.
>>> Not that easy.  Some VFP don't support NaNs, or non-nearest rounding modes,
>>> or denormals.  Allowing them to used could cause a panic.
>> I see. Thank you for the explanations.
>> 
>> I wonder if it makes the user's life easier to just allow user-space
>> writes to FPSCR
>> and handle the exceptions transparently. Seems easier to use than
>> adding a sysarch
>> call.
> 
> Most cortex don't support VFP exceptions :(
> 

More correctly, they support the cumulative exception bits in the FPSR, but not 
trapping on exceptions.

R.