Re: vfp_fpscr_handler() from vfp_handler()

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Oct 17, 2017 at 05:12:55PM -0700, Chuck Silvers wrote:
> I looked into this and talked with gimpy about it a while back:
> 
> the reason for this emulation of FPSCR is to provide a way to maintain
> per-thread rounding and exception state for softfloat.  gimpy's plan was
> to use the FPSCR hardfloat instructions in userland to get and set those bits
> even for softfloat, and have the kernel emulate the instructions and store
> the FPSCR bits in the PCB on systems that did not actually have an FPSCR
> register.  the softfloat libc code does not support per-thread
> rounding/exception state currently, there's just process-wide global
> variable.  gimpy also added a hook the softfloat code to allow MD code to
> override the global variable for rounding/exception state (see
> "set_float_rounding_mode") but nothing actually overrides that currently.
> it looks like some groundwork was laid but this plan was never completed.

Also, before calling vfp_fpscr_handler(), vfp_handler() tests ci_vfp_id.
So vfp_fpscr_handler() can't be used for softfloat in this case either.

vfp_fpscr_handler() is called directly as a handler in the !FPU_VFP
case, or if vfp_attach() didn't detect a useable VFP.

So I still can't see the point in calling vfp_fpscr_handler() from
vfp_handler().

Note that I don't suggect to remove vfp_fpscr_handler(), just to
not use it if we have a real VFP.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--