On Fri, Dec 08, 2000 at 02:41:30PM +0100, Peter Van Eynde wrote:
> On Thu, Dec 07, 2000 at 04:14:03PM -0600, William Harold Newman wrote:
> > and also in the new cmucl-18c, where it looks like
> > #if defined(__linux__) && defined(i386)
> > /*
> > * Restore the FPU control word, setting the rounding mode to nearest.
> > */
> > if (contextstruct.fpstate)
> > setfpucw(contextstruct.fpstate->cw & ~0xc00);
> > #endif
> > I'm not quite sure about the side effects of removing it, either. My
> > guess is that as long as there's nothing in SBCL which changes the
> > floating point mode, removing it is quite safe. However, it's possible
> I wouldn't. It seems the code in 2.4.20+ is stable. The root cause seems
> to be that sometimes the kernel doesn't fill in the FPU control word...
> Restoring this is needed because it's not SBCL that changes it: it's the
> kernel that resets the FPU and returns it to its default state, which is
> not the state in which SBCL starts up IIRC.
If we do need to do control word hacking on entry to
handle_interrupt_now and maybe_now_maybe_later, it sounds from your
explanation as though it might be cleanest to define a function
os_vm_low_level_init_or_reinit(), and call that in three places: in
handle_interrupt_now, in maybe_now_maybe_later, and at system startup.
Then on Linux/i386 that function could be defined to put the FPU into
a standard state (rounding to nearest, etc.), without reference to
anything in the signal context.
However, I'm not going to try to do this now. MNA's fix (deleting the
Linux-only FPU-state-setting code) makes all known problems go away.
The cmucl-18c code doesn't translate directly to POSIX signals, as far
as I can see, since in the POSIX signal context there's no fpstate
pointer to test, so using cmucl-18c-ish code instead isn't a good
option. And the old cmucl-2.4.8-based code, which unconditionally sets
the floating point control word from the state in the interrupt
context, causes POSIX SIGINT handling to be horribly unreliable, so
that's not a good option either.
There might be new problems, but I don't know how to find them. I
don't even know whether the weird FPU behavior exists in the POSIX
signal handling implementation; it might be an idiosyncrasy of the
Linux implementation of old-style BSD-ish signal handling only. And
when I asked on cmucl-imp@... about the motivation for the
cmucl-18c code, DTC didn't tell me a good way to exercise the problem.
I poked around a little trying to cause problems: hitting Ctrl-C, and
doing floating point operations that raise exceptions. I didn't happen
to notice any problems, and without more explanation from someone who
understands the reason for the 18c code, it's hard for me to search
for problems systematically, so for now I'm just going to wait and see.
> Actually the fact that the kernel loses the cw is strange, that
> sometimes it doesn't even manage to save it is beyond me.
Yes, I certainly don't understand losing the control word. I thought
the point in any context save was to save stuff like that. And
evidently all the *BSD implementors think so too.. I have no clue what
the Linux people think they're doing here, whether it's documented
anywhere, or they consider it a bug, or what.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C