[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: vfp_fpscr_handler() from vfp_handler()
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
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
Main Index |
Thread Index |