Hi, that's right, but does not change the undefined order of evaluation. That's why the result of
a ^= b ^= a; // ^= is an asignment operator. or simply a[i] = i++; is undefined. Therefore gcc produces warnigs at such ugly code ( but not the IAR i have used). Rolf mspgcc-users@lists.sourceforge.net schrieb am 17.08.04 01:01:34: > > The '=' operator in the C language is right associative. That means > x = y = z; means x = (y = z); and not (x = y) = z; > You can also think of the '=' operator being similar to other binary > operators in the C language in that it returns the value of the assignment. > > In the case where 'y' above is a volatile, I don't however know if > the '=' operator returns the value asigned to 'y' or the value 'y' > contains after the assignment. > > See http://encyclozine.com/Associativity for more info, or do a google > on "C language right associative" > > Regards > -Bill Knight > R O SoftWare > > > > On Mon, 16 Aug 2004 22:08:05 +0200, Tadeusz Szczyrba wrote: > > >I wasn't describing the order of evaluation of operands because it's for > >most of the operators with two-or-more operands unspecified (only &&, || > >and ',' and '?:' operators have the order of evaluation specified > >AFAIK). I was talking about value of the expression a = b. > >In fact gcc for i386 has similar approach (checked it with type > >promotion (unsigned int)a = (unsigned char) b = 0x1234 - a is not equal > >0x1234 in the example) but don't know _precisely_ what the specs say. > > >OK - I've learnt for sure it's better not to expect anything concerning > >return value of assignment operand. > > > regards, > > >W li¶cie z pon, 16-08-2004, godz. 21:07, nobo...@web.de pisze: > >> 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 > >> > >> > >> > >> > >> > >> ------------------------------------------------------- > >> 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 > > > > > > ------------------------------------------------------- > 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
