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
>
