I'd say it depends on optimisation level and the other code. bic.b x is technically the same as and.b ~x. If x is known at compile time, both instructions are identically. But if ~x (maybe as pure coincidence) is required later down in the code again, using a mov and and instruction is shorter and faster than a bic instruction with immediate operand. This isn't true if the constant generator can be used for the bic operation. BIC.B #8,&x is a 4-byte instruction, as #8 can be derived from the constant generator and does not need two additional bytes for loading the constant. BIC.B #0x80, &x would be a 6 byte instruction and 1 cycle longer, so there is no difference to AND.B #0x7f, &x. And if 0x7f is required in future anyway, putting it into a register saves 2 bytes and a cycle on the long run. This optimisation is less obvious, if you explicitely do a typecast. I think the compiler doesn't 'see' there anymore that it is the same 0x7f value.
Actually using BIC for a C AND operation is an optimization that makes the code less readable (because of the inverted operand, even if this is the 'real' operand and had already been inverted in the source to allow usage of the AND operator where a BIC was intended). So this "optimization" is only used when the operand is available through the constant generator and therefore the BIC command is shorter and faster than a normal AND. If the operand is unkown at compiletime, an XOR operation would be needed to invert the AND value for BIC, and therefore BIC has no advantage anymore over AND. So it's effectively only used when the bits to clear are known at compile-time and only if it are the bits 0..2, which are available as constant generator values. Anythign else or a combination will result in the AND operation as it is written in the C code. JMGross ----- Ursprüngliche Nachricht ----- Von: Dirk Rapp An: [email protected] Gesendet am: 26 Aug 2010 07:58:00 Betreff: [Mspgcc-users] Why do the compiler not use "bitc" for P1OUT &= ~0x80; Hello, I have a little issue with "bitc". If I use "P1OUT &= ~0x08;" I got "bic.b #8, &0x0021" but if I use "P1OUT &= ~0x80;" I got mov.b #127, r15 and.b r15, &0x0021 with "P1OUT &= (uint8_t)~0x80; I got and.b #127, &0x0021 P1OUT &= ~0x40 --> and.b #-65, &0x0021 which is better but not the expected result. It looks like it depends on the value( high nibble doesn't work). - why is it - how I can get the bic (not using inline assembler) Any ideas? regards, Dirk
