Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #401227

Re: Microcontroller software stacks

Show key headers only | View raw

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> One might also define data structures for control and status
>>>>> registers using bitfield structs.
>>>>
>>>> Yeah.  This kind of application (among others) I consider one of
>>>> the motivating forces behind bitfields.
>>>>
>>>> [Some whitespace trimming done in the excerpt below.]
>>>>
>>>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>>>
>>>>> union UAHC_GBL_OOBR {
>>>>>   uint32_t u;
>>>>>   struct UAHC_GBL_OOBR_s {
>>>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>>>     uint32_t we     :  1; /**< R/W/H - Write enable. */
>>>>>     uint32_t cwmin  :  7; /**< R/W/H - COMWAKE minimum value [...] */
>>>>>     uint32_t cwmax  :  8; /**< R/W/H - COMWAKE maximum value [...] */
>>>>>     uint32_t cimin  :  8; /**< R/W/H - COMINIT minimum value [...] */
>>>>>     uint32_t cimax  :  8; /**< R/W/H - COMINIT maximum value [...] */
>>>>> #else
>>>>>     uint32_t cimax  :  8;
>>>>>     uint32_t cimin  :  8;
>>>>>     uint32_t cwmax  :  8;
>>>>>     uint32_t cwmin  :  7;
>>>>>     uint32_t we     :  1;
>>>>> #endif
>>>>>   } s;
>>>>> };
>>>>
>>>> To me it seems kind of goofy to use uint32_t for the bitfields type.
>>>> I would just use unsigned, which is just as sure to work as intended,
>>>> isn't it?
>>>
>>> The SATA hardware register is defined as a 32-bit register in the
>>> SATA specification.  Therefore we explicitly declare it as such.
>>
>> I understand the motivation for using uint32_t for the union member
>> u.  My question is only about the type used for the bitfields.  Do
>> you know of any platform, or even suspect that there might be a
>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>> of the bitfields makes any difference at all?
>
> I haven't canvassed all the available platforms, and don't have
> any desire so to do.  In my opinion, using the same type for the
> bitfield members as was used for the corresponding union
> element is simply logical.   If we declare the integer part
> of the union as uint64_t,  we use the same time for the
> bitfields (and yes, we could have used unsigned long
> (or unsigned long long on the micky OS) - uint64_t
> is less typing.

Out of curiosity I put together a short program to explore how
bit-field types are understood by the compiler.  Here is the
program:

    #include <stdio.h>
    #include <stdint.h>

    typedef struct {
      _Bool                 ub  : 1;
      unsigned char         uc  : 8;
      unsigned short        us  :16;
      unsigned int          ui  :32;
      unsigned long         ul  :64;
      unsigned long long    ull :64;

      uint8_t               u1  : 1;
      uint8_t               u8  : 8;
      uint16_t              u16 :16;
      uint32_t              u32 :32;
      uint64_t              u64 :64;

      uint64_t              x1  : 1;
      uint64_t              x8  : 8;
      uint64_t              x16 :16;
      uint64_t              x32 :32;
      uint64_t              x64 :64;
    } Bitfields;

    #define whatkind(e) (                                           \
      _Generic( e,                                                  \
        _Bool               : "_Bool",                              \
        unsigned char       : "unsigned char",                      \
        unsigned short      : "unsigned short",                     \
        unsigned int        : "unsigned int",                       \
        unsigned long       : "unsigned long",                      \
        unsigned long long  : "unsigned long long",                 \
        default             : "<something else>"                    \
      )                                                             \
    )

    int
    main(){
      Bitfields bf;
        printf( " whatkind( bf.ub  ) is %s\n", whatkind( bf.ub  ) );
        printf( " whatkind( bf.uc  ) is %s\n", whatkind( bf.uc  ) );
        printf( " whatkind( bf.us  ) is %s\n", whatkind( bf.us  ) );
        printf( " whatkind( bf.ui  ) is %s\n", whatkind( bf.ui  ) );
        printf( " whatkind( bf.ul  ) is %s\n", whatkind( bf.ul  ) );
        printf( " whatkind( bf.ull ) is %s\n", whatkind( bf.ull ) );
        printf( "\n" );

        printf( " whatkind( bf.u1  ) is %s\n", whatkind( bf.u1  ) );
        printf( " whatkind( bf.u8  ) is %s\n", whatkind( bf.u8  ) );
        printf( " whatkind( bf.u16 ) is %s\n", whatkind( bf.u16 ) );
        printf( " whatkind( bf.u32 ) is %s\n", whatkind( bf.u32 ) );
        printf( " whatkind( bf.u64 ) is %s\n", whatkind( bf.u64 ) );
        printf( "\n" );

        printf( " whatkind( bf.x1  ) is %s\n", whatkind( bf.x1  ) );
        printf( " whatkind( bf.x8  ) is %s\n", whatkind( bf.x8  ) );
        printf( " whatkind( bf.x16 ) is %s\n", whatkind( bf.x16 ) );
        printf( " whatkind( bf.x32 ) is %s\n", whatkind( bf.x32 ) );
        printf( " whatkind( bf.x64 ) is %s\n", whatkind( bf.x64 ) );
    }

and the output (using gcc)

     whatkind( bf.ub  ) is _Bool
     whatkind( bf.uc  ) is unsigned char
     whatkind( bf.us  ) is unsigned short
     whatkind( bf.ui  ) is unsigned int
     whatkind( bf.ul  ) is unsigned long
     whatkind( bf.ull ) is unsigned long long

     whatkind( bf.u1  ) is <something else>
     whatkind( bf.u8  ) is unsigned char
     whatkind( bf.u16 ) is unsigned short
     whatkind( bf.u32 ) is unsigned int
     whatkind( bf.u64 ) is unsigned long

     whatkind( bf.x1  ) is <something else>
     whatkind( bf.x8  ) is unsigned char
     whatkind( bf.x16 ) is unsigned short
     whatkind( bf.x32 ) is unsigned int
     whatkind( bf.x64 ) is unsigned long

and the output (using clang)

     whatkind( bf.ub  ) is _Bool
     whatkind( bf.uc  ) is unsigned char
     whatkind( bf.us  ) is unsigned short
     whatkind( bf.ui  ) is unsigned int
     whatkind( bf.ul  ) is unsigned long
     whatkind( bf.ull ) is unsigned long long

     whatkind( bf.u1  ) is unsigned char
     whatkind( bf.u8  ) is unsigned char
     whatkind( bf.u16 ) is unsigned short
     whatkind( bf.u32 ) is unsigned int
     whatkind( bf.u64 ) is unsigned long

     whatkind( bf.x1  ) is unsigned long
     whatkind( bf.x8  ) is unsigned long
     whatkind( bf.x16 ) is unsigned long
     whatkind( bf.x32 ) is unsigned long
     whatkind( bf.x64 ) is unsigned long

which serves to reinforce my view that bit-field types should be
chosen from the basic types, and should be the narrowest type that
covers the width of the corresponding bit-field member (with
possible adjustment for widths that match two types, as for example
unsigned long and unsigned long long).

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
  Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
    Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
      Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
      Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
      Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
        Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
          Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
            Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
              Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
                Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
            Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
              Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
                Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:31 +0300
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 13:41 +0200
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 15:41 +0000
                Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:58 +0300
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
                Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
                Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 08:57 +0200
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 14:59 +0000
                Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
          Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
  Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
    Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
    Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
      Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
  Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
    Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
    Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
      Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
        Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
          Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
      Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
      Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
        Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
          Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
            Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
              Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
                Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
        Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
          Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
          Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
        Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
  Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800

csiph-web