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
