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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: jbuck@synopsys.com (Joe Buck) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/24 Message-ID: <5r6a67$p0b@hermes.synopsys.com>#1/1 X-Deja-AN: 258386792 References: <33CD1722.2D24@calfp.co.uk> <33D24C91.C9730CBA@munich.netsurf.de> Organization: Synopsys Inc., Mountain View, CA 94043-4033 Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-24T00:00:00+00:00 List-Id: Robert Dewar wrote: >> The idea that REMOVING the evaluation of boolean expressions >> completely >> is semantically neutral is also completely bogus. Joachim Durchholz writes: >That's a bit strong. In real-time systems, it isn't strong; it has to be taken into account. >> Such removal can affect >> Icache locality of the code that is left, again affecting timing, > >OK. Is an issue for real-time software where code timing is important. >I'm somewhat astonished that such code is still written (the last time I >saw this done was on a C64), but then I'm not in the hard RT field. This statement suggests that your perspective is too narrow. You encounter hard real-time systems every day. Far more processors in the world are running embedded real-time code than are running your favorite PC program. It is exactly these systems that it is most critical to get right; people could die if they fail (anti-lock braking systems, fly-by-wire systems in AirBus planes, industrial robots). No one much cares if your Unix app core dumps. Timing constraints are often quite tight; a telephone-bandwidth speech compression system has to produce one sample every 125 microseconds, all the time, or the user hears a pop. Caches are often of no use, since it is the worst case timing (the cache miss) that counts. If your system has to meet timing even if you take a cache miss, why spend money on the cache? (Instruction caches can still pay because you may be guaranteed that your loop fits in the cache). In practice, these problems are manageable; what matters is the timing of critical paths, not of all paths. But in many cases adding assertion checks will result in a program that does not meet its deadlines, so you need some other means (like a second processor or emulation testbench that observes the processor under test, with assertion checks running on this other processor). >> and can also result in code being at different locations, resulting in >> differences of behavior with unbounded consequences. >Now *that* sounds bogus to me. The code should execute in exactly the >same way, wether assertions are turned on or off. If you don't have >enough confidence in the compiler to generate code that runs correctly, >why do you use a compiler at all? All compilers have bugs, and all responsible software engineers test the object code they are going to ship, not just different object code that has debug code and assertions stuck in. There's a term "Heisenbug", a bug that disappears when you enable debugging because the compiler generates different code when debugging is enabled. -- -- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html Help stamp out Internet spam: see http://spam.abuse.net/spam/