> From: Taylor R Campbell <[email protected]> > Date: Wed, 6 Oct 2010 07:15:43 +0000 > > I'd like to make some changes to MIT Scheme to give programs fine- > grained control over the floating-point environment as in IEEE 754.
Cool. Reminds me of set-floating-error-mask! in src/swat/scheme/control-floating-point.scm, except much more... fine-grained? > There are three parts to this: (a) semantics of the floating-point > environment in Scheme, (b) semantics of the floating-point environment > in microcode primitives, and (c) new operations in Scheme. > > (a) Currently, the floating-point environment is thread-global [...] > I think the floating-point environment should be thread-local, [...] > then most uses of CWCC (for switching threads) would have to save > and restore the environment anyway. The "environment" is, in the abstract, a control register whose bits choose whether the machine will produce NaN-like values, OR signal conditions? (That's the flavor I got from SWAT's set-floating-error-mask!.) I expect we all would like to see compiled code run flat out, with float temporaries NOT in the heap, relying implicitly on a Scheme-friendly default environment. Everyone ELSE should pay, including threads that tweak the default, and ESPECIALLY callouts to alien libraries (or even the many non-open-coded primitives?). Yes? Can a Scheme-side cache of the machine configuration avoid much of the cost of thread switching by punting fesetenv() when switching to a thread with the same expectation of the floating-point environment? > (b) C99 forbids calling any library routine in non-default floating- > point environments unless the routine is documented to allow it. > [...] I could make the microcode alternate between the Scheme and > default C floating-point environments [...] Nice! > (c) Here is a summary of the procedures I'd like to add [...] > > Thoughts? (Patch is not yet done, but let me know if you'd like to > see it.) I do not understand the motivation for all the complexity around flo:defer-exceptions! (and thus unmasked raised [pending?] exceptions?, first-class floating-point environments, etc.). SWAT actually only uses set-floating-error-mask! with a mask of 0, presumably disabling the signaling (and enabling the NaNs?). Do you have a usage case in mind for flo:defer-exceptions!? _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
