Hi Dirk,
I don't have any solutions for you to get gcc to favour 'bic' over
'and', but I am intrigued as to why you require one over the other.
My understanding is that the difference between the two instructions is
simply the way in which you specify the bit mask. 'bic' will invert it
for you then AND it, where with 'and' the source bitmask needs to be
inverted. Both instructions take the same number of cycles to execute
and both of your examples are using immediate addressing of the literal,
and absolute addressing of P1OUT. (overflow bit behaviour differs)
Given that you are coding in C and the statement actually says to AND an
inverted literal value with P1OUT, it seems quite reasonable for the
preprocessor to invert the literal then present the compiler with a
straight forward AND, which it obviously uses the 'and.b' instruction for.
I can see that the output is inconsistent between upper and lower
nibbles, but the end result is the same.
Not intending to criticise, just wanting to understand what reasons you
might have, that I've overlooked, for wanting the bic instruction.
Regards,
Ian.
-------- Original Message --------
Subject: Re: [Mspgcc-users] Why do the compiler not use "bitc" for P1OUT
&= ~0x80;
From: Dirk Rapp <[email protected]>
To: [email protected]
Date: 26/08/2010 5:14 PM
Hi Dan,
Thanks for your fast response.
sorry, I forgot two things:
1. the compiler version is 3.2.3
2. it was -O0
I tried it now with -O2 and I got the same version like with
"P1OUT&= (uint8_t)~0x80;
--> and.b #127,&0x0021
Any other ideas?
Regards,
Dirk
Am 26.08.2010 08:47, schrieb Dan Bloomquist:
Dirk Rapp wrote:
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?
You didn't say what -Ox you where using. But if -O0, I would expect the
compiler to take the longest route possible. Longer than anyone doing
assembly would think. But this works great for debugging.
Is that the case?
Best, Dan.
------------------------------------------------------------------------------
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
