Re: semantics of loating point exception handling
From: Kevin Bracey (kevin.bracey_at_tematic.com)
Date: 03/05/04
- Next message: Dan Pop: "Re: Increasing efficiency in C"
- Previous message: Dan Pop: "Re: Freestanding Environment"
- In reply to: juergen perlinger: "Re: semantics of loating point exception handling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 05 Mar 2004 12:48:31 GMT
In message <c27061$8iq$1@papyrus.erlm.siemens.de>
juergen perlinger <juergen.perlinger@ptd.siemens.de> wrote:
> Kevin Bracey wrote:
> > In message <c1kilp$ohr$1@papyrus.erlm.siemens.de>
> > juergen perlinger <juergen.perlinger@ptd.siemens.de> wrote:
> >
> >
> >>Hello out there.
> >>
> > > sometimes I need to have proper control of the floating point
> > > arithmetic of the C(and C++) runtime system, and using the f.p.
> > > exception handling of the C99 standard is quite handy for that purpose.
> > > The only problem when dealing with f.p. exception signals is that there
> > > is (afaik) no specification *when* the f.p. exception is raised, with
> > > one notable exception: 'feraiseexcept(int)' raises the exceptions
> > > passed in the argument mask before it returns.
> >
> >
> > As I read the standard, fetestexcept() is required to accurately report
> > exceptions raised by preceding code, so it must be a synchronising
> > operation.
> >
> Thanks for reply. Seems my wording was not accurate; I'm not a native
> speaker, and the selection of words is important here. What I actually
> tried to express was: Have unmasked execeptions been signalled to the
> CPU and the associated handler been executed?
The C standard doesn't really have much to say about FP exceptions being
trapped; it says that they should be non-trapping by default (if following
Annex F), and offers no functions to control trapping behaviour. There is a
small document about trapping on WG14's site by Fred Tydeman though.
Trapped IEEE exceptions can be a pain. Particularly underflow ones, as
trapped underflow is different from untrapped underflow. For example, does
sin(<some subnormal number>) generate an underflow trap, even if you would
normally use the "loss of accuracy" form? I haven't the foggiest, as the C
standard is written in terms of underflow being in its "untrapped" guise.
Anyway, that's not relevant to you...
> (Some INTEL machines have the annoying property to actually do the
> interrupt on the NEXT f.p. instruction.
So do other architectures, such as the ARM FPA.
> It seems to me that RAISING the exception and EXECUTING the exception
> are different aspects and EXECUTING is not the scope of the standard,
> though the OpenGroup documentation says:
The terminology here is that the "exception" is the overflow, or whatever,
and this is "raised". When the exception is raised, if its trap is disabled,
the cumulative exception flag is set. If its trap is enabled, then the trap
handler is called.
Now, with FP hardware, the exception may have been internally flagged in the
FPU, but not have actually caused any external effect, and it won't until the
next FP instruction occurs (or some other synchronising event happens).
For untrapped exceptions, the distinction doesn't matter, as the only way
of finding out about them is to read the cumulative exception flags, which
is obviously an FP instruction, so you can be sure the flags are up-to-date.
(And if the FP hardware doesn't do this automatically, it will be the
implementor's job to ensure a synchronising instruction is included in
fetestexcept).
For trapped exceptions, the trap handler is liable to not be called until
another FP instruction happens. Because the C standard doesn't consider trap
handlers, it's not totally clear what the "correct" behaviour is.
Section F.8.1 says
This specification does not require support for trap handlers that
maintain information about the order or count of floating-point
exceptions. Therefore, between function calls, floating-point exceptions
need not be precise: the actual order and number of occurrences of
floating point exceptions (> 1) may vary from what the source code
expresses.
So as they go on to say, the compiler may choose to optimise a loop so that
it only raises an exception once. Thus your trap handler may only be called
once, although the implication is that your trap handler should be called
before the next function call. But frankly, I doubt that many implementions
would take the pains to do that, at least by default.
But it would seem to me that the act of calling fetestexcept() would be
sufficient in all real implementations to make sure any pending traps
get sent off to handlers, as whatever synchronisation is done to ensure the
flags are up-to-date should also lead to pending traps being taken.
If you really need precise information on each trap, you will probably need
compiler support via some sort of pragma or command-line switch to add a
synchronising instruction after each FP instruction, unless the FPU has a
"synchronous operation" mode that you can enable. Both of these will
obviously impair performance.
> >The feraiseexcept() function shall attempt to raise the supported
> >floating-point exceptions represented by the argument excepts. The
> >order in which these floating-point exceptions are raised is
> >unspecified. Whether the feraiseexcept() function additionally raises
> >the inexact floating-point exception whenever it raises the overflow
> >or underflow floating-point exception is implementation-defined.
> </quote>
>
> That "the order in which exceptions are raised is undefined" implies in
> my understanding that the exception is actually handled, which in turn
> tells me that the exception must have been signaled to the CPU.
Well, I don't see that this is any different to any other exception; indeed
it says that "the effect is intended to be similar to that of floating-point
exceptions raised by arithmetic operations". For example, my implementation
of feraiseexcept() just calculates "DBL_MAX*2.0" when asked to raise
FE_OVERFLOW. And this is subject to the same pending exception behaviour as
any other FP operation. I think other implementations may do the same, so I
wouldn't be certain that the trap handler will actually be called by the time
feraiseexcept() returns.
-- Kevin Bracey, Principal Software Engineer Tematic Ltd Tel: +44 (0) 1223 503464 182-190 Newmarket Road Fax: +44 (0) 1223 503458 Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
- Next message: Dan Pop: "Re: Increasing efficiency in C"
- Previous message: Dan Pop: "Re: Freestanding Environment"
- In reply to: juergen perlinger: "Re: semantics of loating point exception handling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
