Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401227
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Microcontroller software stacks |
| Date | 2026-08-15 17:31 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <864igu52jb.fsf@linuxsc.com> (permalink) |
| References | (5 earlier) <fkCTR.17300$_BG8.7520@fx24.iad> <86h5mv8umk.fsf@linuxsc.com> <oac_R.3743$Zhg2.1242@fx12.iad> <865x1c7a63.fsf@linuxsc.com> <iZLfS.7962$oxY4.4420@fx09.iad> |
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 | Find similar | Unroll 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 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
csiph-web