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

Groups > comp.lang.c > #400174 > unrolled thread

Re: Microcontroller software stacks (was Re: this girl calls c ugly)

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.

Contents

  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 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 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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#401368 — Re: Storage needed when there are bit-field members

Scott Lurndal <scott@slp53.sl.home> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>antispam@fricas.org (Waldek Hebisch) writes:
>  <snip>
>>> Other post mentioned gcc "packed".  gcc "packed" does not
>>> respect alignment rules, so in such cases 2 byte are enough
>>> regardless of type.
>>
>>gcc "packed" can also cause quiet crashes on some systems.  It can
>>result in, for example, an int member being allocated at an odd address.
>>Passing the address of such a member to a function that assumes the
>>pointed-to object is correctly aligned can result in Bad Things
>>Happening.  (On x86, as I understand it, misaligned accesses
>>are merely somewhat slower than aligned accesses.)
> 
> In modern systems, so long as the misaligned access is
> fully contained within a single cache line, there is
> zero additional latency for the misaligned  access.

But most efficient access fetches the whole line.  If it stays
within a single cache line, then by neccessity it is aligned.

And adjective "modern" can be applied to microcontrollers.
Microcontrollers typically have word-sized data bus.  Misaligned
word sized access needs two transfers over data bus, clearly
less efficient than single access.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#401363 — Re: Storage needed when there are bit-field members

On Wed, 19 Aug 2026 15:26:14 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
> (On x86, as I understand it, misaligned accesses
> are merely somewhat slower than aligned accesses.)
> 

On all surviving general-purpose CPUs that I am aware of, not just x86. 
Not that there are many that survived.
May be, some of Chinese general-purpose designs are exception.

And in many cases it's not slower.
Typically, mis-aligned accesses become slower than aligned only when
dozens of such accesses executed in tight sequence.

[toc] | [prev] | [next] | [standalone]

#401188 — Re: Storage needed when there are bit-field members

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>> But
>>>     uint32_t bf : 1;
>>> is meaningfully different from
>>>     unsigned bf : 1;
>>>
>>> only because in most implementations (and ABIs), the underlying type
>>> of a bit field affects the layout of the entire structure.
>
> [...]
>
>>> I accept that this is the case, but it's never made any sense to me,
>>> and there's no hint of it in the C standard.
>>
>> I think saying there is not even a hint is an overstatement.  The C
>> standard says that an implementation "may allocate any addressable
>> storage unit large enough to hold a bit-field."  It shouldn't be a
>> surprise that how much storage is allocated depends on the type of
>> the bit-field member.  For example, a bit-field of type 'unsigned'
>> might very well choose a larger storage unit than what is chosen
>> for a bit-field of type '_Bool'.  It seems obvious that the type of
>> a bit-field might affect what size and layout is chosen.
>
> I'm sure it seems obvious to you.  As I said, it's not at all
> obvious to me.
>
> Prior to C99, C didn't even require compilers to support bit-field
> types other than int, unsigned int, and signed int.

True, but allowing other types was listed as a common extension.

> The declared
> type might typically be used only to determine the signedness of the
> bit-field (though I *think* most compilers permitted other types).
>
> Implementations are certainly not *required* to use the declared
> type of a bit-field as a factor in deciding how to allocate it,
> or how to allocate the rest of the structure.  Allocating just one
> byte for an isolated 1-bit bit-field of any declared type would
> be conforming.  A conforming compiler could use the declared type
> only to determine the signedness and the maximum allowed width of
> a bit-field (and its conversion behavior in the case of bool)

Yes, it could.

>>> For example, if I write:
>>>     uint64_t bf : 1;
>>>
>>> then the containing struct is typically at least 64 bits, even
>>> though those other 63 bits aren't part of the bit field and other
>>> members can be allocated within them.
>>>
>>> It would make a lot more sense *to me* if an N-bit bit field were
>>> simply N bits.
>>
>> Two problems with that.  One, it seems to be in conflict with what
>> the C standard says about 0-width bit-fields.
>
> 0-width bit-fields are obviously a special case.

Sorry for not making my point more clear.  My comment is meant to
to raise the question of whether

    struct x {
        _Bool foo:1;
        _Bool :0;
        char  c;
    };

and

    struct y {
        unsigned foo:1;
        _Bool       :0;
        char  c;
    };

should be different.  I'm inclined to think they should be, by
which I mean my preference is for compilers where they would be.

>>                                                Two, the C standard
>> explicitly allows allocating bit-fields using a high-to-low order
>> or a low-to-high order (implementation-defined choice).  Presumably
>> this freedom is given to accommodate both big- and little-endian
>> platforms.  The idea that an N-bit bit-field should simply be N
>> bits doesn't work in big-endian environments.  It seems better to
>> allow little-endian implementations to choose a size that matches
>> what a big-endian implementation would use, rather than insisting
>> that they be different.
>
> I honestly don't understand your point here.  How does making
> N-bit bit-fields N bits not work in a big-endian environment?
> Can you elaborate?  Of course endianness can affect how bit-fields
> are allocated within a "storage unit".

