Re: vfp_fpscr_handler() from vfp_handler()

[Chuck Silvers <chuq%chuq.com@localhost>]

On Wed, Oct 18, 2017 at 09:13:39AM +0200, Manuel Bouyer wrote:
> 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().

yea, like I said, some of the pieces of that plan are there,
but it never got to the point of working.


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

sounds fine to me, go for it.

-Chuck