Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: Re[4]: [lpc2000] Re: Bit addressing

2006-03-01 by Robert Adsett

Quoting Alexey Bishletov <nita@...>:

> 5:08:07 PM, Wednesday, March 1, 2006, Robert wrote:
>> Also if you have a different read and write register at the same
>> address you may
>> get really odd results.
>
> My variant uses the same register for read and write. It is possible
> for LPC.

Sorry I don't understand this. This is a general issue using any sort of
Read-modify-write sequence when you have hardware that maps a ready-only
register and a write only register to the same address.  Bit fields are almost
always implemented as RMW sequences and so in that case you will not be doing
what you expected to do.

> There is another solution. Use C++, create class "port" and overload
> operator=(int) and int(port). But some overhead will be unavoidable.

There was an initiative to standardize a set of macros and library
routines for
ISO C for Hardware access.  I havn't heard of it in a while though.

>> Basically bitfields are a very bad idea for I/O.  Sooner or later thay
>> will bite
>> you in the fundament.
>
> Why do you think so? Or is it so only with LPC?

Nope, all processors.  The issues off the top of my head are
  - Bitfield order is implementation defined
  - Bitfield write is necessarily an RMW sequence which is invalid for a lot of
hardware and non-atomic on a lot of processors.
  - Access size is indeterminate.
  - Bitfields default to signed.

Worse some of this may change depending on optimization conditions.  And the
compiler vendor is quite free to change this from version to version.

Now if the compiler vendor is using this for their own defined headers
there is
a reasonable chance that it will remain valid (although I have seen vendors
change similar details on a major upgrade).  You are though locked into your
particular vendor at that point.

I've also found building and maintaining bifield structures to be far more
painful than the alternatives.

The only thing bitfields are good for is saving memory in internal data
structures, where everything except the signedness is irrelevant.

Robert

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.