Port-arm archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Why sysarch(ARM_VFP_FPSCR) only allows changing the rounding mode?
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. :)
> A little background: I was working on enabling VFP support for Go
> (golang.org) on netbsd/arm. As Go formally requires correct handling of
> subnormal floating point numbers, both Go runtime and Go compiler need
> to clear the flush-to-zero bit of the FPSCR. On most other systems (Linux,
> Darwin), fpscr is writable from the user space, however NetBSD forbids the
> user space from changing that part of the fpscr.
>
> I wonder why we insist on using flush-to-zero mode for VFP? That is
> unfortunate as it means Go programs could only use software floating point
> to be conforming to the language specification.
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.
> 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.
Home |
Main Index |
Thread Index |
Old Index