Re: [avr-libc-dev] [bugs #12040] sbi in FAQ

[Erik Walthinsen]

> Should be removed or replaced with "The compiler optimizes '|=' to use
> sbi when appropriate" (does he?)

Just to clarify, no it does not (avr-gcc-3.4.3, as built by rod.info's 
script, aka a very recent stable compiler used by the vast majority of 
people actually making products):

   4:test.c        ****   PORTB |= 0x03;
  67                    .LM2:
  68 0008 88B3                  in r24,56-0x20
  69 000a 8360                  ori r24,lo8(3)
  70 000c 88BB                  out 56-0x20,r24

vs.

   4:test.c        ****   PORTB |= 0x01;
  67                    .LM2:
  68 0008 C09A                  sbi 56-0x20,0
   5:test.c        ****   PORTB |= 0x02;
  70                    .LM3:
  71 000a C19A                  sbi 56-0x20,1

This insistence on people using the least readable form of all possible 
ways of doing bit manipulation because the compiler is really smart 
doesn't seem to have actual grounding.

Let me say this: if the decision were to *replace* the sbi/cbi macros 
with bit_set/bit_clear macros, and provide a full release-cycle overlap 
with significant warnings (having afterthough-style "btw, these are 
deprecated, sucks to be you" warnings in the manual are *not* 
sufficient), no one would be having any problems with this at all.  If 
the *names* of the sbi/cbi macros really were the only reason to remove 
them, then *renaming* them would have been the appropriate action.

Continually telling people that they appear to be too stupid to 
understand C bit operations really *is* arrogant (which is *not* a term 
I use lightly), especially when (as per above) the compiler itself 
appears not to be capable of dealing with an extremely common case properly.

What all this (sbi/cbi and twi.h) appears to boil down to is a complete 
lack of process for actually dealing with major changes to the library. 
 In the case of twi.h, I keep getting told to search (instead of just 
providing a link!) for a thread from more than 2 years ago that 
basically boils down to "um, dunno, let's move this one too, not sure 
why though".  It goes on someone's TODO list, but as far as I can tell 
never actually gets put in the actual TODO file until very shortly 
before 1.2.0.  What everyone except people who've been paying extremely 
close attention to the list fo many year sees is that twi.h silently 
vanishes.

In the sbi/cbi() case, the decision to remove them because people are 
too stupid to understand what they do was made, the word "deprecated" 
was added to the manual, and no further explanations were given. 
Instead of putting a paragraph or two in the manual detailing why the 
macros were supposedly inappropriate, and several different means of 
replacing them (use bit math where appropriate, and **use replacement 
macros bit_set/bit_clear where appropriate**), it was instead decided 
that berating everyone who asked at first why there were marked 
deprecated and later why they were gone was more appropriate and 
time-efficient.

The proper way to manage changes like this is to send out a dedicated 
RFC to the list explaining the proposed change, and let people actually 
comment on it before it happens.  The (commercial!) user base of this 
project is *far* too large to be making changes of this magnitude 
effectively silently.  The use of the bug system appears to be a 
significant step in this direction, but I have yet to see a bug system 
in *any* project used successfully for significant changes like these, 
thus public RFCs are still the best way to do it.

I will say no more on this topic, as people are going to actually read 
this and understand the issues, or just continue to call me an idiot, as 
they wish.

- Omega

BTW, I'll be making another avrdude-stk500v2 release shortly, and Atmel 
is afaict going to send me an stk500 so I can validate the port there, 
and ideally get the parallel and high-voltage serial modes written in.

In case anyone thought I was "just whining".