vippstar@[EMAIL PROTECTED]
wrote:
>>> I'm working with a microcontroller at the moment that has a single
>>> instruction for clearing a bit in a byte.
>>> I started off with the following line of code:
>>> x &= ~0x8u; /* Clear the 4th bit */
>>> But then I changed it to the following because I thought I might get
>>> more efficient assembler out of it:
>>> x &= 0xF7u; /* Clear the 4th bit */
>>> Suprisingly, the compiler produced more efficient code for the latter,
>>> presumably because it recognises the pattern of " x &= ~y" for
>>> clearing a single bit.
>>> Anyway just thought I'd give an example of someone winding up with
>>> less efficient code when their aim was to make the code more
>>> efficient :-D
>> What the other are saying here is that if size of 'int' on your
platform is
>> greater than 1 byte, then these two pieces of code are not equivalent.
> Actually that's not the case.
> It doesn't matter whether int is 1 byte or more, since int is at least
> 16 bits, the operators are well-defined, et cetera.
Yes and no.
When I'm taking about 'byte' in this case, I'm referring to the minimal
unit of
storage the OP's platform can handle with a single application of its
'BCF'
machine operation. If the size of 'x' is small enough to be processed by a
single 'BCF', then, as the OP said already, the optimizer should have
generated
a 'BCF' in both cases (relying on the OP's assertion that this is more
efficient).
Meanwhile, you must be referring to the C 'byte'. You are right, but I'd
note
that it is pretty safe to assume that the two are the same, especially
taking
into account the fact that the OP already stated that 'x' is actually an
unsigned _8-bit_ value.
If we take into account that lhs operand is in fact an 8-bit value, then
the two
original operations are equivalent and the optimizer's behavior does
indeed
reveal a deficiency.
--
Best regards,
Andrey Tarasevich
|
