[ Home ]
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
[ Home ] [ Recent Changes ] [ About CLiki ] [ Text Formatting ]
Most architectures support, in some sense, IEEE floating point handling. Five kinds of exceptions are defined (OVERFLOW, UNDERFLOW, INVALID, DIVIDE-BY-ZERO, INEXACT), and SBCL should be able to detect which has been thrown by investigating the FPU control word in signal handlers.

However, it starts to get complicated there, because each OS/Architecture combinations seems to have its idiosyncracies. In particular, Linux, on at least the x86 and PPC architectures, zeros out the control word on receiving a signal (the sig^Wmcontext structure passed to the handler has a copy of the previous one), so it needs to be restored in some cases. There are other Floating Point Problems on PPC.

Further, some foreign code doesn't cope with floating point traps enabled; it may be necessary to turn them off for ALIEN/FFI interactions; the SBCL Build process currently depends on the fact that underflow is not trapped (when it creates objects such as LEAST-POSITIVE-SINGLE-FLOAT, which is a denormalized float).

The situation has yet to be investigated on Alpha (Linux and Tru64); SPARC/SunOS does not seem to have the "zero control word" problem, while SPARC/Linux gives a bus error on SIGFPE before this particular problem is encountered.

In the long term, it would be good to have a documented interface to the floating point control; something along the lines of (SET-FLOATING-POINT-MODES) would be OK, but it might be nicer if GET-FLOATING-POINT-MODES were to become a place...

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