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

[Kishore <kitts.mailinglists@xxxxxxxxx>]

On Thursday 02 Sep 2010 10:24:29 am Alexander Zakharov wrote:
> 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?

Now i am not entirely convinced about this. Lets look at your example where you have a 5 bit variable (i) and lets say packed next to it, you have another 5 bit variable (j) and they both sit in the same word length...

Now.. in a multi threaded app, since writes to either i or j are not atomic, if thread A did i = 2, it would first need to read the word (which includes j), modify i and write back. Here any write to j happening at the very same moment to j in thread B can corrupt it.

In other words, writes to bitfields are non atomic and can affect adjacent variables and hence requires access protection around the whole group of variables.

> 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
-- 
Cheers!
Kishore