On Wednesday, March 5th, 2025 at 8:14 AM, jnc(a)mercury.lcs.mit.edu <jnc(a)mercury.lcs.mit.edu> wrote: I got thinking about this more after seeing Rob's reply, it does make sense the more I ponder on it now. While it'd be nice to hand that info to the language and have compilation handle all the details, given that endianness is already an issue, it's a steep order to expect any of the other details of mapping onto a set of registers to actually be easily facilitated. Basically unless the struct can perfectly capture *everything*, in other words, operand size, bit ordering, volatility, padding, and so on, the fact that any assumptions may be made at all precludes trusting a struct to be the means for describing a hardware interface. As much as it may pain one (such as myself...) to put in all the serialization logic for data, expecting any old C compiler to be built with that in mind when it isn't a requirement for the language may be a fool's errand. It is nice when it works out that way on a specific machine and your code need not be portable though. Basically it's a happy accident when it does work, but not an indictment of the language when it doesn't. Plus while C may have grown up with the PDP-11 UNIX kernel, it grew wings and soared in userland applications, of which interacting with hardware I/O registers isn't really an expected application. IBM tried the divorce of user and system code with the PL/I vs PL/S exercise, and one only need take a look around to see what impact that materially had on the longevity of the languages. This sort of discussion really makes me appreciate this list, these are perspectives I don't often find elsewhere outside of footnotes in places I wouldn't know to search for. - Matt G.