Re: [avr-libc-dev] interrupt enable functions

[E. Weddington]

On 8 Aug 2002 at 9:14, Theodore A. Roth wrote:
> 
> 
> On Thu, 8 Aug 2002, E. Weddington wrote:
> 
> :) First off, yes I know it included magic numbers... then I said that
> :) the numbers could be replaced with the defines from the processor-
> :) specific headers. I didn't originally write it that way due to time
> :) constraints of  having to look up all the blasted names for the bit
> :) values.
> 
> That was meant to be tongue in check. Didn't mean to offend, sorry if
> I did. ;-)
> 

No offense taken. Just kinda "yeah, yeah, I know, I know" :)


> :) Concerning namespace pollution: It's there whether you like it or
> :) not. What difference does it make to have all the bits in a reg :)
> #defined to have their own arcane symbol that's difficult to :)
> remember, or to have macros defined like :) above that at least tie
> the name with what it does? Which way is more :) mnemonic? :) :) And
> if you're concerned about these macros conflicting with users' :)
> macros, then these could be placed in a separate, optional header :)
> file. Most often, programmers write their own macros to name system-
> :) specific bit flipping. If they already have their own, they don't
> :) have to include the header. If they are starting a new project they
> :) could include this header and spend time writing their application
> :) with readable code without reinventing the macros. :) :) Now since
> most other compiler don't provide these kinds of macros, :) one could
> argue that avrgcc shouldn't do it either and it should be :) left up
> to the programmer. One could make another argument and say :) that
> since no other compiler offers anything like this, why not :)
> differentiate avrgcc from other compilers and offer a convenience to
> :) programmers. .... Really it could go either way. But don't do it
> half- :) way.
> 
> Well, for me, it's more of a maintenance issue. I prefer a single
> simple interface for all cases and use the bit value macros which hind
> the device specifics (although right now that needs some work). The
> "cryptic" bit value macros are not that cryptic if they use (mostly)
> the same mnemonic as the data sheet, which you'll most likely be
> reading any how. The bit value macros are easier to maintain than the
> many function like macros you propose.

Agreed that they are easier to maintain. But it also does what every 
other compiler does too; no added value.

As an aside.. I'm constantly flabbergasted by the number of people 
asking questions about bit-shift operators and what (1 << x) means in 
the BV macro. Flipping bits, and creating bit masks seems to me to be 
basic stuff. I'm almost to the point of requesting a FAQ for it. But 
anyway....


> 
> :)
> :) Concerning the new headers: I think that perhaps it came from the
> :) AVRFREAKS site. I'm including the relative files for your perusal.
> :) I'm not particularly thrilled with the implementation, but it works
> :) and they tried to make it backwards-compatible with the macros with
> :) conditional compilation and such. :) :) > > First, I think that you
> should be using _BV() instead of the :) > > deprecated (I believe)
> BV(). That's an off topic nit though. :) > :) > Hmm, i didn't know
> BV() was deprecated.  Sure, its name is in the :) > application
> namespace, but we've got so many other macro names that :) > pollute
> the application namespace so that could hardly be an argument. :) > :)
> > All the other macros with leading underscores (like __inw etc.) have
> :) > even been removed now, why do we want to make the people move
> from :) > BV() to _BV() then?  I can't quite follow this. :) :) Yeah I
> didn't know it was deprecated either. :) :) Personally I don't use
> that macro; I roll my own with the same :) definition and call it
> BIT(). Personally I don't like making :) abbreviations unless
> absolutely necessary. I find it easier to :) understand PORTA |=
> BIT(5) than PORTA |= BV(5) and then remember that :) BV stands for Bit
> Value.
> 
> You're always welcome to do whatever you want in your code and I agree
> that BIT makes more sense than BV (or _BV). In the manual though, our
> examples should try to use non-deprecated interfaces and not introduce
> new ones.
> 
> I really don't know why Marek changed BV() to _BV().

I didn't mean to imply I was suggesting to add anything like this 
macro. I just wanted an example of readability.

Personally I think that that kind of macro, whatever it is called, to 
create a bit mask from the bit number, is the kind of thing that's 
useful in a cross-compiler for an embedded processor. I've seen it in 
one other compiler. I'm not necessarily a proponent for getting rid 
of it or deprecating it.

Eric