Related articles |
---|
Exceptions and dataflow analysis turnidge@cs.wisc.edu (1995-08-04) |
Re: Exceptions and dataflow analysis chase@centerline.com (1995-08-08) |
Re: Exceptions and dataflow analysis jeremy@sw.oz.au (1995-08-15) |
Re: Exceptions and dataflow analysis stt@dsd.camb.inmet.com (1995-08-19) |
Re: Exceptions and dataflow analysis stachour@parka.winternet.com (1995-08-20) |
Re: Exceptions and dataflow analysis ncohen@watson.ibm.com (1995-08-21) |
Re: Exceptions and dataflow analysis anton@mips.complang.tuwien.ac.at (1995-08-23) |
Newsgroups: | comp.compilers |
From: | stachour@parka.winternet.com (Paul D. Stachour) |
Keywords: | dataflow, errors |
Organization: | StarNet Communications, Inc |
References: | 95-08-066 95-08-108 |
Date: | Sun, 20 Aug 1995 06:07:48 GMT |
jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
>chase@centerline.com (David Chase) writes:
>>(*) In this discussion, "exception" is what you get when you say
>>"throw foo", not what you get when you say "max_float*max_float" or
>>"1/0" or "* (int *) -1".
>>(+) In this discussion, "expression" is used in the mathematical or
>>optimizer- writer sense, and not in the vile, disgusting, impure, C++
>>or C sense. "Expressions" have no side-effects.
>What about optimisation in languages where random expressions can throw
>exceptions of the same form as "deliberate" ones (ones caused by "throw")?
>For example, Java will throw a ArrayIndexOutOfBoundsException (phew!)
>at the obvious time. In theory this means that array indexes have
>(or potentially have) side-effects, and therefore a program could notice
>if a compiler reorders the operation with respect to another
>global change (or potential one). The upshot is that to maintain
>precise semantics, a compiler can't do any reordering, hoisting or CSE
>in the presense of otherwise side-effect free operators which can possibly
>throw exceptions.
Right! You are on target. For example, in PL/I, to maintain correct
semantics, the compiler has to "deoptimize" programs, that is, it must
do much less optimization than would otherwise be possible and practical
if exceptions (conditions) did not exist. The was one of the reasons
for the realtively poor performance of PL/I programs compared to, say,
FORTRAN ones. However, I'll still take PL/I programs, where my
assumptions get checked, and thus can write correct programs, to
langauges like FORTRAN and C, where poor code results in incorrect
answers, with silence from the run-time.
>What approach do people take with languages like this?
In the language design, They specify the sematics.
>Is there anything I've missed? How do people handle this?
Yes. You've missed how Ada handles exceptions. Ada handles
the problem by allowing exceptions to propogate only to
controlled places (excpetion handlers), rather than to
arbitrary code. And from said excpetion handler, one can only
proceed by exiting the block/procedures/function/... that the
exception was raised in. By keeping some amount of retry state
in the enclosing block, one can decide whether to re-try (e.g.,
a bad disk-block) or give up. If one consiers languages like
"C" as 0-level with-respect-to-exceptions, and langauges like
PL/I (which preceded C, but the designers of C appeared to take
only a little from the PL/I experience and lots from their B
experience when they designed C) as 1-level, then Ada83
is a 2-level. I do not personally have enough experience with
C++ to give a rating; however, friends who use it regularly
tell me that, when implemented (they say it is not on most
C++ compilers today) it would be a 1-level amount.
Why not check out what Ada can do for you in 1st-class
software engineering? After all, it was designed for
environments that need maximum safety and reliablity,
and have minimum memory and CPU power to do it in.
There is a good online tutorial in:
http://lglwww.epfl.ch/Ada/Tutorials/Lovelace/lovelace.html
and you can download a free compiler from:
ftp://cs.nyu.edu/pub/gnat
or follow this links from my home-page if in/near Minneapolis/St.Paul.
http://www.winternet.com/~stachour
..Paul
--
Paul D. Stachour, Software Engineer and Methodologist
9532 First Avenue South 260-6A-08 3M Center
Bloomington, Minnesota 55420 St. Paul, Minnesota 55144
(612)-884-5977 stachour@winternet.com (612)-733-5217 pdstachour@mmm.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.