[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Erik Walthinsen
Subject: Re: [avr-libc-dev] [bugs #12040] sbi in FAQ
Date: Mon, 28 Feb 2005 15:59:37 -0800
User-agent: Debian Thunderbird 1.0 (X11/20050116)

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


   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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]