From: Robert Gush <robert.gush@su...>  20060418 05:15:31

Hi Maarten, Could it not be argued that a bit field is a signed int? Therefore is has the values of 0 and 1. So on promotion it becomes 0x0000 and 0xFFFF ! This would clearly behave as Rod expects. Regards Robert > All we did was decide "bit" must behave the same as "bool". And if you > search you will find many compilers that behave in the same manner. > > (bool)~(true) = (bool)~((int)true) = (bool)~(0x0001) = (bool)0xFFFE= > = 0xFFFE!= 0 = true > > (bool)~(false) =3D (bool)~((int)false) =3D (bool)~(0x0000) =3D (bool)0xFF= > FF =3D > 0xFFFF!=3D0 =3D true > > The result is always true and therefor reduced to setb. > > If you want to see this "fixed" I suggest to file a bug report to the C > standard committee. > > Greetings, > Maarten > > > All, > > > > At the risk of reopening old wounds I have an issue with the current > > implementation of the '~' operation when operating on bit variables. I > > know that this was thrashed about in 2004 with the subject line of 'Bug > > in June 15 snapshot' but I cannot believe that it has not been fix > > correctly yet. > > > > the following code hilites the issue well: > > #include <8051.h> > > > > void main( void ) > > { > > unsigned char i, c; > > > > while( 1 ) > > { > > P0_0 =3D !P0_0; > > P0_1 =3D ~P0_1; > > P0_2 ^=3D 1; > > > > for( i =3D 0; i < 0xff; i++ ) > > { > > for( c =3D 0; c < 0xff; c++ ) > > { > > ; > > } > > } > > } > > } > > > > > > Generates the following assembler code showing only the bit of interest > > 318 ;test.c:9: P0_0 =3D !P0_0; > > 319 ; genNot > > 0005 B2 80 320 cpl _P0_0 > > 321 ;test.c:10: P0_1 =3D ~P0_1; > > 322 ; genAssign > > 0007 D2 81 323 setb _P0_1 > > 324 ;test.c:11: P0_2 ^=3D 1; > > 325 ; genXor > > 0009 B2 82 326 cpl _P0_2 > > > > > > The first logical not resolves to a complement instruction which in the > > case of a single bit is correct. The second bit invert generates a > > setbit instruction maybe in some parallel universe this is correct but > > not in this universe. This is my issue a bitwise invert of the bit > > should generate a complement instruction like not a setbit instruction. > > While the latest version SDCC prints out a warning about integer > > promotion the wrong code this generated. Finally the XOR with 1 also > > generates the correct code as well. > > While I can see a work around here this needs to be fixed as all other > > compilers I have used do not work this way and I was very surprised to > > discover SDCC doing this as well. > > > > > ____ > > _______________________________________________ > Sdccuser mailing list > Sdccuser@... > https://lists.sourceforge.net/lists/listinfo/sdccuser > > > End of Sdccuser Digest > 
From: Maarten Brock <sourceforge.brock@ds...>  20060423 08:11:06

Hello Robert, This is what the C99 standard has to say about it: 6.2.5 2 An object declared as type _Bool is large enough to store the values 0 and 1. 6 ... The type _Bool and the unsigned integer types that correspond to the standard signed integer types are the standard unsigned integer types. ... This is all about _Bool which equals bool when stdbool.h is included. Btw. Bitfields are something completely different as they are reduced length integers inside structs. Greets, Maarten > Hi Maarten, > > Could it not be argued that a bit field is a signed int? > Therefore is has the values of 0 and 1. > So on promotion it becomes 0x0000 and 0xFFFF ! > This would clearly behave as Rod expects. > > Regards > Robert 