Suppose we have a little endian machine where bit-fields are
allocated in a high-to-low order.  Further suppose that unsigned
ints are 32 bits.  In such an environment, I would expect (or
prefer) a definition like this

    struct foo {
        unsigned x:15;
    };

to be represented like so

    --------  --------  -XXXXXXX  XXXXXXXX

where the X's indicate where the bit-field goes, and the -'s
indicate where there are padding bits.  In such an environment,
I would find it counterintuitive if this type were represented
thus

    -XXXXXXX  XXXXXXXX

rather than as shown in the previous layout.

[toc] | [prev] | [next] | [standalone]

#400187

In article <86h5mv8umk.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>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?

No.  There are issues of alignment and padding one must consider
when using bitfields to model hardware registers, particularly
if (say) a device driver is meant to be shared across ISAs.

Using the exact width types really does make a difference; it's
IB what those properties are, though we're usually at the mercy
of the target platform's ABI anyway at that point.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#400193

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <86h5mv8umk.fsf@linuxsc.com>,
>Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>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?
>
>No.  There are issues of alignment and padding one must consider
>when using bitfields to model hardware registers, particularly
>if (say) a device driver is meant to be shared across ISAs.

That's a good choice of verb (model).

As it happens, the primary use of this data structure is not
to handle direct accesses to the hardware registers, but rather
to model them in a simulation.  So when the simulated CPU
accesses the register, after determining the target address
is assigned to the SATA controller GBL_OOB register, the
SATA device model code (which hosts the register) will access
the bitfields individually by name when implementing the
semantics of a store to that register by the simulated CPU
(which will typically be running the linux SATA driver).

Far more maintainable and readable than manipulating the bit fields
with shift and mask operations.

  e.g.

    if (gbl_oobr.s.we) {  /* Writes are enabled */
       /* do it */
    }

is better in all respects than

   if (gbl_oobr & 1)    /* LE */
or 
   if (gbl_oobr & (1 << 31)) /* BE */
or even
   if (gbl_oobr & (1 << WRITE_ENABLE_BIT_OFFSET)) 


Of course the data structure can also be used by a real
hardware device driver, with the caveat that the contents
of the hardware register is loaded explicitly into the '.u'
member by the driver before accessing the bitfields.

[toc] | [prev] | [next] | [standalone]

#401177

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86h5mv8umk.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> 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?
>
> No.  There are issues of alignment and padding one must consider
> when using bitfields to model hardware registers, particularly
> if (say) a device driver is meant to be shared across ISAs.
>
> Using the exact width types really does make a difference;  it's
> IB what those properties are, though we're usually at the mercy
> of the target platform's ABI anyway at that point.

The motivation for my query was not to ask an abstract theoretical
question but a specific and pragmatic one.

[toc] | [prev] | [next] | [standalone]

#401310

In article <861pc078pc.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <86h5mv8umk.fsf@linuxsc.com>,
>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>
>>> 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?
>>
>> No.  There are issues of alignment and padding one must consider
>> when using bitfields to model hardware registers, particularly
>> if (say) a device driver is meant to be shared across ISAs.
>>
>> Using the exact width types really does make a difference;  it's
>> IB what those properties are, though we're usually at the mercy
>> of the target platform's ABI anyway at that point.
>
>The motivation for my query was not to ask an abstract theoretical
>question but a specific and pragmatic one.

My response was practical and pragmatic, and arises in code that
is written by real-world systems programmers.

I understand that is not your domain of expertise.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#400192

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.

There are other hardware registers in our implementation of the SATA
controller that are defined as 64-bit registers, for those we use
uint64_t (rather than relying on 'unsigned long' for 64-bit linux
or 'unsigned long long' for 32-bit OS - and this code was designed
to be compiled for both 32-bit and 64-bit targets originally).

[toc] | [prev] | [next] | [standalone]

#400197

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> There are other hardware registers in our implementation of the SATA
> controller that are defined as 64-bit registers, for those we use
> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
> or 'unsigned long long' for 32-bit OS - and this code was designed
> to be compiled for both 32-bit and 64-bit targets originally).

You could have used unsigned long long for both.  I agree that using
uint64_t is better if you specifically need 64 bits.

-- 
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]

#401174 — Re: Microcontroller software stacks

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?

> There are other hardware registers in our implementation of the SATA
> controller that are defined as 64-bit registers, for those we use
> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
> or 'unsigned long long' for 32-bit OS - and this code was designed
> to be compiled for both 32-bit and 64-bit targets originally).

Sure, for the non-bitfield member.  My question is only about
(unsigned) bitfields all of width 8 or less.

[toc] | [prev] | [next] | [standalone]

#401184 — Re: Microcontroller software stacks

On 15/08/2026 3:51 AM, Tim Rentsch wrote:
> 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?

