> From: Taylor R Campbell <[email protected]> > 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? _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
