[Top][All Lists]

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

Re: [avr-libc-dev] RFC: avr/bits.h

From: E. Weddington
Subject: Re: [avr-libc-dev] RFC: avr/bits.h
Date: Tue, 01 Mar 2005 11:56:42 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Bob Paddock wrote:

On Tue, 01 Mar 2005 11:24:18 -0700, E. Weddington <address@hidden> wrote:

Is there any place where using this "((uint32_t)1<<(bitpos))"
is going to generate real Flash occupying 32 bit code,
when it is not needed?

Well, there's the tradeoff. Yes, it could if not used within the macros I proposed, if it used without typecasting. I don't know if GCC is smart enough to catch it in all cases without the typecasting. For example:

#define bit(bitpos) ((uint32_t)1<<(bitpos))

PORTD |= bit(1);

The right hand side will be a 32 bit unsigned integer. The left side is an 8 bit unsigned value. Will GCC optimize correctly? What if the register is not in the IO space? What if the value on the left is not defined with volatile?


After the previous discussion about this RFC (a while ago), I had some serious reservations about whether it should be implemented. Jörg has very good points in that the C language bit operators are an integral part of the language; a programmer should know how to use them. These macros *are* just another crutch, albeit sometimes useful. But it can't cover all cases, and it's no substitute for knowing the language. There will always be tradeoffs. And if someone is doing embedded work, it is practically a requirement that they know how to use these operators.


reply via email to

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