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
>
>
>
