Bit filed usage

Discussion in 'C Programming' started by Capstar, Aug 8, 2003.

  1. Capstar

    Capstar Guest

    Hi NG,

    I have a question about the usage of bitfileds in a structure.
    for instance:

    struct pcard
    {
    unsigned pips : 4;
    unsigned suit : 2;
    };

    The only reason I see fot using this is to save memory. But isn't it true
    that on most systems memory isn't that much of an issue to pack data like
    this? And even on some embedded machine whitout much memory, I'm not sure
    the memory gain by packing your structures will be much bigger than the loss
    you get from the increased code size. Maybe when you have lots of these
    structures you will gain something.

    Another reason I would consider this helpfull would be if the structures
    would be written to some binary file. In my opinion file size does matter.
    The only problem I see in this case is that every machine, and even a
    different compiler at the same machine, could map the bits somewhere else in
    a word. This would mean that the file is incompatible with anything but the
    same compiler and the same machine.

    So I am very curious if anybody ever uses these kind of structures and where
    they are used for.

    Mark
    Capstar, Aug 8, 2003
    #1
    1. Advertising

  2. "Capstar" <spam0@@@eg.homeip.net> wrote in message
    news:bgvvu3$ac0$...
    > Hi NG,
    >
    > I have a question about the usage of bitfileds in a structure.
    > for instance:
    >
    > struct pcard
    > {
    > unsigned pips : 4;
    > unsigned suit : 2;
    > };
    >
    > The only reason I see fot using this is to save memory. But isn't it

    true
    > that on most systems memory isn't that much of an issue to pack data

    like
    > this? And even on some embedded machine whitout much memory, I'm not

    sure
    > the memory gain by packing your structures will be much bigger than

    the loss
    > you get from the increased code size. Maybe when you have lots of

    these
    > structures you will gain something.
    >
    > Another reason I would consider this helpfull would be if the

    structures
    > would be written to some binary file. In my opinion file size does

    matter.
    > The only problem I see in this case is that every machine, and even a
    > different compiler at the same machine, could map the bits somewhere

    else in
    > a word. This would mean that the file is incompatible with anything

    but the
    > same compiler and the same machine.
    >
    > So I am very curious if anybody ever uses these kind of structures and

    where
    > they are used for.
    >
    > Mark
    >


    I suspect this is off-topic, but we use bit-field structures when
    mapping data for RFID tags where the memory is usually measured in bits,
    not bytes let alone kB.

    --
    Simon Wilkins
    www.robotag.co.uk
    Simon Wilkins, Aug 8, 2003
    #2
    1. Advertising

  3. On Fri, 8 Aug 2003 13:01:20 +0200
    "Capstar" <spam0@@@eg.homeip.net> wrote:
    > struct pcard
    > {
    > unsigned pips : 4;
    > unsigned suit : 2;
    > };
    >
    > The only reason I see fot using this is to save memory. But isn't it true
    > that on most systems memory isn't that much of an issue to pack data like
    > this? And even on some embedded machine whitout much memory, I'm not sure
    > the memory gain by packing your structures will be much bigger than the loss
    > you get from the increased code size. Maybe when you have lots of these
    > structures you will gain something.


    A reason for using these is to get around those annoying bitwise operations.
    They can be a real pain, and even when macro-ifying the operations, they don't
    improve readability.
    Bitfields leave those operations to the compiler.

    And the memory conservation is not an issue, since the structs are aligned
    anyway. The example you gave won't take up just 6 bits, it'll align and take up
    a byte, or a word, or an int, depending on your platform.

    Just using a struct of char's uses only slightly more memory, but gets rid of
    all the operations. All depends on what you want, more memory or more cycles.

    --
    char*x(c,k,s)char*k,*s;{if(!k)return*s-36?x(0,0,s+1):s;if(s)if(*s)c=10+(c?(x(
    c,k,0),x(c,k+=*s-c,s+1),*k):(x(*s,k,s+1),0));else c=10;printf(&x(~0,0,k)[c-~-
    c+"1"[~c<-c]],c);}main(){x(0,"^[kXc6]dn_eaoh$%c","-34*1'.+(,03#;+,)/'///*");}
    Pieter Droogendijk, Aug 8, 2003
    #3
  4. Capstar

    Capstar Guest

    "Pieter Droogendijk" <> wrote in message
    news:...
    > On Fri, 8 Aug 2003 13:01:20 +0200
    > "Capstar" <spam0@@@eg.homeip.net> wrote:
    > > struct pcard
    > > {
    > > unsigned pips : 4;
    > > unsigned suit : 2;
    > > };
    > >
    > > The only reason I see fot using this is to save memory. But isn't it

    true
    > > that on most systems memory isn't that much of an issue to pack data

    like
    > > this? And even on some embedded machine whitout much memory, I'm not

    sure
    > > the memory gain by packing your structures will be much bigger than the

    loss
    > > you get from the increased code size. Maybe when you have lots of these
    > > structures you will gain something.

    >
    > A reason for using these is to get around those annoying bitwise

    operations.
    > They can be a real pain, and even when macro-ifying the operations, they

    don't
    > improve readability.
    > Bitfields leave those operations to the compiler.


    Yes I understand, but what do you need those bitwise operations for if you
    don't use bits anyway? I mean bits in the sence that you don't measure how
    many bits you need for something and then stuff as many as possible in one
    word, but just use a word or more for every variable. That would also get
    you around those bitwise operations.

    >
    > And the memory conservation is not an issue, since the structs are aligned
    > anyway. The example you gave won't take up just 6 bits, it'll align and

    take up
    > a byte, or a word, or an int, depending on your platform.
    >
    > Just using a struct of char's uses only slightly more memory, but gets rid

    of
    > all the operations. All depends on what you want, more memory or more

    cycles.
    >
    > --
    >

    char*x(c,k,s)char*k,*s;{if(!k)return*s-36?x(0,0,s+1):s;if(s)if(*s)c=10+(c?(x
    (
    > c,k,0),x(c,k+=*s-c,s+1),*k):(x(*s,k,s+1),0));else

    c=10;printf(&x(~0,0,k)[c-~-
    >

    c+"1"[~c<-c]],c);}main(){x(0,"^[kXc6]dn_eaoh$%c","-34*1'.+(,03#;+,)/'///*");
    }
    Capstar, Aug 8, 2003
    #4
  5. Capstar

    Capstar Guest

    "Zoran Cutura" <> wrote in message
    news:bh02gm$plc$-felb.debis.de...
    > Capstar <spam0@@@eg.homeip.net> wrote:
    > > Hi NG,
    > >
    > > I have a question about the usage of bitfileds in a structure.
    > > for instance:
    > >
    > > struct pcard
    > > {
    > > unsigned pips : 4;
    > > unsigned suit : 2;
    > > };
    > >
    > > The only reason I see fot using this is to save memory. But isn't it

    true
    > > that on most systems memory isn't that much of an issue to pack data

    like
    > > this? And even on some embedded machine whitout much memory, I'm not

    sure
    > > the memory gain by packing your structures will be much bigger than the

    loss
    > > you get from the increased code size. Maybe when you have lots of these
    > > structures you will gain something.
    > >
    > > Another reason I would consider this helpfull would be if the structures
    > > would be written to some binary file. In my opinion file size does

    matter.
    > > The only problem I see in this case is that every machine, and even a
    > > different compiler at the same machine, could map the bits somewhere

    else in
    > > a word. This would mean that the file is incompatible with anything but

    the
    > > same compiler and the same machine.
    > >
    > > So I am very curious if anybody ever uses these kind of structures and

    where
    > > they are used for.

    >
    > Your understanding of what the most systems are is, IMHO, wrong. Have
    > you ever noticed that there are so many embedded devices out there
    > having only a few kBytes of RAM available? For example in automotive
    > typical so called ECU's (electronic control units) run with controllers
    > having between 120 and 500 kBytes of ROM where the program code can be
    > stored in, but only with 2 to 16 kBytes of RAM that can be used for
    > data. That usually brings in the need to care about Bits and Bytes.


    I must admit that there are a lot of embedded systems around nowadays, but I
    didn't realise that the ROM is often that much bigger than the RAM. I
    actually assumed the other way around. Which is probably a bit naive since
    ROM is much cheaper than RAM.
    So this actually is a good answer on my question why to use bitfield
    operators.

    >
    > You're probably thinking about most programmers being programmig for

    systems
    > where memory isn't a issue, but that is a claim that is hard to prove.
    >
    > Anyway, when you start a project or program, you usually do not need to
    > care about memory usage and speed form the very start. It should be
    > sufficient to make the program functionally correct and care about size
    > and speed when you recognize that there are problems with these.
    >
    > As you may have recognized yourself, structures shouldn't be written to
    > binary files as they are. Structures are very implementation specific
    > and as you say even two versions of a compiler may constitute 'em in
    > different ways. That is an issue with all structs not only bit fields.


    I understand. I didn't mean writing structs to a binary file, but for
    instance creating a one word header in a file. If that file contains some
    flags, you could use masks and bit operations to set and clear flags, or use
    a bitfield structure, and use that. Well actually the last is not possible,
    but that was what I tried to say in my OP.

    Mark
    Capstar, Aug 8, 2003
    #5
  6. On Fri, 8 Aug 2003, Capstar wrote:
    >
    > "Pieter Droogendijk" <> wrote...
    > > "Capstar" <spam0@@@eg.homeip.net> wrote:
    > > > struct pcard
    > > > {
    > > > unsigned pips : 4;
    > > > unsigned suit : 2;
    > > > };

    > >
    > > A reason for using these is to get around those annoying bitwise
    > > operations. They can be a real pain, and even when macro-ifying the
    > > operations, they don't improve readability.
    > > Bitfields leave those operations to the compiler.

    >
    > Yes I understand, but what do you need those bitwise operations for if you
    > don't use bits anyway? I mean bits in the sence that you don't measure how
    > many bits you need for something and then stuff as many as possible in one
    > word, but just use a word or more for every variable. That would also get
    > you around those bitwise operations.


    There are some applications for bitwise operators;
    encryption and compression come to mind. IIRC,
    some schemes for data encryption require bitwise
    XORs and shifts on 24-bit data, which could be a
    little annoying on platforms with 16- and 32-bit
    words. So if one really wanted to be pedantic,
    one could write

    struct int24_s
    {
    unsigned value: 24;
    };

    typedef struct int24_s int24_s;

    #define VALUE(int24) ((int24).value)

    and then use the regular bitwise operators on
    the VALUEs of int24_s objects, without worrying
    about bit masks.

    The caveat here is that I'm not sure whether
    the above bit-field definition is guaranteed to
    work on platforms where 'unsigned int' has fewer
    than 24 value bits. Expert advice welcome.

    -Arthur
    Arthur J. O'Dwyer, Aug 8, 2003
    #6
  7. Zoran Cutura <> writes:

    > Capstar <spam0@@@eg.homeip.net> wrote:
    > > Hi NG,
    > >
    > > I have a question about the usage of bitfileds in a structure.
    > > for instance:
    > >
    > > struct pcard
    > > {
    > > unsigned pips : 4;
    > > unsigned suit : 2;
    > > };
    > >
    > > The only reason I see fot using this is to save memory. But isn't it true
    > > that on most systems memory isn't that much of an issue to pack data like
    > > this? And even on some embedded machine whitout much memory, I'm not sure
    > > the memory gain by packing your structures will be much bigger than the loss
    > > you get from the increased code size. Maybe when you have lots of these
    > > structures you will gain something.
    > >
    > > Another reason I would consider this helpfull would be if the structures
    > > would be written to some binary file. In my opinion file size does matter.
    > > The only problem I see in this case is that every machine, and even a
    > > different compiler at the same machine, could map the bits somewhere else in
    > > a word. This would mean that the file is incompatible with anything but the
    > > same compiler and the same machine.
    > >
    > > So I am very curious if anybody ever uses these kind of structures and where
    > > they are used for.

    >
    > Your understanding of what the most systems are is, IMHO, wrong. Have
    > you ever noticed that there are so many embedded devices out there
    > having only a few kBytes of RAM available? For example in automotive
    > typical so called ECU's (electronic control units) run with controllers
    > having between 120 and 500 kBytes of ROM where the program code can be
    > stored in, but only with 2 to 16 kBytes of RAM that can be used for
    > data. That usually brings in the need to care about Bits and Bytes.


    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.

    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 :)

    --

    John Devereux
    John Devereux, Aug 8, 2003
    #7
  8. Capstar

    Jack Klein Guest

    On Fri, 8 Aug 2003 13:01:20 +0200, "Capstar" <spam0@@@eg.homeip.net>
    wrote in comp.lang.c:

    > Hi NG,
    >
    > I have a question about the usage of bitfileds in a structure.
    > for instance:
    >
    > struct pcard
    > {
    > unsigned pips : 4;
    > unsigned suit : 2;
    > };
    >
    > The only reason I see fot using this is to save memory. But isn't it true
    > that on most systems memory isn't that much of an issue to pack data like
    > this? And even on some embedded machine whitout much memory, I'm not sure
    > the memory gain by packing your structures will be much bigger than the loss
    > you get from the increased code size. Maybe when you have lots of these
    > structures you will gain something.


    Have you ever worked on an embedded system without much memory? If
    you haven't had the experience, your experience is pretty useless.
    Try writing C code to run in an environment with 4K (4K octets or
    bytes, not kilobytes or megabytes) read-only code space and less than
    128 8-bit bytes of read/write RAM.

    Then you'll be qualified to have an _informed_ opinion about writing C
    code for such environments.

    > Another reason I would consider this helpfull would be if the structures
    > would be written to some binary file. In my opinion file size does matter.
    > The only problem I see in this case is that every machine, and even a
    > different compiler at the same machine, could map the bits somewhere else in
    > a word. This would mean that the file is incompatible with anything but the
    > same compiler and the same machine.
    >
    > So I am very curious if anybody ever uses these kind of structures and where
    > they are used for.
    >
    > Mark


    If you don't see the usefulness of bit-fields in the code your write
    for the execution environments your code runs in, by all means feel
    free not to use them.

    Nobody ever said you had to use them, or even suggested that you use
    them.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 9, 2003
    #8
  9. Capstar

    Jack Klein Guest

    On 8 Aug 2003 11:45:26 GMT, Zoran Cutura
    <> wrote in comp.lang.c:

    > Capstar <spam0@@@eg.homeip.net> wrote:
    > > Hi NG,
    > >
    > > I have a question about the usage of bitfileds in a structure.
    > > for instance:
    > >
    > > struct pcard
    > > {
    > > unsigned pips : 4;
    > > unsigned suit : 2;
    > > };
    > >
    > > The only reason I see fot using this is to save memory. But isn't it true
    > > that on most systems memory isn't that much of an issue to pack data like
    > > this? And even on some embedded machine whitout much memory, I'm not sure
    > > the memory gain by packing your structures will be much bigger than the loss
    > > you get from the increased code size. Maybe when you have lots of these
    > > structures you will gain something.
    > >
    > > Another reason I would consider this helpfull would be if the structures
    > > would be written to some binary file. In my opinion file size does matter.
    > > The only problem I see in this case is that every machine, and even a
    > > different compiler at the same machine, could map the bits somewhere else in
    > > a word. This would mean that the file is incompatible with anything but the
    > > same compiler and the same machine.
    > >
    > > So I am very curious if anybody ever uses these kind of structures and where
    > > they are used for.

    >
    > Your understanding of what the most systems are is, IMHO, wrong. Have
    > 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.

    > typical so called ECU's (electronic control units) run with controllers
    > having between 120 and 500 kBytes of ROM where the program code can be
    > stored in, but only with 2 to 16 kBytes of RAM that can be used for
    > data. That usually brings in the need to care about Bits and Bytes.
    >
    > You're probably thinking about most programmers being programmig for systems
    > where memory isn't a issue, but that is a claim that is hard to prove.
    >
    > Anyway, when you start a project or program, you usually do not need to
    > care about memory usage and speed form the very start. It should be
    > sufficient to make the program functionally correct and care about size
    > and speed when you recognize that there are problems with these.
    >
    > As you may have recognized yourself, structures shouldn't be written to
    > binary files as they are. Structures are very implementation specific
    > and as you say even two versions of a compiler may constitute 'em in
    > different ways. That is an issue with all structs not only bit fields.


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 9, 2003
    #9
  10. Capstar

    Don Starr Guest

    On Sat, 09 Aug 2003 18:32:07 GMT, Jack Klein <> wrote:

    >Try writing C code to run in an environment with 4K (4K octets or
    >bytes, not kilobytes or megabytes) read-only code space and less than
    >128 8-bit bytes of read/write RAM.


    Now I feel spoiled with my 8k-word ROM, 384-byte RAM PIC ;)

    (And, yes, I use bitfields extensively. I even use them to <gasp!> control bits in hardware
    registers.)

    -Don
    Don Starr, Aug 9, 2003
    #10
  11. Capstar

    Zoran Cutura Guest

    Jack Klein <> wrote:
    > On 8 Aug 2003 11:45:26 GMT, Zoran Cutura
    > <> 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 ()
    "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
    Zoran Cutura, Aug 11, 2003
    #11
  12. Capstar

    Dan Pop Guest

    In <> John Devereux <> 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:
    Dan Pop, Aug 11, 2003
    #12
  13. (Dan Pop) writes:

    > In <> John Devereux <> writes:
    >
    > > (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
    John Devereux, Aug 12, 2003
    #13
  14. (Dan Pop) writes:

    > In <> John Devereux <> writes:
    >
    > > (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
    John Devereux, Aug 13, 2003
    #14
  15. On Mon, 11 Aug 2003 06:54:25 UTC, Zoran Cutura
    <> wrote:

    > Jack Klein <> wrote:
    > > On 8 Aug 2003 11:45:26 GMT, Zoran Cutura
    > > <> 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, shit
    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
    The real OS2 guy, Aug 14, 2003
    #15
  16. Capstar

    Chris Torek Guest

    In article <bhd451$5j7$> Dan Pop <> 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.
    Chris Torek, Aug 16, 2003
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patricia Kline

    application filed to initialize properly

    Patricia Kline, Feb 26, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    518
    Patricia Kline
    Feb 26, 2004
  2. RSB

    How to Validate a Date Filed.

    RSB, May 20, 2004, in forum: ASP .Net
    Replies:
    6
    Views:
    517
    John Oakes
    May 21, 2004
  3. Replies:
    3
    Views:
    1,743
    Timothy Bendfelt
    Jan 19, 2007
  4. Replies:
    9
    Views:
    966
    Juha Nieminen
    Aug 22, 2007
  5. Jeff.M
    Replies:
    6
    Views:
    171
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page