Hi,
ANSI-C (C99) says about the assignment operators (6.5.16.4):
The order of evaluation of the operands is unspecified.
This means it's compiler dependent and allowed to change the order e. g. every
day or in random order (i would prefer random order).
This is also true for many other operators.
It's the same with function arguments; the order in which the arguments are
evaluated is not defined; some compiler do it from left to right, some from
right to left and other do optimize it to a case dependent order.
You can by an exemplar of the standard at www.ansi.org. It's an pdf for about
15 $ which can be paied online with a visa card and will be mailed in a few
minutes.
Rolf
mspgcc-users@lists.sourceforge.net schrieb am 16.08.04 14:39:04:
>
> Hi,
>
> First off, I would say that writing "a = b = c" is a bad idea, precisely
> because it is not clear what it means. There are several interpretations,
> some of which might be the same - what the author thinks it means, what the
> reader thinks it means, what the compiler thinks it means, what ANSI C says
> it means, what the reader thinks the author thinks it means, and so on.
>
> To my knowledge, ANSI C says "a = b = c" means "b = c; a = b;", which is
> precisely how mspgcc is interpreting it. Since the registers you are using
> are special registers, and therefore treated as volatile, this means that
> IE2 must be re-read before assigning the value to a. When you use your
> defines, the variables are not volatile, so gcc already knows what value it
> has put into IE2, and can re-use it without reading IE2 - after all, since
> IE2 is now declared not volatile, it must (as far as gcc knows) contain the
> value you wrote to it.
>
> As far as I can see, mspgcc is therefore giving you exactly the code you
> asked for. The correct way to write your code would therefore be:
> IE1 = 0;
> IE2 = 0;
>
>
> David
>
>
> > Hallo,
> >
> > <disclaimer>
> > I don't claim i've found the bug in mspgcc I use, but it seems to me
> > that the behaviour I've found in mspgcc is at least not ANSI C
> > conformant (I don't have access to real ANSI C specification but the
> > information I've found in ANSI by Kernighan & Ritchi confirm my
> > suspicions).
> > </disclaimer>
> >
> > The operator '=' assigns the right side operant, which can be lvalue or
> > not lvalue expression to left side operand which has to be lvalue.
> > But what's the value of the expression (a = b)? According to my
> > knowledge it's not lvalue but value of the b operand assigned.
> > How mspgcc behaves?
> >
> > Consider the little app, compiled for msp430x147 (only -mmcpu=msp430x147
> > for compiler given):
> >
> > int
> > main() {
> > IE1 = IE2 = 0;
> > return 0;
> > }
> >
> > The interesting is the expression IE1 = IE2 = 0;
> >
> > When IE1 and IE2 are defined exactly as in headers for msp430f14x as:
> > sfrb(IE1,0x0000);
> > sfrb(IE2,0x0001);
> > The expression is compiled into (indepenant on level of optimisation)
> > as:
> >
> > mov.b #llo(0), &0x0001 ; 9 *movqi3/3 [length = 2]
> > mov.b &0x0001, r15 ; 10 *movqi3/5 [length = 2]
> > mov.b r15, &0x0000 ; 11 *movqi3/2 [length = 2]
> >
> > It takes 3 words in mem, 11 cycles for execution according to my
> > knowledge.
> >
> > When IE1 and IE2 are defined as:
> > #define IE1 (*(unsigned char*)0x0000)
> > #define IE2 (*(unsigned char*)0x0001)
> > The expression is compiled into (independant on level of optimisation
> > given by -O option)
> > as:
> >
> > mov.b #llo(0), &1 ; 11 *movqi3/3 [length = 2]
> > mov.b #llo(0), &0 ; 12 *movqi3/3 [length = 2]
> >
> > It takes 2 words in mem, 8 cycles for execution.
> >
> > And last but not least: the second output seems to be correct code, the
> > first is not !!!
> > (the second approach has one drawback: It doesn't produce good debug
> > symbols, but one could make simple workaround for it with std library
> > and linker).
> >
> > Consider the situation with:
> > - interrupts (the memory cell content can always be changed in between)
> > - special registers - some bits are read-only or undefined.
> >
> > After execution the expression produces the values:
> > IE2: 0
> > IE1: 1
> > Probably because IE2 has some undefined bits.
> >
> > The mspgcc & C-library version I've tried was gcc-3.2.3 with patches
> > from mspgcc CVS from 30.July.2004.
> > I hope that mspgcc maintainers would have some ideas how to solve it,
> >
> > regards
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
