Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Bit filed usage

Reply
Thread Tools

Bit filed usage

 
 
Zoran Cutura
Guest
Posts: n/a
 
      08-11-2003
Jack Klein <(E-Mail Removed)> wrote:
> On 8 Aug 2003 11:45:26 GMT, Zoran Cutura
> <(E-Mail Removed)> wrote in comp.lang.c:
>

....
>> you ever noticed that there are so many embedded devices out there
>> having only a few kBytes of RAM available? For example in automotive

>
> "kBytes"? That's among the larger size for embedded systems. I've
> done quite a few applications in my time with C for 8051 derivative's
> with 128 bytes, some of which has to be left for CPU registers.


I've not, still I know that there are such systemsi, and I'm about to
experience such systems in the near future.

I probably should have mentioned the even smaller systems, but I have or
had the feeling that the number of such systems is rather low, when one
comes to think about this in more depth, one recognizes that feelings
are not always to be trusted.

--
Z ((E-Mail Removed))
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      08-11-2003
In <(E-Mail Removed)> John Devereux <(E-Mail Removed)> writes:

>In fact, I suspect that when C bitfields were "invented", the machines of the
>time would have been equivalent in resources to the embedded systems of which you
>speak.


Not really. Even the first PDP-11 machine used by Ritchie was capable
of addressing 56K of RAM (the upper 8K were reserved for I/O registers).

By the time C started to have the shape described in K&R1, the PDP-11/45
was the "standard" Unix hardware (a single program could easily access
64k of code and 64k of data).

>Are there any legitimate uses other than saving space in structures? I
>have seen them used for defining peripheral hardware register layouts, but that
>is very bad form here so I won't even mention it


I strongly suspect that Ritchie added them to the language so that he
could write readable device drivers. Such code is a pain to read if
bit fields are not used. To the generated object code, it makes little
difference if the shifting and masking is coming from the source code or
is inlined by the compiler, as a result of processing bit fields: given
the way information is mapped on certain hardware registers, it is
unavoidable.

I have yet to see a "high level" programming task requiring or benefitting
from the usage of bit fields.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
John Devereux
Guest
Posts: n/a
 
      08-12-2003
(E-Mail Removed) (Dan Pop) writes:

> In <(E-Mail Removed)> John Devereux <(E-Mail Removed)> writes:
>
> >(E-Mail Removed) (Dan Pop) writes:
> >

<SNIP>
> >> I strongly suspect that Ritchie added them to the language so that he
> >> could write readable device drivers. Such code is a pain to read if
> >> bit fields are not used. To the generated object code, it makes little
> >> difference if the shifting and masking is coming from the source code or
> >> is inlined by the compiler, as a result of processing bit fields: given
> >> the way information is mapped on certain hardware registers, it is
> >> unavoidable.

> >
> >Ironic that this is usage is now frowned on, as far as I know.

>
> You shouldn't confuse this newsgroup and the real world.


No, I don't think it's just the newsgroup I've seen this advice
elsewhere, long before I discovered clc!

> OTOH, it is true that, if you need to write a "portable" device driver
> (i.e. one that works on any hardware platform supported by something like
> xBSD or Linux), bit fields are usually not an option.


