Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Microcontroller software stacks Date: Fri, 14 Aug 2026 12:51:32 -0700 Organization: A noiseless patient Spider Lines: 56 Message-ID: <865x1c7a63.fsf@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <10vjsg2$259m3$3@dont-email.me> <10vkk65$l8v$1@reader1.panix.com> <10vlvie$2ne3j$2@dont-email.me> <10vmh2e$b44$1@reader1.panix.com> <86h5mv8umk.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 14 Aug 2026 19:51:35 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2956047"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hkXTJUlu0gcy/0KFdtq8kOveYjPrSAcI="; posting-host="34d543ba31754db8d869ebd4dc5daf69" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:tTAK69YXVRCaJbEHzjNtpEeBdHA= sha1:hzDOrp6msxcvb2ZSR5mqqVyQ6dQ= sha256:pnoPFWHHyvHJA6rBps7Fkz9V7wSIHk2sauFKSBDYrwo= sha1:lOigPrXRCsD1MqMy0hLp5HpNlRk= sha256:7Ma3LhBomi/pVRncMfTkh5Po6NdetkFEIeO2hV7Bhxo= Xref: csiph.com comp.lang.c:401174 scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch 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.