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

[Douglas Dotson]

I guess that the term "deprecated" doesn't ring
true with some. Anyone that disagrees with the
policy can define the deprecated features in their
own local headers. Just because a feature is 
deprecated doesn't mean it can't be used.

Doug

--- Victoria Welch <address@hidden> wrote:

> Hello Bruce,
> 
> Wonderfully made points all.
> 
> On Sunday 30 January 2005 17:37, Bruce D. Lightner
> wrote:
> > 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. ;-)
> 
> Perhaps some of us just use the sbi/cbi macros
> (quite 
> successfully, I might add) and have been since we
> started 
> using the avr-gcc toolchain.
> 
> Personally, I take that comment as elitist,
> arrogant, 
> patronizing and insulting to those of use the
> language and 
> are not low level gurus.
> 
> > > 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!
> 
> Bravo!  I like a rational attitude :-)!   I'm no
> guru but if 
> I can help, let me know and I'll do whatever I can
> although 
> that might not be much :-/.
> 
> > 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.
> 
> I'm pretty new to the list, but it did come as a
> shock to 
> get pages of errors over this.  Fortunately it was
> easy 
> enough to fix after some research.
> 
> > 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!!
> 
> Very much so, the efforts of all involved in this
> are more 
> greatly appreciated than there are words suitable to
> 
> express it!
> 
> This is not a great big deal although I do wonder
> why these 
> disappeared when they certainly appear to have a
> VERY wide 
> and heavy usage (at least amoungst those I work with
> and 
> know who do work with the avr-gcc tools.)
> 
> > 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?
> 
> No, I don't think you are overreacting at all.  "If
> it ain't 
> broke, don't fix it" comes to mind here.  Especially
> 
> something that I know for me and a number of others
> has 
> been HEAVILY used for quite some time.
> 
> The suggested method might be pure, but it sure as
> hell, 
> IMNSHO, is not as clear as the sbi / cbi constructs.
>  I'm 
> no purist so I just add the following to my defs.h
> file:
> 
> 
> /* defines for backward compatibility */
> #ifndef cbi
>  #define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
> #endif
> #ifndef sbi
>  #define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
> #endif
> 
> It was looking at the massive amount of time, effort
> and 
> hassle to replace all the sbi /cbi stuff alone that
> sent me 
> off looking for the above.
> 
> That said, some gracious soul sent me what appears
> to be a 
> better set of macros, I just need to take some time
> and 
> look them over, but I suspect that I will use them.
> 
> > How about a vote on this?
> 
> I dunno about a vote, it is certainly easy to fix
> and one of 
> the joys of open source and C is that you do not
> need to 
> just swallow what one isfed :-).
> 
> Yes, I am a little miffed over the original comment
> on this, 
> but I'll get over it :-).
> 
=== message truncated ===