[MIT-Scheme-devel] floating-point environment

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> 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!?