Greetings! Raymond Toy <[email protected]> writes:
> On Tue, Aug 21, 2012 at 8:34 AM, Camm Maguire <[email protected]> wrote: > > Raymond Toy <[email protected]> writes: > > > It would be nice if we could get gcl to signal errors for IEEE errors > > like overflow, divide-by-zero, and invalid-operation. I think most > > other lisps have some option to do this. (I personally don't like float > > operations returning NaN since they propagate forever and I never find > > NaN being useful at the end of some long computation.) > > > > Perhaps Camm can give us the magic gcl options to enable these? > > > > Greetings! I've been looking at this. I have a local version with some > support, but have questions about what is truly useful. > > 1) By default, hardware FPE signals are enabled "oneshot", i.e. after > the first occurrence, the enabling command must be reissued to catch the > > I don't think they're oneshot. Once enabled, they will always generate a > trap when the exception occurs, unless your trap handler chooses to > disable the exceptions. I was hoping to abstract this at the C (rather than hardware specific assembler) level. Specifically the feenableexcept call provided in fenv.h. Playing around with this, it does indeed appear to be "oneshot". > > > next. (This is entirely different from the FPE signal catching > mechanism with sigaction, what is meant here is that FPE signals are not > even sent by the kernel by default without some enabling command.) I'm > assuming that at the lisp level, one wants a global variable that keeps > the desired behavior, and have the C level signal handler reenable the > FPE signal as desired when caught automatically. The alternative is to > provide the user with an enabling command that will work once and must > be repeated by the user if so desired. > > 2) Modern kernels appear to have the ability to enable only certain > types of error, and this level of granularity could be passed to the > lisp user, with some complexity. divide-by-zero, overflow, underflow, > inexact, and invalid are all separably trapable. My guess is that a > global enable command is appropriate here. > > I think it's more a function of the chip than the kernel. Look up the x87 > FPU control word and the SSE mxcsr register to see what all the options > are. For gcl, I guess you might have to know if gcc is using SSE or not so > that you can configure either the x87 control word or the sse mxcsr > register appropriately. > See above. Do you see any problem sticking with a C interface? > To be general, I think you'd want the user to be able to set the masks to any > desired (valid) value. > OK > But I think maxima really just needs the overflow, invalid, and > divide-by-zero exceptions enabled, and have lisp deliver the exceptions as > lisp > errors so that a lisp handler can do something with them. > > > 3) The fault address is typically available. It could be reported at > the lisp level, but my guess is that the typical lisp user would not > find that useful, unless a reverse lookup of the function name was > performed. > > It probably doesn't hurt to provide the fault address, but maxima probably > doesn't need that. I, however, find it useful if the offending operands > can be returned. Maxima probably doesn't need that either, though. > sigaction manpage does not appear to indicate that these are available. The function name lookup is possible, but tedious in 2.6.8pre. > If you need more information, I can help with that. > > What would be really cool is if we could get a small snippet of gcl code > (lisp or C) that we can compile today in maxima to enable this. Then we > don't have to wait for a new release of gcl or for all the distros to update > their copy of gcl. > This is almost possible. Alas, implementing this has uncovered a (sigaction) signal resetting bug for FPE in the base code. Take care, > Ray > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