I think the portability issue is more to do with portability between
compilers, rather than hardware platforms. Can standard C guarantee
bit alignment? (I didn't think it could).

For example, consider the use of bitfields to define a register layout
in a microcontroller. There is no need for the bitfields to be
portable to another type of microcontroller since the hardware they
specify will be totally different anyway. But it would be nice if you
could use any standard C compiler without all the bit positions moving
around each time you change compilers.


--

John Devereux
 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      08-13-2003
(E-Mail Removed) (Dan Pop) writes:

> In <(E-Mail Removed)> John Devereux <(E-Mail Removed)> writes:
>
> >(E-Mail Removed) (Dan Pop) writes:
> >
> >> OTOH, it is true that, if you need to write a "portable" device driver
> >> (i.e. one that works on any hardware platform supported by something like
> >> xBSD or Linux), bit fields are usually not an option.

> >
> >I think the portability issue is more to do with portability between
> >compilers, rather than hardware platforms.

>
> The compiler's behaviour is often dictated by the underlying hardware.
> gcc allocates bit fields differently on little endian vs big endian
> platforms. OTOH, different compilers generating code for the same
> hardware platform usually align bit fields in the same way.
>
> >Can standard C guarantee bit alignment? (I didn't think it could).

>
> It could, if it wanted to, but it doesn't:
>
> The order of allocation of
> bit-fields within a unit (high-order to low-order or low-order
> to high-order) is implementation-defined.
>
> >For example, consider the use of bitfields to define a register layout
> >in a microcontroller. There is no need for the bitfields to be
> >portable to another type of microcontroller since the hardware they
> >specify will be totally different anyway. But it would be nice if you
> >could use any standard C compiler without all the bit positions moving
> >around each time you change compilers.

>
> Have you actually noticed differences in behaviour between compilers
> targeting the same processor?


Well, no. I tend to choose a compiler and stick to it. (Recently I
have been using gcc for everything). I expect you're right (that most
compilers for the same platform have the same bit allocations). I just
read somewhere not to use bitfields for this sort of thing, when I was
learning C. And I never did. I end up with constructs like

REG |= 3<<1 | 1<<3 | 1<<6;

etc.





--

John Devereux
 
Reply With Quote
 
The real OS2 guy
Guest
Posts: n/a
 
      08-14-2003
On Mon, 11 Aug 2003 06:54:25 UTC, Zoran Cutura
<(E-Mail Removed)> wrote:

> Jack Klein <(E-Mail Removed)> wrote:
> > On 8 Aug 2003 11:45:26 GMT, Zoran Cutura
> > <(E-Mail Removed)> wrote in comp.lang.c:
> >

> ...
> >> you ever noticed that there are so many embedded devices out there
> >> having only a few kBytes of RAM available? For example in automotive

> >
> > "kBytes"? That's among the larger size for embedded systems. I've
> > done quite a few applications in my time with C for 8051 derivative's
> > with 128 bytes, some of which has to be left for CPU registers.

>
> I've not, still I know that there are such systemsi, and I'm about to
> experience such systems in the near future.
>
> I probably should have mentioned the even smaller systems, but I have or
> had the feeling that the number of such systems is rather low, when one
> comes to think about this in more depth, one recognizes that feelings
> are not always to be trusted.
>


For that it is much easier to maintenace a structure of bitfields than
to crawl through the whole soure to find thouseds of bitmasks, ****
operations and so on:

#ifdef MASHINEA
typedef struct S_A {
unsigned s : 1;
unsigned f : 3;
unsigned v : 4;
unsigned ta : 4;
unsigned tb : 4;
unsigned reserve : 16; /* planned hardware extension */
} *PREGC;

In question it is siple to reorder the struct and forget the access to
spezific bits:
#elseif MASHINEB
typedef struct S_A {
unsigned reserve : 4; /* planned hardware extension! */
unsigned tb : 4;
unsigned ta : 4;
unsigned reserve2 :4;
unsigned v : 4;
unsigned reserve3 :8;
unsigned f : 3;
unsigned s : 1;
} *PREGC;
#else /* mashine C */
.....

and all changes are done, each bitfield gets addressed with its own
name instead some shift macros, fiddeling around with masks and son
on. A simple assignment, a simple test is what is visible in the
soure. Let the compiler do the mashine dependant work, simply do the
project work.

#define RESET_REGC 0xf
#define INIT_REGC 0x0
......


PREGC regc = (PREGC) REGC_ADDR;
......
if (regc->v) ra = regc->ta, regc->tb = ro, regc->s = 0;
else regc->v = regc->s ? RESET_REGC : INIT_REGC;

ist doch einiges übersichtlicher als

temp = *r4711 & REGC_MASK_V >> REGC_V_SHIFT_COUNT;
if (temp)
ra = temp & REGC_MASK_TA >> ......
......
oder sonstige Makrobastelei.


Bitfelder sind nicht auf allen Maschinenstrukturen identisch
organisiert - aber selbst bei kleineren Hardwareabweichungen lassen
sich durch geschickt gewählte structs, die eben die Bits
(maschinenabhängig sortiert) Bitfeler ausweisen einfacher im Source
handhaben, ohne Rücksicht auf die konkrete Maschine.

Treiber, die auf einer Maschine eine ganze Familie von Geräten mit
vendorspezifischen Abweichungen behandeln, lassen sich so auch auf
einen lesbaren Codelevel bringen. Wenn kein Hardwareregister drunter
steckt, lassen sich auch ganze Flagorgien kompakt organisieren - ohne
mit casting, shiftorgien und Makrogeschwüren rumzumachen.

Klarer, lesbarer Code ist wichtiger als Speicher und Laufzeitersparnis
im Mikrosekundenbereich. Und wenn es wirklich auf die Nanosekunde und
das letzte Byte Codeersparnis ankommt, hilft sowieso nur noch
Unportabilität in aller Konsequenz == Assebler. Ansonsten
höchstmögliche Portabilität, einfacher Code, Klarheit und damit
Bitfelder wo möglich/nötig.

Bitfelder helfen maßgeblich dabei.



--
Tschau/Bye

Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 german is in beta testing
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      08-16-2003
In article <bhd451$5j7$(E-Mail Removed)> Dan Pop <(E-Mail Removed)> wrote:
>Have you actually noticed differences in [bit-field] behaviour
>between compilers targeting the same processor?


I have.

The MIT 68k C compiler used little-endian bit ordering, while the
Sun 68k C compiler on the Sun 2 used big-endian ordering.

These did both predate ANSI C, but since 1993 or so I have had the
luxury of using only a single C compiler (GCC). (I suppose GCC
could be called many different compilers; certainly gcc1, gcc2,
egcs, and now gcc3 have all been rather different internally. But
they are more like each other than they are like the old VAX PCC,
for instance.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the point of having 16 bit colour if a computer monitor can only display 8 bit colour? How do you edit 16 bit colour when you can only see 8 bit? Scotius Digital Photography 6 07-13-2010 03:33 AM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit, Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new ! vvcd Computer Support 0 09-17-2004 08:15 PM
COMPLAINT FILED CITIZEN OF INDIA MCSE 30 07-02-2004 05:13 AM
application filed to initialize properly Patricia Kline ASP .Net 0 02-26-2004 10:33 PM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit,Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new! Ionizer Computer Support 1 01-01-2004 07:27 PM



Advertisments