Path: utzoo!utgpu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: comp.sys.mips
Subject: Re: compiler bug
Message-ID: <8559@yunexus.UUCP>
Date: 11 Mar 90 01:13:11 GMT
References: <36721@mips.mips.COM> <18302@shamash.cdc.com> <36884@mips.mips.COM>
Organization: York U. Computing Services
Lines: 37

>In article <18302@shamash.cdc.com> dwl@mercury.udev.cdc.com (Daren W Latham)
>writes that the following doesn't compile correctly.
>>#define  PushArg(n)              argStack[argStackP++] = n
>>#define  PopArg()                argStack[--argStackP]
>>
[...]
>>  temp = PopArg() + PopArg();
>> }

  Erk!  That expands to 
	temp = argStack[--argStackP] + argStack[--argStackP];
for which a legal archaic (K&R) interpretation is
	(argStackP -= 2, temp = argStack[argStackP] + argStack[argStackP]);

  In other words, because there are no ";"s in the expression, it's subject
to having the addressing operations either pulled to the front (unusual,
admittedly) or delayed to the end of the expression (common if they're
postfix ++'s). The old rule-of-the-thumb was "anything that doesn't contain
a semicolon can be reordered", and several compilers happily did so, typically
to avoid generating **horrible** sequences for b[a++] that looked like
	load a,R1
	increment R1
	store R1,a
	decrement R1
	load address b,R2
(I'll give you three guesses about who's machine needed this optimization).

  The ANSI interpretation is substantially similar, if stated and reasoned
about quite differently...


--dave
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.