SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

Most of these issues have been observed on Darwin, but they seem as if they have more to do with the architecture than the OS.

Most of this stuff is from this thread on sbcl-devel, but I can't go back and edit the misunderstandings in the earlier mails :)

The simplest problem is that the contents of the FPU are noise in a new process on Darwin, and thus there tend to be some exception flag bits set which need to be cleared before traps can safely be enabled.

More effort to fix, but still tractable is the Invalid Operation 'bit'. SBCL assumes that each IEEE 754 exception corresponds to a single bit in the floating point control word, and this just isn't true on the PPC for the Invalid Operation exception -- in fact there are five different bits in the FPSCR that each mean a different kind of Invalid Operation. There is a 'summary' bit that's set if any Invalid Operation bit is set, but you cannot affect it directly, only by clearing each particular bit individually.

I guess that asking set-floating-point-modes to clear the :invalid-operation exception should clear all the VX bits, asking it to set the exception should set VXSOFT and asking if an exception is set should test the summary bit.

The really fun part is restoring the processor state when a signal handler (not just the SIGFPE handler, unfortunately) wants to take a non-local exit (via #'cl:error or whatever).

A PowerPC chip takes a floating point exception (say, overflow) if the trap enable bit in the FPSCR is set, the exception bit is set, and either of the floating point exception enable bits in the MSR is set.

As part of the process of taking a Program Exception (which floating point exceptions are a subset of) these (and other) bits of the MSR are cleared (they have to be, because otherwise the exception handler itself wouldn't be able to run!).

Most (all?) Program Exceptions result in a unix style signal handler being called, with exceptions still disabled. If the unix signal handler returns normally, a sigreturn syscall takes care of restoring the processor state (which means in the case of SIGFPE you have to do something to avoid ending up straight back in the handler). If the handler exits via cl:throw or longjmp, though, the processor state is not restored, and subsequent code executes with FP exceptions enabled in the FPSCR and not in the MSR, a more-or-less insane state of affairs.

I'm not at all sure what to do about this. One answer might be 'arrange_return_to_lisp_function', but I don't understand how that works. Another is to clear the bits in the FPSCR that would cause the immediate raising of an exception, restore the MSR and proceed as before. This is made more exciting by the fact that changing the MSR is a supervisor level operation, so we need to get the kernel to do it for us somehow. Aggravatingly, this would have to be done for (almost?) all signal handlers, but that's probably not a big deal.

This page is linked from: Floating Point  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively