avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Question about gcc preprocessing and port/pin assign


From: wbounce
Subject: RE: [avr-gcc-list] Question about gcc preprocessing and port/pin assignments
Date: Thu, 9 Dec 2004 19:27:09 -0500

I do not know the inner working of gcc but I disagree with your
statement 
"The only thing that the language promises is that all side effects from
the expression are completed before the next statement is executed."

In your example 
a = (b = 3) + 4;
Order of operation requires the following
Assign 3 to b (because of the ())
Return 3 from that
Add 4 
Then assign result (7) to a


C DOES have order of operation and operations on the same level are
supposed to be processed left to right.




-----Original Message-----
Date: Wed, 8 Dec 2004 15:20:58 -0800
From: "Dave Hylands" <address@hidden>
To: "Graham Davies" <address@hidden>,
        address@hidden
Subject: RE: [avr-gcc-list] Question about gcc preprocessing and
port/pin assignments
Message-ID:
<address@hidden
m>
Content-Type: text/plain;
 charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: list
Message: 1

Hi Graham,

> So, your feeling is that declaring SOME_REG volatile does not=20 
> require the compiler to generate a single assignment to it. =20 Hmm.  
> I though that assignments worked by evaluating the=20 expression on 
> the right and then placing the result at the=20 lvalue on the left.  
> Deviations from this would be=20 optimizations that are only 
> permissible if writes to SOME_REG=20 have no side-effects, which is 
> not the case if I declare it=20 volatile. If this is not so, I will 
> have to adjust my=20 understanding of the language.

The fact that assignment causes something to be stored in memory at all,
is technically a "side effect". Assignment is really just a special case
of an expression.

So statements like:
=09
        a = (b = 3) + 4;

are legal. The only thing that the language promises is that all side
effects from the expression are completed before the next statement is
executed.

So, what this says to me, is that it's perfectly reasonable for the
compiler to take an expression like:

        x = 1 + 2 + 3;

and compile it as:

        tmp =3D 1;
        tmp +=3D 2;
        tmp +=3D 3;
        x =3D tmp;

or as:

        x = 1;
        x += 2;
        x += 3;

It's stuff like this that can sometimes make the embedded
programmer/device driver writer go crazy....

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/=20




reply via email to

[Prev in Thread] Current Thread [Next in Thread]