Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400174 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2026-06-21 14:13 -0700 |
| Last post | 2026-08-20 04:51 +0800 |
| Articles | 8 on this page of 48 — 10 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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-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 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
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-15 23:22 +0300 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <20260815232215.00006cf8@yahoo.com> |
| In reply to | #401218 |
On Sat, 15 Aug 2026 19:39:54 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Michael S <already5chosen@yahoo.com> writes:
> >On Fri, 14 Aug 2026 21:42:38 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
> >
> >> 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.
> >>
> >
> >Why not plain 'unsigned' ?
> >
>
> Did you not read the paragraph you are responding to?
I missed the part about "using the same type". Sorry.
Now, when I read it ... no, I don't think that it is logical.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-16 14:38 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <PXjgS.6807$Z7Ef.13@fx46.iad> |
| In reply to | #401221 |
Michael S <already5chosen@yahoo.com> writes:
>On Sat, 15 Aug 2026 19:39:54 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> >On Fri, 14 Aug 2026 21:42:38 GMT
>> >scott@slp53.sl.home (Scott Lurndal) wrote:
>> >
>> >> 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.
>> >>
>> >
>> >Why not plain 'unsigned' ?
>> >
>>
>> Did you not read the paragraph you are responding to?
>
>I missed the part about "using the same type". Sorry.
>Now, when I read it ... no, I don't think that it is logical.
>
Using unsigned for the bitfields wouldn't work properly
if the modeled register is 64 bits and any of the fields
are more than 32 bits in size.
I've never liked using unadorned 'unsigned' in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-16 16:11 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <115tg3g$hmg2$1@kst.eternal-september.org> |
| In reply to | #401230 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Michael S <already5chosen@yahoo.com> writes:
>>On Sat, 15 Aug 2026 19:39:54 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
[...]
>>> >Why not plain 'unsigned' ?
>>>
>>> Did you not read the paragraph you are responding to?
>>
>>I missed the part about "using the same type". Sorry.
>>Now, when I read it ... no, I don't think that it is logical.
>
> Using unsigned for the bitfields wouldn't work properly
> if the modeled register is 64 bits and any of the fields
> are more than 32 bits in size.
If you need a bitfield wider than the width of int, of course you
have to use some implementation-defined type. There's no way to
do that portably unless you have C23. (C23 requires support for
bit-fields of bit-precise integer types, so up to at least 64 bits,
but still doesn't require support for bit-fields of type unsigned
long.)
> I've never liked using unadorned 'unsigned' in C.
I think that by "plain 'unsigned'", Michael was referring to the type,
not necessarily to how it's named. ("unsigned", "unsigned int", and
"int unsigned" are all the same type.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 16:16 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <868q673rft.fsf@linuxsc.com> |
| In reply to | #401190 |
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.
To me it seems more logical to use the smallest basic type that
suffices for the width of the associated bit-field, assuming
the compiler allows it, or 'unsigned' for compilers that don't
provide those extensions.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:34 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <1162fle$3a9$1@reader1.panix.com> |
| In reply to | #401224 |
In article <868q673rft.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>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.
>
>To me it seems more logical to use the smallest basic type that
>suffices for the width of the associated bit-field, assuming
>the compiler allows it, or 'unsigned' for compilers that don't
>provide those extensions.
You do not appear to actually write software that interfaces
directly with hardware in the manner that Scott and I (among
others) do.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-08-19 19:57 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <11651rc$19gjl$2@paganini.bofh.team> |
| In reply to | #401224 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 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.
>
> To me it seems more logical to use the smallest basic type that
> suffices for the width of the associated bit-field, assuming
> the compiler allows it, or 'unsigned' for compilers that don't
> provide those extensions.
Conider the following two structs:
typedef struct {char a:5; char b:5; char c:5;} bf1;
typedef struct {short a:5; short b:5; short c:5;} bf2;
gcc allocates 3 bytes to first one and 2 bytes for the second one.
Bitfields are frequently used to converve memory and the second
one is better in this aspect. So it is hard the avoid notion
of storage unit and using type to control size of storage unit.
Of course, if you can not count on compiler behaving in specific
way, abd you can not tolerate different behaviour, then it is better
to use access if given needed size and masks and shifts to access
the bits.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 17:31 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <864igu52jb.fsf@linuxsc.com> |
| In reply to | #401190 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-20 04:51 +0800 |
| Message-ID | <rHohS.1224206$yWz9.765340@fx04.ams4> |
| In reply to | #400174 |
On 22/06/2026 5:13 AM, Tim Rentsch wrote: > > 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? As long as both /unsigned/ and /uint32_t/ are of the same /bit width/. In DOS, you can find /unsigned/ to be 16bits and not 32bits. And in the future, I'm sure someone here in comp.lang.c, or maybe comp.arch, will make a computer with /unsigned/ as 64bits. So, it really depends on whether you want to account for the past and the future, or if you're only coding in the present; plus of course visual aesthetics, because some people find uint32_t ugly. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.c
csiph-web