RE: [arm-gnu] Access to volatile bit-fields

["Alexander Zakharov" <zakharov@xxxxxxxxxxxx>]

Charles,

I do not want dispute or argue - by the end of the day its designer's
choice, but I didn't spend this 15 years in the same company - I am
freelance consultant and each shop has its own rules, tools, procedures
and coding guidelines. It just happen that in current assignment
bitfields are part of the design SOW since shop did and is using them
heavily. The point though that I did try to make is that CS compiler is
claimed to be ARM ABI compliant and as such any deviation from ARM ABI
must be considered as a bug or flow (but not  a feature). By the end of
the day if I as a coder do declare "volatile unsigned int: 5" I really
mean it. Why compiler does choose access for me if I did directly
instruct it to do unsigned int access respective to the architecture?

BTW - this issue is at least 3 years old, and if you have spare minute
you can search in GNU forum this topic and see that it was submitted as
a bug and accepted as a bug and corresponding patch was created - it's
just got MIA and hanging there as unassigned.

More and more people in ARM community are switching to CS from Keil,
IAR, RVDS and number of other commercial compilers, but guess what -
they do have huge legacy code base with heavy usage of bitfields (at
least all the commercial ARM compilers do obey volatile bitfields access
container - name me one that doesn't and I'll eat my sandals). What
would be your offer for them? I had very hard time to convince my client
to switch to GNU tool chain and now when estimated cake walk porting
became a nightmare, I do understand why this bug fix is so important. To
give you an idea, I had to modify ch9 USB files and nand flash files
(combined around 300K of source code) by hand and I am around 10% done
with respect to other drivers. We all love GNU and all the associated
benefits, we all are contributors, so why make life hard for those
unfortunate with bitfields in hand? What we are talking about is 20
lines of C code patch. Let designers choose what to use - bitfields or
all this or/and/shift stuff.

Again, we are not talking about personal or professional preferences,
but rather ARM ABI standard, and volatile bitfields is a pure bug in ARM
gcc and has to be fixed at some point and sooner it will be done sooner
people will switch from proprietary tool chains to GNU.

-----Original Message-----
From: Charles Manning [mailto:manningc2@xxxxxxxxxxxxx] 
Sent: Wednesday, September 01, 2010 10:41 PM
To: arm-gnu@xxxxxxxxxxxxxxxx
Subject: Re: [arm-gnu] Access to volatile bit-fields

I am 100% with 42Bastian on this.

"Looks cute" is not the same as "cleanest"

I've been an embedding with C for 26 years now and won't touch bitfields
for 
this purpose.

It is not the cleanest mapping because there is no definition of what
bus 
cycles should occur. Nor does any C spec define the actual bit layouts
of 
bitfields. The compiler is actually free to shift bits around in a
structure 
to improve alignment if it should so wish.

There are also other ways to support your debugging. For example gdb
provides 
extensive macro capabilities which allow you to read a register and
format 
the output way more flexibly than bitfields ever will.

I do, however, make extensive use of bitfields for other structures.

--Charles


On Wednesday 01 September 2010 02:19:01 zakharov@xxxxxxxxxxxx wrote:
> Many developers would agree with you since many of them did bite the
> bullet at some point. Yet bitfields is the most clean mapping from the
> hardware spec to the actual code. You have to remember one more
> important thing - debugging. If you will use all this or-ing and
> shifting then you will loose opportunity to see the register in the
> debugger. For example in my design I can always pop-up "live" register
> in TRACE32 or Eclipse and see absolute location address and all the
> fields. Very handy and very useful. In my previous project where we
> had around few hundred very complex registers it was a must. In any
> case, if compiler is declared ARM ABI compliant it has to be so. What
> confuses me is that issue goes back to 2007 and patch does exist and
> still not populated in current releases. I spent last  15 years
> writing firmware for all kinds of CPU and micro controllers and my
> opinion is - we want and we will use bitfields. I am sure any embedded
> designer will be on my side.
>
> Alex
>
> Quoting 42Bastian <list-bastian.schick@xxxxxxxxxxx>:
> > AmAm 31.08.2010 10:04, schrieb Ryan Lishman:
> >> Not pretty either way ... the best solution would be an ABI
compliant
> >> compiler. Anxiously, we wait.
> >
> > Sorry to say this: The best solution would be to not use bit fields
at
> > all.
> >
> > When it comes to hardware I strongly discourage the use of bit
fields.
> >
> > --
> > 42Bastian
> > +
> >
> > | http://www.sciopta.com
> > | Fastest direct message passing kernel.
> > | IEC61508 certified.
> >
> > +