Lpc2000

At 04:13 PM 11/9/05 -0500, Tom Walsh wrote:
>Robert Adsett wrote:
> >
> >Bitfields are very seductive approaches to HW interfacing but after trying
> >them several times I've come to the conclusion that they are far more
> >effort than they are worth and are questionable even if you stick to the
> >same compiler (and version) on the same architecture.
> >
> >IMO the only thing bitfields are useful for is storing abstract flags and
> >sub integer sized values in structure that you want to memory
> >optimize.  They then act as a hint to the compiler that you want to use as
> >little room as possible at the expense of extra runtime.  They are not even
> >useful for binary file structures (they break across compilers/architecture
> >there as well)..
> >
> >
> >
>
>I agree with you for the most part.  However there are data records that
>other systems send to me in a packed format that I either write a lot of
>code to unmangle, or simply describe it using packed attribute and
>bitfield definitions.

Fair enough.  That works (until it doesn't).

>What I don't agree with is your statement about "at the expense of extra
>runtime".   As an assembly programmer for many years, I would be hard
>pressed to come up with some of the code sequences that the compiler
>produces!

Um, I think what I was writing about and what you read are two different 
things.  I was referring to the difference in time between accessing field 
a in the two following structures.

struct AA {
         int a : 1;
         int b : !:
         };

struct BB {
          int a;
         int b;
           };

Barring bit instructions access to the BB structure will be faster and take 
less code.  As I said abstract flags.

For hardware access I've found I can wrap up access in macros or functions 
nearly as quickly as I can create a structure with bitfield in it to 
provide the same access.  And since the bitfield form usually needs some 
form of information hiding anyway to provide a 'clean ' interface and I 
don't have to worry about how the compiler has defined items like bit order 
allocation and bitfields crossing boundaries (documentation that always 
seems to be hidden away no matter the compiler)  I've given up on bitfields 
having any use for hardware access.  YMMV


>For the most part, I try not to be too specific about how I code
>something so that the compiler can take advantage of optimizing my
>code.  The more specific I get about how an operation should proceed,
>the less leeway I'm allowing the optimizer to take.  Todays' code
>optimizers are amazingly efficient!

Yep, code clearly comment well and test.  Then consider optimizing IF there 
is a performance issue after considering alternate algorithms.  To quote 
Knuth "Premature optimization is the root of all evil".

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/