[TUHS] Any UNIX With No C In Userland?

[segaloco via TUHS]

On Wednesday, March 5th, 2025 at 8:14 AM, jnc at mercury.lcs.mit.edu <jnc at mercury.lcs.mit.edu> wrote:

> > From: Rob Pike
> 
> 
> > The notion that the struct layout must correspond to the hardware
> 
> > device's layout is about as non-portable as thinking can get.
> 
> 
> I'm confused; I thought device register layout is inherently about as
> non-portable a thing as one could have, generally.
> 
> (Exceptions: 1) the device is basically a single chip, so interfaces on two
> machines might be essentially identical, if they use the same chip; 2) someone
> made a 68K card that plugged into a QBUS, so drivers on a PDP-11 and that 68K
> could be identical.)
> 
> Or did you mean that one could somehow disassociate the struct layout and the
> details of the device (assuming it has addressable registers, as became
> common)? How (I'm missing it)?
> 
> Noel

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.