Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!sdcrdcf!psivax!nrcvax!sdd!dc
From: dc@sdd.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and overflow anomolies
Message-ID: <386@sdd.UUCP>
Date: Tue, 14-Apr-87 11:44:38 EST
Article-I.D.: sdd.386
Posted: Tue Apr 14 11:44:38 1987
Date-Received: Sat, 18-Apr-87 01:37:05 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP> <995@wanginst.EDU> <820@xanth.UUCP>
Reply-To: dc@sdd.UUCP (Daniel Corbett)
Distribution: world
Organization: Software Design & Development Corp, Camarillo, CA
Lines: 50
Keywords: C overflow anomolies execution order parentheses

In article <820@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>
>A few times in 26 years of coding, I have found myself working at the limits
>of a data type, and having to rearrange code to assure that overflow or
>underflow did not take place, during a sound, but not robust calculation.
>Where control of execution order was needed, nothing else would do.
>
>A previous poster has noted that a compiler writer who is on an optimization
>spree (not meant to be derogatory, I have a lot of respect for this skill,
>and spent a long bar evening listing to some justifiable bragging by one of
>the practicioners of this bit of arcana) will not respect anything you can
>do to force a certain code order, since s/he feels free to rearrange
>statements, elide temporaries, rearrange loops, rearrange blocks, reduce
>strength  (change your multiplies to adds, for example), and recent
>publications suggest that separate compilation may not be good enough,
>either, to prevent unexpected interactions of two pieces of code which were
>certainly separate in the programmer's mind.
>
>The ANSI C dpANS, I understand, has chosen to overload the unary plus with
>this task.  I have two problems with this.  First it is {counterintuitive,
>ugly,unmathematical} (pick one).  I have noted earlier, that to the user
>coming from a secondary school environment, the unary plus is a no-op, just
>as s/he learned in algebra class.  It really trashes out the appearance of
>an expression containing it (although C is already in the top five, in the
>running for world's ugliest major language) (need I mention that is one of
>the opinions promised above?).  ;-)  Stray operators floating around don't
>look much like the mathematical equations to which the new user is presumably
>accustomed.
>
>Second, this may provide insufficient or inappropriate granularity of
>control against the optimizing compiler.  I may need to control the order
>of execution of a series of statements which the compiler may decide to
>rearrange.  The unary plus doesn't cut it here, but the compiler author
>has promised to look everywhere for optimizations.  How do I stop the code
>from exercising optimization where it is dangerous to the success of the
>program, without turning it off where it is harmless or beneficial?  I
>think the standard should include a better, prettier method of control of
>optimization scope and degree.
>
>Comments?
>

	Why not utilize a #pragma NO_OPTIMIZE & a counter pragma #pragma OPTIMIZE
around code that is to executed as is  Perhaps we can even create various
classes of pragmas for different optimizations:  #pragma NO_OPTIMIZE LOOPS,
#pragma NO_OPTIMIZE_STRENGTH, etc.


											Daniel Corbett
											V.P. Engineering SDD Corp.