🚀 go-pugleaf

> In article <673@galbp.UUCP> gbm@galbp.UUCP (Gary McKenney) writes:
> >> In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
> >> >	/* a = b + b + b */
> >> >	a = ((b=1),b) + ((b=2),b) + ((b=3),b)
> >> >
> 
> Lets change the expression from
> 	a = ((b=1),b) + ((b=2),b) + ((b=3),b)
> to
> 	a = ((a1),r1) + ((a2),r2) + ((a3),r3)
> 
> Where a1 stands for assignment (to b) 1 and r1 stands for reference
> (to b) 1.  The following conditions must be meet for proper code:
> a1 before r1
> a2 before r2
> a3 before r3
> 
> That is all of the restrictions imposed by C.  Thus the following is
> correct code:
> 
> a3, a2, a1, r1, r2, r3
> 
> which produces the answer of 3.  I think I can come up with correct
> code which produces an answer anywhere form 3 to 9.
> 
> This same question comes up every few days it seems like.  I do not
> see what is so confusing about it.  The simple law that C imposes no
> restrictions on the ordering of most operators never seems to be
> understood.
> 
> Perry

Finally a sensical response.  In other words, instead of all crying of how
all the compilers do different things under ambiguous K&R guidelines, just
DON'T WRITE THIS TYPE OF CODE.  Face it, since there are compilers in
existence that don't generate code for expressions in exactly the same
order, then engaging in this "creative" programming is NON-PORTABLE.

Expression rearrangement is an extremely valuable tool in optimization.
For instance, consider the following simple example:

   a= (b+c)+d

Assume that b is a memory variable, but that a and c and d are registers,
and furthermore that the processor has a delayed load (not an unreasonable
situation for a RISC).  The generated code would then look like:

   load rb, _b
   add ra, rc, rd	; load completes during this instruction
   add ra, ra, rb

Here we see the value of breaking the user's parentheses in associative/
commutative operator evaluation in order to save one instruction.

In another type of machine with multiple functional units, the possibilities
for expression optimization are endless.  I would not want to castrate the
potential of such machines just so some people could write "clever-looking"
code that is explicitly warned against in the ANSI standard.  And please
stop complaining about a situation that won't, can't, and shouldn't go away.

	Mark Papamarcos
	Valid Logic Systems
	hplabs!ridge!valid!markp