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

[Bruce D. Lightner]

E. Weddington wrote:

> Erik Walthinsen wrote:
>
> > E. Weddington wrote:
> >
> > > They've been deprecated for a long time. They were finally removed in 
> > > the 1.2.x series. They're gone for good.
> >
> > I still have not figured out what the logic is behind removing two of 
> > the most useful macros possible on a machine where ALL IO is preformed 
> > by setting and clearing bits.
> >
> > Please, enlighten me.
> Go look at the implementation of the sbi and cbi macros and you'll see 
> why. ;-)
> Eric

I just looked at the file "sfr_defs.h" where sbi() and cbi() macros are 
defined and I don't see what the problem is, nor do I see anything 
humorous about the code or the situation...

Eric, please enlighten me!  Exactly why were the "sbi() and cbi() macros 
removed?!!

Are *all* the "input/output" macros gone (e.g., bit_is_set(), 
bit_is_clear(), inb(), inw(), outb(), outw()...)?

If you need someone to "maintain" the file "sfr_defs.h", then I'm sure you 
can find lot's of volunteers...like me!

I've followed the "avr-gcc" mailing list every day for many years and I 
don't remember *any* inquiries, surveys, or votes regarding this recent 
"improvement" to avr-gcc, namely removing "depricated" I/O marcos.

So, please enlighten us as to why these macros cannot remain in the 
library.  I for one am ready listen to reason, but please also think long 
and hard about what removing them does to many of us long time end-users 
of avr-gcc.  And don't get me wrong, we folks that make daily use of the 
wonderful things that the maintainers of "avr-gcc" and it's libraries have 
created truly do appreciate your hard work!  And, we thank you!!

However, as the comments in the "sfr_defs.h" source code say regarding the 
"missing" macros, they are included for...

  "For backwards compatibility"

I personally have created well over 100 "avr-gcc" projects that make use 
of one or more now "depricated" I/O macros.  I have hundreds of thousands 
of AVR-based devices in the field that use avr-gcc source code that 
references these macros.  Responsibility for supporting that installed 
base resets with me.

Although I, like most(?) others make less and less use of "depricated" 
macros for new code, I do not want to be forced to revisit perfectly fine, 
field-proven, debugged and tested avr-gcc code just because a macro was 
"depricated" and I (or one of my customers) has decided to (or has been 
forced to) upgrade the "avr-gcc" toolset.  I don't know about you, but I 
know that "fixing" working source code is an invitation for new bugs. 
And, bugs cost time to fix, and time is money...to anyone but a hobbyist.

Does anyone else want to comment?  Am I overreacting?

How about a vote on this?

Best regards,

Bruce

--
 Bruce D. Lightner
 Lightner Engineering
 La Jolla, California
 Voice: +1-858-551-4011
 FAX: +1-858-551-0777
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/