Yes, people still code real mode DOS for fun and amusement.  Not to
mention boot strapping code for /real operating systems/, for some value
of /real/.

On 6502, int is 16bit, I believe, for reasons.  And I also believe it
makes total sense to keep int 16bit on a 68000.

> 
>> There are other hardware registers in our implementation of the SATA
>> controller that are defined as 64-bit registers, for those we use
>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>> or 'unsigned long long' for 32-bit OS - and this code was designed
>> to be compiled for both 32-bit and 64-bit targets originally).
> 
> Sure, for the non-bitfield member.  My question is only about
> (unsigned) bitfields all of width 8 or less.

I'm ignorant of the prior discussion, so I'll stop now; happy retro-
coding!
-- 
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] | [next] | [standalone]

#401193 — Re: Microcontroller software stacks

On 14/08/2026 22:02, Johann 'Myrkraverk' Oskarsson wrote:
> On 15/08/2026 3:51 AM, Tim Rentsch wrote:
>> 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?
> 
> Yes, people still code real mode DOS for fun and amusement.  Not to
> mention boot strapping code for /real operating systems/, for some value
> of /real/.
> 
> On 6502, int is 16bit, I believe, for reasons.  And I also believe it
> makes total sense to keep int 16bit on a 68000.
> 

WTF are you on about? If you're an actual human then I suggest getting 
some help. If not then where the hell does all this bilge come from?


>>> There are other hardware registers in our implementation of the SATA
>>> controller that are defined as 64-bit registers, for those we use
>>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>>> or 'unsigned long long' for 32-bit OS - and this code was designed
>>> to be compiled for both 32-bit and 64-bit targets originally).
>>
>> Sure, for the non-bitfield member.  My question is only about
>> (unsigned) bitfields all of width 8 or less.
> 
> I'm ignorant of the prior discussion, so I'll stop now; happy retro-
> coding!

'Happy' - OK, CMT has finally convinced me!

[toc] | [prev] | [next] | [standalone]

#401228 — Re: Microcontroller software stacks

On 15/08/2026 8:18 AM, bart wrote:
> On 14/08/2026 22:02, Johann 'Myrkraverk' Oskarsson wrote:
>> On 15/08/2026 3:51 AM, Tim Rentsch wrote:
>>> 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?
>>
>> Yes, people still code real mode DOS for fun and amusement.  Not to
>> mention boot strapping code for /real operating systems/, for some value
>> of /real/.
>>
>> On 6502, int is 16bit, I believe, for reasons.  And I also believe it
>> makes total sense to keep int 16bit on a 68000.
>>
> 
> WTF are you on about? If you're an actual human then I suggest getting 
> some help. If not then where the hell does all this bilge come from?


Hey bart!  You fucking piece of shit asshole.  Tim asked a question.  I
answered it.  There is a difference between 'unsigned' and 'uint32_t' on
DOS, you fucking piece of shit know-nothing slob burger.

Now, if Tim decides real mode DOS is not a target for his own question,
then he should be answering with a polite followup, or spew his own
hatred, and not you, you miserable psychopath!


>>>> There are other hardware registers in our implementation of the SATA
>>>> controller that are defined as 64-bit registers, for those we use
>>>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>>>> or 'unsigned long long' for 32-bit OS - and this code was designed
>>>> to be compiled for both 32-bit and 64-bit targets originally).
>>>
>>> Sure, for the non-bitfield member.  My question is only about
>>> (unsigned) bitfields all of width 8 or less.
>>
>> I'm ignorant of the prior discussion, so I'll stop now; happy retro-
>> coding!
> 
> 'Happy' - OK, CMT has finally convinced me!

Happy living in alt.fantasy, you fucking piece of shit!
-- 
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] | [next] | [standalone]

#401186 — Re: Microcontroller software stacks

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> 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?

On platforms where unsigned int is 32 bits, I'd be very surprised
if it made any difference.  If unsigned it is, say, 16 or 64 bits,
it can make a difference.

As I wrote here a while ago, "Implementions commonly use the declared
type of a bit-field to affect the layout, not necessarily of the
bit-field itself, but of the containing structure."  This was in
a thread with the subject "Storage needed when there are bit-field
members", in a followup to your post a few days after the article
to which you've just replied.

On the other hand, the standard only requires support for
bitfields of declared types int, signed int, unsigned int, and bool
(and bit-precise integer types in C23 and later); a conforming
implementation might not support bit-fields of type uint32_t.

-- 
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]

#401190 — Re: Microcontroller software stacks

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.

[toc] | [prev] | [next] | [standalone]

#401217 — Re: Microcontroller software stacks

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' ?

[toc] | [prev] | [next] | [standalone]

#401218 — Re: Microcontroller software stacks

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?

[toc] | [prev] | [next] | [standalone]

#401221 — Re: Microcontroller software stacks

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]

#401230 — Re: Microcontroller software stacks

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]

#401242 — Re: Microcontroller software stacks

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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web