Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.]

[Joerg Wunsch]

As Dmitry K. wrote:

> > . sbi(), cbi()

> In old library these expressions were realized through the asm() containing 
> the appropriate commands (for a lower half of ports). Definitions as
> "REG |= _BV(BIT)" do not give atomic operations by the switched off 
> optimization: it is checked up.

Sure.  Don't turn off optimization for any real-life project.  That's
basically a #1 rule for /any/ RISC CPU, and the AVR core is a bit like
RISC in this respect as well (i. e., the compiler has a lot chances to
optimize the code).

The original inline asm has been dropped once the new SFR macros were
in place.  Basically, it's now no longer (easily) possible to use one
of the SFRs as the target of an inline asm statement anyway (see bug
ID #2233, we need to update our inline asm docs accordingly).  So
since then, the sbi() and cbi() macros have been nothing else but what
we are promoting now.  On the pro side, the new form is working on
/any/ IO register, regardless of whether it's a possible target of an
SBI/CBI instruction (where you would have gotten assembler errors with
the old macros).  The optimizer is just smart enough to see whether it
can be translated into SBI/CBI, has to be emulated using IN/OUT, or
even has to remain using MMIO instructions (like for the extended IO
registers of the ATmega128, or when using it within a function where
the actual IO register address is not known at compile-time).

> It will confuse not only veterans, but also beginners as words "sbi/cbi" 
> associate with appropriate commands AVR.

Yes, and that's the main reason to completely drop support for the old
hacks: sbi()/cbi() /suggest/ to the people they would use the
respective assembler instruction automatically, but they don't.

> "avr-libc" it is widely used already 3 - 4 years, and an opportunity
> of direct use of ports in expressions only recently. I believe, ALL
> old programs use these functions.

That's why the suggestion is to not remove them immediately but to
deprecate them.  My idea with the <compat/gcc.h> (or whatever you
might name it) was to allow people to get away (for a while) with only
minimal changes to their sources, yet by requiring them to include the
additional header, give them a fair warning that they're now using a
deprecated functionality, so they might consider using the newer
method for new code.

> P.S. "to deprecate" it is a synonym "to exclude" ?

No, Webster says »to express disapproval of [something]«.  The idea is
to eventually remove it in future, but not immediately.  The removal
period could easily extend to a couple of years if you ask me, taking
into account its historial widespread use.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/