From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: thp@cs.ucr.edu (Tom Payne) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: <4kh9on$jm@galaxy.ucr.edu>#1/1 X-Deja-AN: 146796539 references: organization: University of California, Riverside newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: Matt Austern (austern@isolde.mti.sgi.com) wrote: : In article <4kgmgu$jm@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes: : : > The problem shows up in real situations: In C++ AFAIK there is no : > efficient way for an exception at the hardware level to generate an : > exception (in the C++ sense) on the part of the running program -- the : > running must poll a volatile atomic variable to see if the exception : > has occurred. This obviously makes the langauge, as defined in the : > standard, unacceptable for use in the area of, say, embedded systems. : > Even in scientific progrmming, however, one would like to be able to : > throw an exception out of a matrix manipulation routine when the : > underlying hardware detects a floating point exception, and polling : > for such an occurrence would involve unacceptable overhead. : : Are you sure that this is possible on the machines that you'd like : your program to run on? On many of today's RISC chips, after all, : floating point exceptions are asynchronous: you have no way of : knowing which instruction caused the problem. : : (This sounds perverse, but there's a reason for it. If you want : synchronous exceptions, you end up having to stall the pipeline when : you're processing a floating point instruction.) The scientific programming community has bad to put up with imprecise detection of floating point exceptions since the IBM 360/91, or before. I'm not asking that a C/C++ implementation do anything more than pass the information along (via a signal) when it gets it. (That's why I said " ... when the underlying hardware detects a floating point exception ...".) The problem, however, is not the timing of the resulting signal, but what I can (and can't) do within its handler. The handler cannot read global data and, hence, cannot take any kind of corrective action. Also, it cannot throw an exception to unwind the computation back to some known state. Other than aborting the computation, the only option left to a C/C++ signal handler is to set a flag that the program must poll to determine that a floating-point exception has occurred and to take corrective action such as throwing a C++ exception. I don't know Ada, but I doubt that it suffers the same limitation, and I expect that Gnat implements Ada on virtually all machines that run C/C++. (To that extent, I am moderately sure that what I'm asking for is doable.) Tom Payne (thp@cs.ucr.edu)