Date: Tue, 12 Oct 2010 23:04:54 -0700 From: [email protected] (Matt Birkholz)
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. The floating-point environment is usually stored in several machine registers. If by `fluid-bound mask' you mean a variable that one can FLUID-LET, we don't have any mechanism for variables to reflect machine registers like that. But if you mean readers and writers for the state which one can use in DYNAMIC-WIND, well, that's what I proposed -- FLO:MASKED-EXCEPTIONS, FLO:SET-MASKED-EXCEPTIONS!, &c., with a thread-local floating-point environment. > It may also be necessary to frob the floating-point environment in > the thread timer interrupt handler. ALL interrupts? All thread timer interrupts. (There are other interrupts, but these are the most frequent.) Most of these eventually switch threads anyway, which would involve changing the floating-point environment. Do you expect the condition system to be too costly, thus deferred exceptions (which can be checked and possibly cleared later) are preferable? The machines and C libraries give us two choices in exceptional situations: trap; or give a well-defined, if undesirable, result (0, NaN, +/-inf) on which further arithmetic can happen, and set the exception flags. The condition system can be used to handle traps; using it to substitute results deep inside a computation is not as straightforward. As for performance costs, I don't know what they will be. That's why I want to implement this, measure the performance, and see how the operations turn out to be used. This is an experiment: I want to better understand IEEE 754 by implementing and using all of it in a practical system such as MIT Scheme. Arthur recently added primitives to convert between integers and the IEEE 754 floating-point values that their bit patterns represent. But these explode if you pass in an integer representing, say, a NaN. To avoid that requires masking or handling the floating-point exception. Since Arthur's primitives will usually involve bignums anyway, perhaps involving the condition system to do this won't be so bad. But if we instead had primitives to read floating-point values from and write them to octet vectors, which could be relatively easily open-coded, I imagine the difference between frobbing the machine's floating-point exception mask versus involving the condition system would be pretty substantial. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
