Re: [avr-gcc-list] What Happened to the sbi() and cbi() Macros????

[Richard Urwin]

It seems to me that there are two arguments here:

1.
The removal of cbi and sbi breaks existing code.

IMHO this is a bad thing. It forces developers to revisit existing 
functional code and make edits that they would not otherwise have to 
do, and it makes it more difficult to support the same code on multiple 
library versions. Yes, it's easy to fix it in each individual case. 
Yes, the code shouldn't be there in the first place. But every edit is 
a potential bug. Forcing edits over entire code-sets on developers is a 
bad thing, and in an ideal world would be avoided.

However the world is not ideal. Tools-sets change over time and bit-rot 
is a real phenomenon. This sort of thing happens, and this particular 
event is easy enough to cope with.

2.
The removal of cbi and sbi make code more obscure.

I really don't see this. Anyone with any hope of writing efficient C 
code must understand the bit manipulation capabilities of the language. 
Code can be written a lot more succinctly with the C language 
operations than a few random macros. For example:

// LED1 off, LED2 on and toggle LED3
PORTB = ((PORTB & ~LED1) | LED2) ^ LED3; 

The equivalent code with the macros would not be optimised to the same 
extent, since PORTB is volatile, and must be written at each ";"
That could even make certain code buggy:

PORTD |=  clock | data;

is guaranteed to write both bits in a single operation, but

sbi(PORTD, clock);
sbi(PORTD, data);

is guaranteed not to - and will open a race-condition window that will 
take hours of debugging to find. IMO, a novice would find that 
debugging harder and more disheartening than learning the bit 
operations.

Even in mainstream development, bit operations have their frequent uses, 
but they are a major part of what makes C so useful for embedded 
development. There can be no excuse for ignoring them.

-- 
Richard Urwin