Hi JMGross,
thank you for the long and very informative explanation.
I had in mind that there was an errata in th 261x with a workaround with
bic/bis but it
was vice versa, using a mov to avoid TAB22 instead of using bis/bic. So
all is ok for me.
Reagrds,
Dirk
Am 26.08.2010 13:08, schrieb JMGross:
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
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Ingenieurbüro Dirk Rapp
Hard-& Softwareentwicklung
Adelhauser Str. 36
79585 Steinen
Tel.: +49 7627 923494
Mobil: +49 173 6686246
