Re: [MIT-Scheme-devel] floating-point environment

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Fri, 8 Oct 2010 03:57:34 +0000
> 
[...]
> Theoretically, exception flags might be more interesting -- they
> might describe the operation that was in progress at the time of the
> exception, they might describe parts of the floating-point
> environment, &c.

I was wondering what all you had in mind.  The floating environment
object looked opaque -- not just a set of flags.  Yet I expect the NaN
option to toss the interesting detail and the trap option to reflect
these details in a signaled condition object.  That does not leave
much but the "enables" in the environment.  A fluid-bound mask might
KISS.

>    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?
> 
> I don't understand your question.

I suppose it makes little sense if the environment includes "deferred
exceptions".

> What I have in mind is for every continuation invocation --
> including those used to switch threads -- to do fesetenv.

I understand you want to perform the complete save/restore
(fegetenv/fesetenv) context switch and see how much it costs.

> It may also be necessary to frob the floating-point environment in
> the thread timer interrupt handler.

ALL interrupts?

> This all may turn out to be prohibitively expensive -- I'll find out
> when I implement and measure it.
> 
> Does this answer your question?

Yes, thank you.  Had I noticed feholdexcept in the fesetenv man page I
might have guessed.  I take it that the motivation is to provide a set
of procedures familiar to the numerical C programmer, which are
implemented by the portable libc functions.

Do you expect the condition system to be too costly, thus deferred
exceptions (which can be checked and possibly cleared later) are
preferable?