Related articles |
---|
[7 earlier articles] |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) poser@csli.stanford.edu (1990-06-06) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) larus@primost.cs.wisc.edu (1990-06-07) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) tli@%phakt.usc.edu (1990-06-07) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-10) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) cwitty@csli.Stanford.EDU (1990-06-14) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-14) |
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@june.cs.washington.edu (1990-06-15) |
Newsgroups: | comp.compilers |
From: | pardo@june.cs.washington.edu (David Keppel) |
References: | <1990Jun14.032437.5554@esegue.segue.boston.ma.us> |
Date: | Fri, 15 Jun 90 05:17:53 GMT |
Organization: | University of Washington, Computer Science, Seattle |
Keywords: | code, optimize |
I (pardo) wrote:
>>[Some languages are standardize to undefined order of evaluation]
John Levine (the moderator) writes:
>>[More the rule than the exception.]
cwitty@csli.Stanford.EDU (Carl Witty) writes:
>[I belive not true for C; only the ``as if'' rule, e.g., where proven
> not to make a difference. (For example, on many machines, integer
> arithmetic really is commutative and associative.)]
John writes:
>[Of course, I don't know what I was thinking.]
I'll stick by my gnus on this one :-) I'll warn you that I'm not the
ultimate expert on this, but I've had several ``ultimate experts''
convince me...
Consider the following:
a[i] = b[i++];
``Yeah, yeah'', I hear you type, ``that's only one example.'' Ok,
then, consider:
struct fs { struct fs next; } foo;
foo->next = foo = (struct fs *)zork;
Well, the address of `foo->next' can be computed before or after `foo'
is assigned. Or how about
foo = (struct fs *)something_legal;
foo = foo->next = (struct fs *)zork;
`foo' can be assigned before `foo->next' is computed or assigned. The
`as if' rule applies to _types_ in this case. For example
int x;
long y;
y = x = (long)value;
The value assigned to `y' must be what would be assigned AS IF the
value was assigned from `x', but there is no insistance that the
assignment actually proceed in that order:
long y = (long)(int)value;
int x = value;
Still not convinced that this is the rule rather than the exception?
Consider bit shifts by more than the word size, order of evaluation of
expressions in a parameter list, the meaning of modulo by a negative
number, and a number of other things that CAN have well-defined
semantics in C but which DON'T have well-defined semantics in C.
Let the goodflame games begin :-)
;-D on ( Careful definition ) Pardo
--
pardo@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
[C is very picky in areas like associativity, you have to do a+b+c as
(a+b)+c and not a+(b+c) unless you can prove that the latter two are
entirely equivalent in all ways including possible exceptions. That's
pretty restrictive. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.