[TUHS] Re: Any UNIX With No C In Userland?

[TUHS] Re: Any UNIX With No C In Userland?

[Noel Chiappa]

    > From: Phil Budne

    > BUT, the basic TCP and IP protocols seem to have been created with a
    > general care that two byte fields should be aligned at multiples of two
    > bytes

Yes, because dealing with a 16-bit field that spans two PDP-11 16-bit words
is a pain (espcially because the PDP-11 does not have a 'load byte into
register _without_ extending the sign bit into the high half' instruction).

Do realize that in addition to the early TCP implementation, the _first_ TCP
router (at that stage, TCP and IP were not separate protocols) was also a
PDP-11 (albeit programmed in BCPL, not MACRO-11).

I remember the extension being a real PITA. To load an un-aligned 16-bit
quantity into R0, one would have had to do something like (assuming a pointer
to the un-aligned 16-bit quantity was in R1):

	MOVB	(R1)+, R0
	SWAB	R0
	BIC	#0377, R0
	BISB	(R1)+, R0

There may have been a better way to do it, but that's the best I can come up
with now; I recall we had to do something like that.

Yes, the 16-bit fields were 16-bit word aligned.

	Noel

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Thu, Mar 6, 2025 at 1:23 AM Lars Brinkhoff <lars@nocrew.org> wrote:
> Dan Cross writes:
> > John Levine wrote:
> >> I believe the earliest versions of C were on a GE 635, a word addressed
> >> machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
> > This is a startling claim that I have never heard before. [...] C did
> > not appear until they were solidly on the PDP-11, and was developed on
> > that machine. The earliest connections to other machines were Dennis
> > Ritchie constructing a cross-compiler for B that ran on the PDP-7
>
> Whilst I agree the claim is startling, there is a connection between
> early C and the GE 635.  The little known Snyder C compiler has back
> ends for the PDP-10, PDP-11, and Honeywell 6000 series (nee GE 635).
>
> https://github.com/PDP-10/Snyder-C-compiler/blob/master/MAC-TR-149.pdf
>
> I believe this compiler was started when Snyder visited Bell Labs in
> 1973, and it comes with a very archaic version of Yacc.

Interesting. I wonder if this is the basis for Dennis mentioning the
GE-635 port in the C history paper?

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Wed, Mar 5, 2025 at 11:03 PM John Levine <johnl@taugh.com> wrote:


>
> I believe the earliest versions of C were on a GE 635, a word addressed
> machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
> where the byte and word addresses motivated the datatypes that turne
>
>  I believe the history is this....  Ken write the original B
interpreter/subsystem for in Assembl;er (see the Unix V0 stuff).  Dennis
write a new B compiler in B.   That was moved the GE635 (and Steve Johnson
brought it with him to Waterloo).   When the PDP-11 came, Dennis started
change the compiler to add features for the PDP-11.  This was originally
called "New B" (or nb).  He used  a continuous development scheme.
Originally, nb could accept B, but ass Dennis added more and more features
that were not compatible (basically as typing was added), nb became so
different it was renamed C.

Johnson's comment was that by the time he returned from Waterloo, no one
was using B anymore.

At some point, Synder (who was a summer student) wrote a C compiler for the
PDP-10.  I am unclear if that was before the Honeywell 6000 back end,
although given the dates, if you look at the code repositories, I >>think<<
it was.  FWIW: by 1978, Dennis and Brian do not mention the PDP-10 on page
179 of K&R — only the PDP-11, Honeywell, IBM 360/370 and Interdata 8/32.
ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 3162 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Noel Chiappa]

    > There may have been a better way to do it

	CLR	R0
	BISB	(R1)+, R0
	SWAB	R0
	BISB	(R1)+, R0

That saved one instruction over the previous one.

	Noel

[TUHS] Re: Any UNIX With No C In Userland?

[Lars Brinkhoff]

Dan Cross writes:
> John Levine wrote:
>> I believe the earliest versions of C were on a GE 635, a word addressed
>> machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
> This is a startling claim that I have never heard before. [...] C did
> not appear until they were solidly on the PDP-11, and was developed on
> that machine. The earliest connections to other machines were Dennis
> Ritchie constructing a cross-compiler for B that ran on the PDP-7

Whilst I agree the claim is startling, there is a connection between
early C and the GE 635.  The little known Snyder C compiler has back
ends for the PDP-10, PDP-11, and Honeywell 6000 series (nee GE 635).

https://github.com/PDP-10/Snyder-C-compiler/blob/master/MAC-TR-149.pdf

I believe this compiler was started when Snyder visited Bell Labs in
1973, and it comes with a very archaic version of Yacc.

[TUHS] Re: Any UNIX With No C In Userland?

[John Levine]

I thought Dennis said he didn’t the work on the 635 but you’re right, C was mostly on the Pdp-11 and then targeted back to the 635.

Please consider the environment before reading this message.
John Levine, johnl@taugh.com 

> On Mar 5, 2025, at 23:36, Dan Cross <crossd@gmail.com> wrote:
> 
> On Wed, Mar 5, 2025 at 11:11 PM John Levine <johnl@taugh.com> wrote:
>>> snip
>>> And as for C: It was born on a 16-bit word system that expected 16-bit
>>> aligned words, replacing B, a language with just the word datatype, on
>>> a system with a 32KB (or less) user space, by people who had just come
>>> from a project where waiting for working production PL/I compiler had
>>> been a major headache, and generally suffered from "second system
>>> syndrome" bloat.
>> 
>> I believe the earliest versions of C were on a GE 635, a word addressed
>> machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
>> where the byte and word addresses motivated the datatypes that turned
>> B into C.
> 
> This is a startling claim that I have never heard before. Can you cite
> a source for this?
> 
> The history as recounted in Dennis Ritchie's paper on the history of C
> (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf) is
> that the initial bootstrapping of PDP-7 Unix was done by
> cross-assembling on a GE-635, with paper-tape hand carried to the PDP.
> B appears to have been an invention that began life on the PDP-7 and
> was subsequently ported to the PDP-11. But C did not appear until they
> were solidly on the PDP-11, and was developed on that machine. The
> earliest connections to other machines were Dennis Ritchie
> constructing a cross-compiler for B that ran on the PDP-7; as he
> described it:
> 
> |The most ambitious enterprise I undertook was a genuine cross-compiler
> |that translated B to GE-635 machine instructions, not threaded code. It was
> |a small tour de force: a full B compiler, written in its own language and
> |generating code for a 36-bit mainframe, that ran on an 18-bit machine with
> |4K words of user address space.
> 
> C was later ported to GE-635 and IBM 370, but there's no indication
> it was created on the GE-635.
> 
>        - Dan C
> 

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Wed, Mar 5, 2025 at 11:11 PM John Levine <johnl@taugh.com> wrote:
>>snip
> >And as for C: It was born on a 16-bit word system that expected 16-bit
> >aligned words, replacing B, a language with just the word datatype, on
> >a system with a 32KB (or less) user space, by people who had just come
> >from a project where waiting for working production PL/I compiler had
> >been a major headache, and generally suffered from "second system
> >syndrome" bloat.
>
> I believe the earliest versions of C were on a GE 635, a word addressed
> machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
> where the byte and word addresses motivated the datatypes that turned
> B into C.

This is a startling claim that I have never heard before. Can you cite
a source for this?

The history as recounted in Dennis Ritchie's paper on the history of C
(https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf) is
that the initial bootstrapping of PDP-7 Unix was done by
cross-assembling on a GE-635, with paper-tape hand carried to the PDP.
B appears to have been an invention that began life on the PDP-7 and
was subsequently ported to the PDP-11. But C did not appear until they
were solidly on the PDP-11, and was developed on that machine. The
earliest connections to other machines were Dennis Ritchie
constructing a cross-compiler for B that ran on the PDP-7; as he
described it:

|The most ambitious enterprise I undertook was a genuine cross-compiler
|that translated B to GE-635 machine instructions, not threaded code. It was
|a small tour de force: a full B compiler, written in its own language and
|generating code for a 36-bit mainframe, that ran on an 18-bit machine with
|4K words of user address space.

 C was later ported to GE-635 and IBM 370, but there's no indication
it was created on the GE-635.

        - Dan C

[TUHS] Re: Any UNIX With No C In Userland?

[John Levine]

It appears that Phil Budne <phil@ultimate.com> said:
>Noel Chiappa wrote:
>>     > From: Larry McVoy
>>
>>     > Not once did I think about packing, the structs somehow just worked on
>>     > the machines I was working on. Maybe the TCP/IP guys knew about spacing
>>     > in the structs.
>>
>> Not really! Of the first 6 TCP/IP implementations:
>> only 1 was in C - and it was a relatively late one. The earliest ones were
>> mostly in assembler (PDP-10 and PDP-11).
>
>BUT, the basic TCP and IP protocols seem to have been created with a
>general care that two byte fields should be aligned at multiples of
>two bytes and four byte fields should be at multiples of four bytes,
>or at the VERY least, no multi-byte field should cross a four byte
>boundary (which would have been a pain to PDP-10 programmers who
>likely expected 32 bits of data in each 36 bit word).

There were a bunch of S/360 systems, which also need two- and
four-byte fiekds to be aligned unless you do extra byte string moves
to pack and unpack the structures.

>And as for C: It was born on a 16-bit word system that expected 16-bit
>aligned words, replacing B, a language with just the word datatype, on
>a system with a 32KB (or less) user space, by people who had just come
>from a project where waiting for working production PL/I compiler had
>been a major headache, and generally suffered from "second system
>syndrome" bloat.

I believe the earliest versions of C were on a GE 635, a word addressed
machine comparable to a PDP-10.  But it moved to a PDP-11 soon enough
where the byte and word addresses motivated the datatypes that turned
B into C.

R's,
John

[TUHS] Re: Any UNIX With No C In Userland?

[Phil Budne]

Noel Chiappa wrote:
>     > From: Larry McVoy
>
>     > Not once did I think about packing, the structs somehow just worked on
>     > the machines I was working on. Maybe the TCP/IP guys knew about spacing
>     > in the structs.
>
> Not really! Of the first 6 TCP/IP implementations:
> only 1 was in C - and it was a relatively late one. The earliest ones were
> mostly in assembler (PDP-10 and PDP-11).

BUT, the basic TCP and IP protocols seem to have been created with a
general care that two byte fields should be aligned at multiples of
two bytes and four byte fields should be at multiples of four bytes,
or at the VERY least, no multi-byte field should cross a four byte
boundary (which would have been a pain to PDP-10 programmers who
likely expected 32 bits of data in each 36 bit word).

IP and TCP Options may blow that out of the water, I don't recall.

ISTR that in the IL protocol (atop IP) in early Plan9, the four byte
sequence numbers would cross over the lines in a traditional RFC box
diagram.

And for early TCP/IP networking and alignment pain (with Unibus!):

I briefly looked at gluing the TCP/IP stack in MIT-ITS for the 2020
(KS10, a PDP-10) which had a Unibus, to the driver someone had written
a Unibus Interlan NI1010 card, BUT the 14 byte Ethernet header meant
the 32-bit words in the TCP and IP headers landed across the (36 bit)
word boundaries expected by ITS' TCP stack (that had been written to
speak to IMPs).  There might have been an (MIT added?) BLT to move
8-bit bytes around (or the DEC EXTEND MOVSLJ might have been
available), but it was too gross to contemplate... I suppose Berkeley
trailers might have solved the problem (had I known about them at the
time, but.... also gross).

And as for C: It was born on a 16-bit word system that expected 16-bit
aligned words, replacing B, a language with just the word datatype, on
a system with a 32KB (or less) user space, by people who had just come
from a project where waiting for working production PL/I compiler had
been a major headache, and generally suffered from "second system
syndrome" bloat.

I think it's fair to say that the essence of UNIX and the brilliance
of the development team (largely lost on modern developers) was to
make it as simple as possible, but no simpler.

IMO judging Unix, C and it's creators by criteria like "how could they
not have anticipated my alignment problems" (or why isn't C like PL/I)
is armchair quarterbacking.  If you feel otherwise, maybe you should
travel back in time and join the Unix-Haters mailing list, or at least
not be on this one, insulting people who were involved, and are kind
enough to put up with our inane blathering...

[TUHS] Re: Any UNIX With No C In Userland?

[segaloco via TUHS]

On Wednesday, March 5th, 2025 at 8:14 AM, jnc@mercury.lcs.mit.edu <jnc@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.

[TUHS] Re: Any UNIX With No C In Userland?

[Noel Chiappa]

    > 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 

[TUHS] Re: Any UNIX With No C In Userland?

[Christian Hopps]

Konstantin Belousov via TUHS <tuhs@tuhs.org> writes:

> ...
> Then, after some time, but long time ago, all Unix-like systems converged
> to just two practically observable ABIs: ILP32 and LP64.  Both of them
> require 8bit bytes, byte addressability, natural alignment for the basic
> integer types, and equiality of uint8_t/unsigned char, uint16_t/short,
> uint32_t/long.

I think you mean uint32_t/int; `long` is 32 bits in IPL32 and 64 bits in LP64, indeed the name LP64 stands for Long and Pointer 64 :)

Thanks,
Chris.

[TUHS] Re: Any UNIX With No C In Userland?

[Chet Ramey via TUHS]

On 3/5/25 9:26 AM, Henry Bent wrote:

>     This would have been 1991-1992, so we were working on mostly 4.3 BSD (me)
>     and SunOS (Brian). We didn't expect more than K&R from the compiler, even
>     though we were primarily using gcc. It was before autoconf, so we rolled
>     our own version to create a `sysdefs.h', and had code to choose between
>     POSIX, USG, and BSD versions of functions. I don't think it would have
>     compiled on anything older than possibly 4.2 BSD, and probably not that,
>     so I think your speculation about the post-V7 runtime support is on the
>     mark.
> 
> 
> I have bash-2.04 running on 4.1C BSD.

Nice! I haven't done much software archaeology like that.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Re: Any UNIX With No C In Userland?

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Wed, 5 Mar 2025 at 09:15, Chet Ramey via TUHS <tuhs@tuhs.org> wrote:

> On 3/4/25 4:55 PM, Rob Gingell wrote:
>
> > On 3/4/25 7:07 AM, Chet Ramey via TUHS wrote:
> >> We expected a lot less from the system and compiler in the bash-1.12
> days;
> >> that helped here.
> >
> > How would those expectations differ from what V7 provided, as PAUNIX's
> > ambitions only went that far (not that they couldn't be expanded but...)
> > The thing is the Harrenstein C must've gotten more complete runtime
> support
> > to run 1.12 and seems like that'd exceed V7 and make PAUNIX even more
> futile.
>
> This would have been 1991-1992, so we were working on mostly 4.3 BSD (me)
> and SunOS (Brian). We didn't expect more than K&R from the compiler, even
> though we were primarily using gcc. It was before autoconf, so we rolled
> our own version to create a `sysdefs.h', and had code to choose between
> POSIX, USG, and BSD versions of functions. I don't think it would have
> compiled on anything older than possibly 4.2 BSD, and probably not that,
> so I think your speculation about the post-V7 runtime support is on the
> mark.


I have bash-2.04 running on 4.1C BSD.  I don't remember whether I used
gcc-1.42 or gcc-2.81 to build it, but it was one of the two.  In my
experience 2.04 is the last version that will successfully build and run on
many very older systems, though I believe there are a few where I was not
able to get past 1.14.  At least on 4.1C, I've successfully used 2.04 to
run all sorts of configure scripts and I don't remember ever having run
into significant issues.

-Henry

[-- Attachment #2: Type: text/html, Size: 2039 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Chet Ramey via TUHS]

On 3/4/25 4:55 PM, Rob Gingell wrote:

> On 3/4/25 7:07 AM, Chet Ramey via TUHS wrote:
>> We expected a lot less from the system and compiler in the bash-1.12 days;
>> that helped here.
> 
> How would those expectations differ from what V7 provided, as PAUNIX's 
> ambitions only went that far (not that they couldn't be expanded but...) 
> The thing is the Harrenstein C must've gotten more complete runtime support 
> to run 1.12 and seems like that'd exceed V7 and make PAUNIX even more futile.

This would have been 1991-1992, so we were working on mostly 4.3 BSD (me)
and SunOS (Brian). We didn't expect more than K&R from the compiler, even
though we were primarily using gcc. It was before autoconf, so we rolled
our own version to create a `sysdefs.h', and had code to choose between
POSIX, USG, and BSD versions of functions. I don't think it would have
compiled on anything older than possibly 4.2 BSD, and probably not that,
so I think your speculation about the post-V7 runtime support is on the
mark.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Re: Any UNIX With No C In Userland?

[Konstantin Belousov via TUHS]

Sorry for dup, resent from the subscribed address.

On Tue, Mar 04, 2025 at 07:15:42PM -0800, Larry McVoy wrote:
> On Wed, Mar 05, 2025 at 10:54:01AM +1100, Rob Pike wrote:
> > The notion that the struct layout must correspond to the hardware device's
> > layout is about as non-portable as thinking can get.
> 
> I agree but as a side note, I ported Lachman's (nee Convergent I believe)
> TCP/IP stack to ETA-10's Sys V OS and to SCO's v7 or whatever they had.
> Somewhere I have a note book where I laid out in structs every packet
> format with notes about what that packet did, I was learning.
> 
> Not once did I think about packing, the structs somehow just worked on
> the machines I was working on.  Maybe the TCP/IP guys knew about spacing
> in the structs.
> 
> I get it, I was naive, but sometimes the structs work.

All questions about type sizes and alignment, as well as the layout of
structures, are defined by platform ABI.  Any useful compiler for C
would follow ABI, and any non-C compiler hoping to interoperate with
the system libraries, would provide some way to communicate using the ABI.

Then, after some time, but long time ago, all Unix-like systems converged
to just two practically observable ABIs: ILP32 and LP64.  Both of them
require 8bit bytes, byte addressability, natural alignment for the basic
integer types, and equiality of uint8_t/unsigned char, uint16_t/short,
uint32_t/long.

From there, it is easy to see that e.g. layout of most ip protocol packets
can be trivially written as C structs.  The only trouble there is the
need to align whole incoming packets on suitable boundary, but e.g. for
IP/TCP/UDP the 4-bytes is enough, and most hardware enforces it.

[TUHS] Re: Any UNIX With No C In Userland?

[Noel Chiappa]

    > From: Larry McVoy

    > Not once did I think about packing, the structs somehow just worked on
    > the machines I was working on. Maybe the TCP/IP guys knew about spacing
    > in the structs.

Not really! Of the first 6 TCP/IP implementations:

   https://gunkies.org/wiki/TCP_and_IP_bake_offs

only 1 was in C - and it was a relatively late one. The earliest ones were
mostly in assembler (PDP-10 and PDP-11).

	Noel

[TUHS] Re: Any UNIX With No C In Userland?

[Chris Hanson]

On Mar 1, 2025, at 1:51 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
> 
> segaloco via TUHS writes:
>> Given that anything that obeys the ABI and has assembler entries to the ker=
>> nel
>> can request services, it seems to me it would be possible to stand up a
>> user-land without C being present.  Have any UNIXen ever done this after th=
>> e
>> advent of C?
> 
> SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> and made it a $$$ add on.  That move single-handedly made GCC the
> reference compiler moving forward.


SunOS still included their K&R compiler for kernel tuning, as well as all of the header files. It was both sufficient for hacking and sufficient for bootstrapping GCC if you needed an ANSI compiler.

  -- Chris

[TUHS] Re: Any UNIX With No C In Userland?

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

At Wed, 5 Mar 2025 10:54:01 +1100, Rob Pike <robpike@gmail.com> wrote:
Subject: [TUHS] Re: Any UNIX With No C In Userland?
>
> The notion that the struct layout must correspond to the hardware device's
> layout

Not "must" -- "can".

Of course that's just effectively using the compiler to do the
marshalling -- at compile time.

There are caveats of course -- one can lay out bit flags for a register
in a struct, but one must not make a pointer to such a struct and point
it at the register and expect bit manipulations to work -- even with -O0
you'll probably mess up any attempts to change bits predictably in that
register in ways that the hardware expects.

Of course the same problems occur if you try to point a word-sized
integer, even one with a "volatile" qualifier, at a register and
manipulate its bits with C bitwise expressions.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Wed, Mar 05, 2025 at 10:54:01AM +1100, Rob Pike wrote:
> The notion that the struct layout must correspond to the hardware device's
> layout is about as non-portable as thinking can get.

I agree but as a side note, I ported Lachman's (nee Convergent I believe)
TCP/IP stack to ETA-10's Sys V OS and to SCO's v7 or whatever they had.
Somewhere I have a note book where I laid out in structs every packet
format with notes about what that packet did, I was learning.

Not once did I think about packing, the structs somehow just worked on
the machines I was working on.  Maybe the TCP/IP guys knew about spacing
in the structs.

I get it, I was naive, but sometimes the structs work.

[TUHS] Re: Any UNIX With No C In Userland?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Not if you do it well. Plan 9 did it and it was easy.

The notion that the struct layout must correspond to the hardware device's
layout is about as non-portable as thinking can get.

-rob


On Wed, Mar 5, 2025 at 8:27 AM Greg A. Woods <woods@robohack.ca> wrote:

> At Tue, 04 Mar 2025 06:37:56 +0000, Lars Brinkhoff <lars@nocrew.org>
> wrote:
> Subject: [TUHS] Re: Any UNIX With No C In Userland?
> >
> > I NEVER EVER use C structs or bit fields for this.  I get the raw octets
> > (or whatever the byte size is), and shift and mask accordingly to get
> > the data fields.
>
> Marshalling data in or out byte by byte is of course safe and is
> definitely the most portable way, and one can of course still read or
> write "record"-length amounts of bytes at one time (or multiples of
> records).  It just can be a little more tedious.
>
> --
>                                         Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>
>

[-- Attachment #2: Type: text/html, Size: 2224 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Rob Gingell]

On 3/3/25 10:46 PM, Lars Brinkhoff wrote:
> Rob Gingell wrote:
>> Yes, the Harrenstein C was the one we'd expected to use and were
>> playing with at the time. We'd tried the Snyder compiler and one other
>> I don't recall right now as well.
> 
> Probably Jay Lepreau's PCC from Utah, or maybe Sargasso C.

Yes, Jay's was I was thinking of. I'm embarrassed to have spaced on 
that, Jay was such a presence in both the TOPS-20 and UNIX worlds, 
thanks for reminding me.

On 3/4/25 7:07 AM, Chet Ramey via TUHS wrote:
> We expected a lot less from the system and compiler in the bash-1.12 days;
> that helped here.

How would those expectations differ from what V7 provided, as PAUNIX's 
ambitions only went that far (not that they couldn't be expanded but...) 
The thing is the Harrenstein C must've gotten more complete runtime 
support to run 1.12 and seems like that'd exceed V7 and make PAUNIX even 
more futile.

On 3/3/25 10:40 PM, Lars Brinkhoff wrote:
> Please!  At the very least, can you put the code online?

It seems likely to be just a novelty and of no real use (and given the 
above, not necessary) but putting it online would be fine.

The code is copyrighted/licensed by CWRU (and in some cases, both CWRU 
and me) and that should get cleaned up. At the time this work was done 
in the early 1980's, we had what was really a naive and clumsy view of 
how to go about it all. By today's expectations it looks more 
restrictive than anyone intended.

I'll go get that cleaned up and follow-up with you (Lars) about going 
forward.

[TUHS] Re: Any UNIX With No C In Userland?

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

At Tue, 04 Mar 2025 06:37:56 +0000, Lars Brinkhoff <lars@nocrew.org> wrote:
Subject: [TUHS] Re: Any UNIX With No C In Userland?
>
> I NEVER EVER use C structs or bit fields for this.  I get the raw octets
> (or whatever the byte size is), and shift and mask accordingly to get
> the data fields.

Marshalling data in or out byte by byte is of course safe and is
definitely the most portable way, and one can of course still read or
write "record"-length amounts of bytes at one time (or multiples of
records).  It just can be a little more tedious.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Chet Ramey via TUHS]

On 3/3/25 7:02 PM, Rob Gingell wrote:

> Glad to see it developed enough to get bash compiled, very cool, thanks for 
> pointing it out!

We expected a lot less from the system and compiler in the bash-1.12 days;
that helped here.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Re: Any UNIX With No C In Userland?

[Lars Brinkhoff]

Rob Gingell wrote:
> Dan Cross wrote:
>> As an aside, Ken Harrenstein wrote a C compiler for the PDP-10

KCC, started by Kok Chen at the Stanford AI lab.

> Yes, the Harrenstein C was the one we'd expected to use and were
> playing with at the time. We'd tried the Snyder compiler and one other
> I don't recall right now as well.

Probably Jay Lepreau's PCC from Utah, or maybe Sargasso C.

[TUHS] Re: Any UNIX With No C In Userland?

[Lars Brinkhoff]

> Although, with my PiDP-10 running TOPS-20, a fun exercise in nostalgic
> futility might be to haul PAUNIX out of the closet and try to finish
> it.

Please!  At the very least, can you put the code online?

[TUHS] Re: Any UNIX With No C In Userland?

[Lars Brinkhoff]

Noel Chiappa writes:
> The area I'm thinking of (and which I saw a lot of) is code to implement
> network protocols (and I'm fairly astounded that nobody else has mentioned
> this yet).

Network packets, tape records, disk images.  It's a bit off-topic, so I
have tried to stay silent.

> One has to have _absolute_ control over how the bits are laid out
> in the packet (which of course might wind up in any one of countless other
> machine types) - which generally means how they are laid out in memory.
> The whole concept of C declarations is not rich enough to really deal with
> this properly.

I NEVER EVER use C structs or bit fields for this.  I get the raw octets
(or whatever the byte size is), and shift and mask accordingly to get
the data fields.

[TUHS] Re: Any UNIX With No C In Userland?

[Luther Johnson]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Any CPU with only a byte-wide memory interface (e.g. 8088) doesn't care
about bigger word alignments. But yes, if the CPU can do 16 and 32 and
64 bits at a time, then aligned accesses of bigger words can be one
transaction instead of two.

On 03/03/2025 03:00 PM, Paul Winalski wrote:
> On Mon, Mar 3, 2025 at 1:28 PM Larry McVoy <lm@mcvoy.com
> <mailto:lm@mcvoy.com>> wrote:
>
>
>     Even x86, it would appear, wants to do aligned loads.  I'm a little
>     surprised by that though maybe I shouldn't be as there is a RISC
>     implemented by the microcode under the x86 CPU.
>
> I don't think there's ever been a CPU design where unaligned accesses
> run at the same speed as naturally aligned accesses.  The worst case
> is an unaligned access that straddles a machine-word boundary.
>
> -Paul W.

[-- Attachment #2: Type: text/html, Size: 1793 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Rob Gingell]

On 3/3/25 3:13 PM, Dan Cross wrote:
> As an aside, Ken Harrenstein wrote a C compiler for the PDP-10 and a
> support library that was "good enough" to port a number of GNU tools
> to TOPS-20, including bash:

Yes, the Harrenstein C was the one we'd expected to use and were playing 
with at the time. We'd tried the Snyder compiler and one other I don't 
recall right now as well.

Glad to see it developed enough to get bash compiled, very cool, thanks 
for pointing it out!

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Mon, Mar 3, 2025 at 6:01 PM Rob Gingell <gingell@computer.org> wrote:
> [snip]
> The UNIX-related part of this was that among the things we used BLISS
> for was a package called PAUNIX that attempted to implement the V7 UNIX
> interfaces using the mechanisms/form used to implement TOPS-10
> compatibility (PA1050). Like the TOPS-10 compatibility it was a run-time
> veneer over TOPS-20 that mapped the UNIX functionality onto it and
> buffered the differences. I describe it as "attempted to" as it was
> successful as far as it got but it was a hobby project that got to about
> 80% done (meaning about 80% of the total effort remained) before life
> and other assignments preempted it.
>
> (Although, with my PiDP-10 running TOPS-20, a fun exercise in nostalgic
> futility might be to haul PAUNIX out of the closet and try to finish it.)

As an aside, Ken Harrenstein wrote a C compiler for the PDP-10 and a
support library that was "good enough" to port a number of GNU tools
to TOPS-20, including bash:

@i vers
 Indra, PANDA TOPS-20 Monitor 7.1(21733)-4
 PANDA TOPS-20 Command processor 7.1(4453)-4
@sh
bash$ echo $BASH_VERSION
1.12.1
bash$
bash$ exit
exit
@@
@

Kind of impressive, really.

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Rob Gingell]

On 3/1/25 3:28 PM, Clem Cole wrote:
> Funny thing, I 
> have always said huge reason BLISS lost was that DEC charged for $5000 
> per CPU for it on TOPS or VMS, while  C was free with UNIX - even though 
> the difference is the resulting code was remarkable.   So many people 
> stayed away because they did not want to spend the extra $s.
The price certainly was an impediment to adoption, and arguably so even 
within DEC.

At CWRU we did a lot of things in Common BLISS (-36, -16) including 
changes to the TOPS-20 monitor. Some of those were bought back by DEC 
but an impediment to that was they didn't want any of the TOPS-20 source 
to be in BLISS. The reason given was that source customers didn't want 
the burden of purchasing the license but it was hard to tell whether 
that was the real reason vs. a cultural rejection within DEC.

I forget how this was resolved but think it was a "take the generated 
code and add comments" solution -- that BLISS' code generation was 
pretty awesome made that workable if tedious.

Common BLISS was a pretty flexible and rich development tool, it would 
have been interesting to see it gain more traction though I can't see it 
"winning" vs. C given how much traction C had. The earlier BLISS-10/-11 
dialects were less compelling and quirkier.

The UNIX-related part of this was that among the things we used BLISS 
for was a package called PAUNIX that attempted to implement the V7 UNIX 
interfaces using the mechanisms/form used to implement TOPS-10 
compatibility (PA1050). Like the TOPS-10 compatibility it was a run-time 
veneer over TOPS-20 that mapped the UNIX functionality onto it and 
buffered the differences. I describe it as "attempted to" as it was 
successful as far as it got but it was a hobby project that got to about 
80% done (meaning about 80% of the total effort remained) before life 
and other assignments preempted it.

(Although, with my PiDP-10 running TOPS-20, a fun exercise in nostalgic 
futility might be to haul PAUNIX out of the closet and try to finish it.)

[TUHS] Re: Any UNIX With No C In Userland?

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Mon, Mar 3, 2025 at 1:28 PM Larry McVoy <lm@mcvoy.com> wrote:

>
> Even x86, it would appear, wants to do aligned loads.  I'm a little
> surprised by that though maybe I shouldn't be as there is a RISC
> implemented by the microcode under the x86 CPU.
>
> I don't think there's ever been a CPU design where unaligned accesses run
at the same speed as naturally aligned accesses.  The worst case is an
unaligned access that straddles a machine-word boundary.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

At Mon, 3 Mar 2025 22:31:13 +1100, Peter Yardley <peter.martin.yardley@gmail.com> wrote:
Subject: [TUHS] Re: Any UNIX With No C In Userland?
>
> Problems I have with C as a systems language is there is no
> certainty about representation of a structure in memory and hence
> when it is written to disk.

That might be true for some nit-pick-ity "Standard C", but it isn't true
for most real implementations, at least in the realm of 'hosted'
implementations.  Real implementations do after all have to interface
with real hardware.

In fact it's not impossible, or even really hard, to define a struct,
even with bitfields, that can be "portably" compiled for a number of
different architectures and platforms, including with different word
sizes and endianness and which will map directly onto an external binary
data representation.  It can get a bit ugly to look at, but it works.
Between the compiler manual and the ABI manual it _should_ all be quite
clear how to do it.

Of course "Standard C" has only got worse as it has morphed along the
way, growing increasingly thorny with more instead of less "Undefined
Behaviour".

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Noel Chiappa]

    > From: "G. Brandn Robinson"

    > C was a language for people who wanted to get that crap out of the way
    > so they could think about binary representations.

Huh? Sometimes C gets in the way of doing that; see below.

    > From: Dan Cross

    > They did indicate that alignment makes sharing _binary_ data between
    > VAX and PDP-11 harder, but that's truerepresentation of other aspects of product
    > types as well.

Alignment is just one aspect of low-level binary representation; there's also
length (in bits), which is critically important in several problem domains;
device registers have already been mentioned, but more below.

    > From: Peter Yardley

    > Problems I have with C as a systems language is there is no certainty
    > about representation of a structure in memory and hence when it is
    > written to disk.

That's yet another one.


The area I'm thinking of (and which I saw a lot of) is code to implement
network protocols (and I'm fairly astounded that nobody else has mentioned
this yet). One has to have _absolute_ control over how the bits are laid out
in the packet (which of course might wind up in any one of countless other
machine types) - which generally means how they are laid out in memory.

The whole concept of C declarations is not rich enough to really deal with
this properly. For each field in the header, one absolutely needs to be able
to separately specify the syntax (e.g. size in bits) and semantics (unsigned
integer, etc).

And if you want the code to be portable, so that one set of sources will
compile to working code on several different architctures, it gets worse.
Device registers, already mentioned, often only have to run on one type of
machine, but having protocol implementions run on a number of different
machine types is really common.


I came up with a way to do this, without _any_ #ifdefs (which I don't like,
for a reason I won't get into) in most source files. Dealing with byte order
issues was similarly dealt with (one can't deal with it just in types, really,
without making the type specification, and the language, somewhat
complicated).

I know later C's got better about richer variable semantics and syntax
selection than the circa 1985 ones I was working with, but I don't think it
was ever made completely simple and orthogonal (e.g.
'signed/unsigned/boolean/etc char/short/long/quad/word/etc') as it should
have been.

	Noel

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Mon, Mar 3, 2025 at 3:26 PM Steve Nickolas <usotsuki@buric.co> wrote:
>
> On Mon, 3 Mar 2025, Larry McVoy wrote:
>
> > Does anyone know if gcc has an option to ignore alignment and pack the
> > structs?
>
> Isn't it __attribute__((packed)) or something like that?

There are a few different ways to do that; some compilers have
`#pragma pack(1)` to pack structs on byte boundaries. All are language
extensions.

Standard C, starting with (IIRC) C11, has the `_Alignas` keyword that
lets you specify extended alignment for data; this can be useful in a
struct or something. However, I just checked the latest C spec and
it's quite explicit that you can't use it to relax alignment
requirements to something less strict. That is, you can't portably say
`alignas(1)` for an `int`.

What Paul described from BLISS makes it sound like you could describe
things like an IPv4 packet (which has fields that start at odd bit
boundaries) exactly. That's neat.

However, usually when programming at _that_ low of a level in C or
Rust or something like that, you have an ABI you can rely on for
guarantees about the size and alignment of fundamental types. If I'm
porting to another machine, I have to be sure those assumptions hold
on the target, or update as needed. I guess that's a bummer.

Unix got away with being able to specify things the way it did for so
long because they controlled the horizontal and the vertical: the
compiler was symbiotic with the system. You knew that your C struct
looked like the layout of the hardware registers for some device
because you maintained the compiler in the same source tree.  Those
days are long gone, of course, hence much of the current consternation
around portable C.

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Steve Nickolas]

On Mon, 3 Mar 2025, Larry McVoy wrote:

> Does anyone know if gcc has an option to ignore alignment and pack the
> structs?

Isn't it __attribute__((packed)) or something like that?

-uso.

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Mon, Mar 3, 2025 at 11:45 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Warner Losh wrote in
>  <CANCZdfrb7FLL_zhDq5E65kAzMsJ8HHBYJbcnWn+bhkAPUySKwg@mail.gmail.com>:
>  |On Mon, Mar 3, 2025, 11:28 AM Larry McVoy <lm@mcvoy.com> wrote:
>  |> On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote:
>  |>> Truth be told the subjectivity of implementing struct memory
>  |> characteristics has
>  |>> bewildered me more rather than less as time goes on.
>  |>
>  |> Alignment is your answer.  Understand that and the confusion goes away:
>  |>
>  |> slovax ~/tmp cat pack.c
>  |> #include <stdio.h>
>  |>
>  |> struct {
>  |>         char    a;
>  |>         int     b;
>  |>} foo;
>  |>
>  |> int
>  |> main(void)
>  |> {
>  |>         printf("%lu\n", sizeof(foo));
>  |>         return (0);
>  |>}
>  |>
>  |> slovax ~/tmp cc pack.c
>  |> slovax ~/tmp a.out
>  |> 8
>  |>
>  |>
>  |> Even x86, it would appear, wants to do aligned loads.  I'm a little
>  |> surprised by that though maybe I shouldn't be as there is a RISC
>  |> implemented by the microcode under the x86 CPU.
>  |>
>  |> Does anyone know if gcc has an option to ignore alignment and pack the
>  |> structs?
>  |>
>  |
>  |__attribute__ ((__packed__))
>
> __attribute__((packed, aligned(1)))
>
> I have forgotten why both.
>

packed (or __packed__) says no space between items.

aligned(1) means that the structure can start at any address.

Warner

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Lars Brinkhoff]

Paul Winalski wrote:
> There are four dialects of BLISS that differed mainly in the size of
> the BLISS value: 16 for BLISS-16 (for the PDP-11, 32 for BLISS-32
> (VAX, x86), 36 for BLISS-36 (PDP-10), and 64 for BLISS-64 (Alpha,
> Itanium, x86-64).

There was also BLISS-10, an earlier version for the PDP-10, and
BLISS-11, a cross compiler targeting the PDP-11, hosted on a PDP-10.

[TUHS] Re: Any UNIX With No C In Userland?

[Steffen Nurpmeso]

Warner Losh wrote in
 <CANCZdfrb7FLL_zhDq5E65kAzMsJ8HHBYJbcnWn+bhkAPUySKwg@mail.gmail.com>:
 |On Mon, Mar 3, 2025, 11:28 AM Larry McVoy <lm@mcvoy.com> wrote:
 |> On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote:
 |>> Truth be told the subjectivity of implementing struct memory
 |> characteristics has
 |>> bewildered me more rather than less as time goes on.
 |>
 |> Alignment is your answer.  Understand that and the confusion goes away:
 |>
 |> slovax ~/tmp cat pack.c
 |> #include <stdio.h>
 |>
 |> struct {
 |>         char    a;
 |>         int     b;
 |>} foo;
 |>
 |> int
 |> main(void)
 |> {
 |>         printf("%lu\n", sizeof(foo));
 |>         return (0);
 |>}
 |>
 |> slovax ~/tmp cc pack.c
 |> slovax ~/tmp a.out
 |> 8
 |>
 |>
 |> Even x86, it would appear, wants to do aligned loads.  I'm a little
 |> surprised by that though maybe I shouldn't be as there is a RISC
 |> implemented by the microcode under the x86 CPU.
 |>
 |> Does anyone know if gcc has an option to ignore alignment and pack the
 |> structs?
 |>
 |
 |__attribute__ ((__packed__))

__attribute__((packed, aligned(1)))

I have forgotten why both.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mon, Mar 3, 2025, 11:28 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote:
> > Truth be told the subjectivity of implementing struct memory
> characteristics has
> > bewildered me more rather than less as time goes on.
>
> Alignment is your answer.  Understand that and the confusion goes away:
>
> slovax ~/tmp cat pack.c
> #include <stdio.h>
>
> struct {
>         char    a;
>         int     b;
> } foo;
>
> int
> main(void)
> {
>         printf("%lu\n", sizeof(foo));
>         return (0);
> }
>
> slovax ~/tmp cc pack.c
> slovax ~/tmp a.out
> 8
>
>
> Even x86, it would appear, wants to do aligned loads.  I'm a little
> surprised by that though maybe I shouldn't be as there is a RISC
> implemented by the microcode under the x86 CPU.
>
> Does anyone know if gcc has an option to ignore alignment and pack the
> structs?
>

__attribute__ ((__packed__))

Warner

>

[-- Attachment #2: Type: text/html, Size: 1660 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]

On Mon, Mar 3, 2025, 10:00 AM Paul Winalski <paul.winalski@gmail.com> wrote:

> On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley <
> peter.martin.yardley@gmail.com> wrote:
>
>> Problems I have with C as a systems language is there is no certainty
>> about representation of a structure in memory and hence when it is written
>> to dis5⅝k.
>
>
> I believe you are correct.  Alignment and padding within structs in C is
> implementation-dependent.
>

Sizeof(int) is compiler dependent. uint32_t even isn't always 4 bytes.
There's no way to say "packed" that is portable. Endian isn't specified so
you have to cope with that. And bit field order is different for big/little
Endian compiler modes, but that detail is just super common. It isn't
mandated. And pointers aren't valid run to run

And that's even before you try to save a string... it's a mess that have a
lot of solutions to serialize...

Warner


> I will be happy to be corrected but I remember this behaviour to be
>> compiler dependant. Other languages such as Bliss and to perhaps a lesser
>> degree Pascal had implicit control of this.
>>
>>  In the case of BLISS, I would call it explicit control.  BLISS is a
> peculiar language in that it has only one data type, the BLISS value which
> is a contiguous set of bits of fixed length, typically the size of the
> target machine word.  There are four dialects of BLISS that differed mainly
> in the size of the BLISS value:  16 for BLISS-16 (for the PDP-11, 32 for
> BLISS-32 (VAX, x86), 36 for BLISS-36 (PDP-10), and 64 for BLISS-64 (Alpha,
> Itanium, x86-64).
>
> Data typing in BLISS is a function of the operations performed on the
> BLISS value rather than a property of the value itself.  BLISS is also
> unusual in that data are retrieved from memory or registers using an
> explicit fetch operator.  There is no distinction between lvalues and
> rvalues.  BLISS is also an expression language rather than a statement
> language.  Everything, including procedural code, is an expression with a
> BLISS value and can be used as such.  For example:
>
>      a = (if .b then .c else .d)
>
> This code fetches the BLISS value whose address is b ('.' is the fetch
> operator).  The IF expression treats this fetched value as a logical
> true/false.  If the value is true, the value whose address is c is fetched,
> otherwise the value whose address is d is fetched.  The value of IF
> expression is the fetched value.  The = expression then stores that value
> at the address represented by a.  The stored value is also the value of the
> = expression itself.  The semicolon (;) is an expression separator with the
> semantics "discard the current expression value".  It is common practice to
> write procedural code with operations separated by semicolons, which gives
> you a syntax similar to statement-oriented languages.  But you don't have
> to code that way.
>
> BLISS does have data aggregates, both vectors (one-dimensional arrays of
> BLISS values) and C-style structs.  The latter allows one to attach
> identifier names to pieces of the aggregate, supplying the same information
> as with the fetch operator (starting bit within the BLISS value, length in
> bits, whether or not it's to be sign-extended).  In C the programmer merely
> specifies the order of the fields within a struct and their data types.
> The compiler actually lays out the positions of the fields.  In BLISS the
> programmer must explicitly position the fields and specify their lengths.
>

[-- Attachment #2: Type: text/html, Size: 4788 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote:
> Truth be told the subjectivity of implementing struct memory characteristics has
> bewildered me more rather than less as time goes on.  

Alignment is your answer.  Understand that and the confusion goes away:

slovax ~/tmp cat pack.c
#include <stdio.h>

struct {
        char    a;
        int     b;
} foo;

int
main(void)
{
        printf("%lu\n", sizeof(foo));
        return (0);
}

slovax ~/tmp cc pack.c
slovax ~/tmp a.out
8


Even x86, it would appear, wants to do aligned loads.  I'm a little
surprised by that though maybe I shouldn't be as there is a RISC
implemented by the microcode under the x86 CPU.

Does anyone know if gcc has an option to ignore alignment and pack the
structs?

[TUHS] Re: Any UNIX With No C In Userland?

[segaloco via TUHS]

On Monday, March 3rd, 2025 at 9:38 AM, Lawrence Stewart <stewart@serissa.com> wrote:

> ...
> It’s too bad that that C doesn’t have standardized rules for structures, because even when hardware isn’t involved, one must be extremely careful with cacheline alignment of fields in order to get good performance.  __attribute__((aligned(64)) for the win, but it is ugly.  I don’t think there is even a portable way to get the cacheline size.
> 
> ...
> 
> -L
> 

Truth be told the subjectivity of implementing struct memory characteristics has
bewildered me more rather than less as time goes on.  What with the UNIX kernel
being one of C's earliest applications, you find plenty of places where a struct
is used to directly represent for instance a set of I/O registers on a
peripheral (UART comes to mind).  In this case, this would pretty much
necessitate a 100% predictable layout of a structure in memory, otherwise you
have no guarantee that the struct members you assign to specific registers
(THR, SR, etc.) will always be aligned with those registers.

This is an area where the "systems language" aspect does break down a bit
broadly for me, if I can't describe a contiguous memory region in a structured
way, just describe an abstract structure that various compilers put together
however they see fit, this makes it much more difficult to use structures for
anything other than abstract, in memory data in the context of a given process
(assuming all code in that process comes from the same compiler).  To
effectively transfer data between systems you then need not only worry about
endianness, but the ordering itself.  Sure, UNIX was all about everything being
text as much as possible, but there's something to be said about being able to
avoid the cost of serialization of data when you know endianness isn't a
problem.  When compilers are free to clobber structures together in memory
haphazardly, even sharing a CPU isn't a guarantee binary data will be portable.

Of course not trying to lob unfair critique at the folks who had to make these
decisions when constructing compilers, but it just surprises me there wasn't
more impetus to ensure a structure represents not only the members but the
memory characteristics of the data as it is being stored.  That said, given that
datatypes generally have minimum limits but are not *exact* across every system,
there is the fact that using the same datatypes across different CPUs, even if
the structures were very strict about no padding, order, whatever, you'd still
have the potential for wildly different memory layouts on different systems.
Not to mention systems requiring specific alignments regardless of data type.
Maybe I've answered my own concern but I still find myself curious why there
wasn't more of a push for memory predictability in a language being pushed as a
systems language.  It winds up being a happy accident, rather than a matter of
intention, when extension-less ANSI C fits nicely over a set of hardware
I/O registers...

- Matt G.

P.S. I will acquiesce that deeply embedded applications where memory
details are quite important typically are not locked into one compiler
ecosystem other than through vendor decisions, so it is much more feasible to
leverage some specific extended C (GNU, llvm, etc.) for bare-metal projects
where I/O register pages and such being perfectly mapped in structs matters.

[TUHS] Re: Any UNIX With No C In Userland?

[Lawrence Stewart]

[-- Attachment #1: Type: text/plain, Size: 4394 bytes --]

A bit of a story.

At SiCortex, we were well aware that structure layout and bitfields were compiler dependent, yet we had real requirements that high (?) level languages be able to directly interact with hardware defined structures.

So there was a chip spec that was the master truth about register layouts and hardware structures.  Wilson Snyder (of Verilator fame) wrote a postprocessor that swallowed the chip spec document and spit out header files in various languages, one of which was C Preprocessor compatible #defines for field offset, position, and width.

We programmers were careful to always use GET and SET macros to access objects with hardware specified layouts.
IIRC there were additional macros to make sure that hardware accesses always used the proper machine instructions and fences.

I don’t think the use of these macros cost much or any performance because they mostly resolved into shifts and masks with constants.

It’s too bad that that C doesn’t have standardized rules for structures, because even when hardware isn’t involved, one must be extremely careful with cacheline alignment of fields in order to get good performance.  __attribute__((aligned(64)) for the win, but it is ugly.  I don’t think there is even a portable way to get the cacheline size.

Then there is compiler register promotion, and volatile.

-L


> On Mar 3, 2025, at 11:59, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley <peter.martin.yardley@gmail.com <mailto:peter.martin.yardley@gmail.com>> wrote:
>> Problems I have with C as a systems language is there is no certainty about representation of a structure in memory and hence when it is written to disk.
> 
> I believe you are correct.  Alignment and padding within structs in C is implementation-dependent.
>  
>> I will be happy to be corrected but I remember this behaviour to be compiler dependant. Other languages such as Bliss and to perhaps a lesser degree Pascal had implicit control of this.
>> 
>  In the case of BLISS, I would call it explicit control.  BLISS is a peculiar language in that it has only one data type, the BLISS value which is a contiguous set of bits of fixed length, typically the size of the target machine word.  There are four dialects of BLISS that differed mainly in the size of the BLISS value:  16 for BLISS-16 (for the PDP-11, 32 for BLISS-32 (VAX, x86), 36 for BLISS-36 (PDP-10), and 64 for BLISS-64 (Alpha, Itanium, x86-64).
> 
> Data typing in BLISS is a function of the operations performed on the BLISS value rather than a property of the value itself.  BLISS is also unusual in that data are retrieved from memory or registers using an explicit fetch operator.  There is no distinction between lvalues and rvalues.  BLISS is also an expression language rather than a statement language.  Everything, including procedural code, is an expression with a BLISS value and can be used as such.  For example:
> 
>      a = (if .b then .c else .d)
> 
> This code fetches the BLISS value whose address is b ('.' is the fetch operator).  The IF expression treats this fetched value as a logical true/false.  If the value is true, the value whose address is c is fetched, otherwise the value whose address is d is fetched.  The value of IF expression is the fetched value.  The = expression then stores that value at the address represented by a.  The stored value is also the value of the = expression itself.  The semicolon (;) is an expression separator with the semantics "discard the current expression value".  It is common practice to write procedural code with operations separated by semicolons, which gives you a syntax similar to statement-oriented languages.  But you don't have to code that way.
> 
> BLISS does have data aggregates, both vectors (one-dimensional arrays of BLISS values) and C-style structs.  The latter allows one to attach identifier names to pieces of the aggregate, supplying the same information as with the fetch operator (starting bit within the BLISS value, length in bits, whether or not it's to be sign-extended).  In C the programmer merely specifies the order of the fields within a struct and their data types.  The compiler actually lays out the positions of the fields.  In BLISS the programmer must explicitly position the fields and specify their lengths.


[-- Attachment #2: Type: text/html, Size: 5539 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley <peter.martin.yardley@gmail.com>
wrote:

> Problems I have with C as a systems language is there is no certainty
> about representation of a structure in memory and hence when it is written
> to disk.


I believe you are correct.  Alignment and padding within structs in C is
implementation-dependent.


> I will be happy to be corrected but I remember this behaviour to be
> compiler dependant. Other languages such as Bliss and to perhaps a lesser
> degree Pascal had implicit control of this.
>
>  In the case of BLISS, I would call it explicit control.  BLISS is a
peculiar language in that it has only one data type, the BLISS value which
is a contiguous set of bits of fixed length, typically the size of the
target machine word.  There are four dialects of BLISS that differed mainly
in the size of the BLISS value:  16 for BLISS-16 (for the PDP-11, 32 for
BLISS-32 (VAX, x86), 36 for BLISS-36 (PDP-10), and 64 for BLISS-64 (Alpha,
Itanium, x86-64).

Data typing in BLISS is a function of the operations performed on the BLISS
value rather than a property of the value itself.  BLISS is also unusual in
that data are retrieved from memory or registers using an explicit fetch
operator.  There is no distinction between lvalues and rvalues.  BLISS is
also an expression language rather than a statement language.  Everything,
including procedural code, is an expression with a BLISS value and can be
used as such.  For example:

     a = (if .b then .c else .d)

This code fetches the BLISS value whose address is b ('.' is the fetch
operator).  The IF expression treats this fetched value as a logical
true/false.  If the value is true, the value whose address is c is fetched,
otherwise the value whose address is d is fetched.  The value of IF
expression is the fetched value.  The = expression then stores that value
at the address represented by a.  The stored value is also the value of the
= expression itself.  The semicolon (;) is an expression separator with the
semantics "discard the current expression value".  It is common practice to
write procedural code with operations separated by semicolons, which gives
you a syntax similar to statement-oriented languages.  But you don't have
to code that way.

BLISS does have data aggregates, both vectors (one-dimensional arrays of
BLISS values) and C-style structs.  The latter allows one to attach
identifier names to pieces of the aggregate, supplying the same information
as with the fetch operator (starting bit within the BLISS value, length in
bits, whether or not it's to be sign-extended).  In C the programmer merely
specifies the order of the fields within a struct and their data types.
The compiler actually lays out the positions of the fields.  In BLISS the
programmer must explicitly position the fields and specify their lengths.

[-- Attachment #2: Type: text/html, Size: 3477 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Peter Yardley]

Problems I have with C as a systems language is there is no certainty about representation of a structure in memory and hence when it is written to disk. I will be happy to be corrected but I remember this behaviour to be compiler dependant. Other languages such as Bliss and to perhaps a lesser degree Pascal had implicit control of this. Having said that I worked with C as a systems language many times.

> On 3 Mar 2025, at 10:25 am, Dan Cross <crossd@gmail.com> wrote:
> 
> On Sun, Mar 2, 2025 at 1:46 PM G. Branden Robinson
> <g.branden.robinson@gmail.com> wrote:
>> At 2025-03-02T17:54:01+0000, segaloco via TUHS wrote:
>> [snip]
>> If I'm understanding Bakul's point correctly, then what you're saying is
>> a defensible claim about many aspects of C but emphatically _not_ of its
>> type system.  The language does _not_ give you the tools to implement a
>> rigorous type system as, Haskell programmers or type theorists would
>> conceive of it.  I mean, you could write a Haskell compiler in C, but
>> you wouldn't be able to apply its type logic to C's own type system.
>> (Maybe you could do it for any types other than the primitive ones
>> already supported, with sufficient abuse of the preprocessor.)
>> 
>> This rigid inability was baked into C from day one.  Everything that can
>> possibly be represented in a machine register with all bits clear shows
>> up as an integral zero literal.
>> 
>> '\0' == 0 == nullptr == struct { } == union { }
>> 
>> The CSRC staked a lot on the typeless B, and clung to that heritage.
>> I don't think it's an accident that C's designers expressed type
>> _aliasing_ with the keyword "typedef".  Types simply were not taken
>> seriously as reasoning tools.  C was a language for people who wanted to
>> get that crap out of the way so they could think about binary
>> representations.  (Okay, octal.)
> 
> I'm sure I've said something like this before, but I do not think this
> criticism is fair. Many of the design aspects of C were dictated by
> the context in which it was developed, and if judging it in 2025, we
> have to bear that in mind. Recall that it had to fit on a machine that
> is laughably small by today's standards, and pretty small even in
> 1972; that imposed real constraints on its structure and semantics.
> Did other systems-oriented languages in that era have significantly
> richer type systems? Would a compiler for such a language even be
> runnable on Unix in the very early 70s? That's a serious question.
> Incidentally, the keyword for creating a type alias in Haskell is just
> `type`. Same in SML, OCaml, and Rust. I don't know that `typedef` is
> appreciably different, nor that it can credibly be cited as some sort
> of "tell" about a cavalier attitude towards types.
> 
>> C was aggressively oversold, I think more by by its fans than its
>> designers.
> 
> For the sorts of things one used C for throughout the 70s and into the
> 80s, what were the alternatives?
> 
>> Even its reputation as "portable assembler" withstands
>> scrutiny only as long as all you want to port to are models in the
>> PDP-11 line.  If you think that claim is crack-headed, review London &
>> Reiser's paper on porting Unix to the VAX-11/780.  Even setting aside
>> the problems with nroff/troff and the Bourne shell, they pointed their
>> fingers at problems that a "portable assembly language" would already
>> have considered, like machines having differing alignment requirements,
> 
> I didn't read that in their paper. They pointed out four enhancements
> to C, related to types, that they felt would enhance portability.
> Interestingly, all four have been implemented in more modern dialects
> of the language, though the alignment thing is still a bit perilous; I
> can't quite tell whether they were referring to "packed" structures
> (largely irrelevant when programs are written against a well-defined
> ABI) or something closer to `alignas()`/`alignof()`. They did indicate
> that alignment makes sharing _binary_ data between VAX and PDP-11
> harder, but that's true of other aspects of product types as well.
> 
>> or having the standard I/O library's binary I/O functions write and
>> interpret some kind of header in the file expressing basic facts like
>> the endianness of various integer widths (big, little, or FP-11).  Magic
>> numbers were good enough for object file formats, but not applications
>> programmers, I guess.
> 
> This really doesn't seem like it's the job of the IO library. For that
> matter, I don't think more recent languages delegate this to their IO
> routines, either. I'm also not sure that's what they said (at least,
> that's not how I interpreted their comments).
> 
>> I don't doubt that people could be massively more productive in C than
>> in PDP-11 assembly language.  But that claim doesn't establish anything
>> that wasn't already known about the utility of higher-level languages.
>> 
>> K&R were still trying to warn people in 1988 that C was not a hammer for
>> all nails.
>> 
>> "...C offers only straightforward, single-thread control flow: tests,
>> loops, grouping, and subprograms, but not multiprogramming, parallel
>> operations, synchronization, or coroutines." (_The C Programming
>> Language, 2nd edition, p. 2)
>> 
>> I guess we can add a general, flexible algebraic type system to the list
>> of missing features.
> 
> Sure. But then we're back where we started, talking about a language
> that only has a passing resemblance to C.
> 
>        - Dan C.

.1.3.6.1.4.1.8852.4.2
Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: Any UNIX With No C In Userland?

[Rob Gingell]

On 3/1/25 3:38 PM, Larry McVoy wrote:
> Rob Gingell would likely know.

Time has fogged the memories but I'll try.

> On Sat, Mar 01, 2025 at 06:28:58PM -0500, Clem Cole wrote:
>> IIRC: Sun continued to bundled a simple C compiler so you build the kernel,
>> but it was trying to make $s on the compiler suite.
>>
>>   SW economics can be difficult.

As has been noted, SunOS 4.x continued to ship a cc sufficient to build 
the kernel but which didn't otherwise track the language evolution going 
on. The unbundled tools were introduced to deliver those and, in a 
theory about the value of software, to earn the necessary investments by 
generating a return. It wasn't just marketing being revenue vampires 
though it presented an opportunity for feeding.

There was a good bit of investment / change in the tools in this period. 
The SVR4 work brought the ANSI C front end from AT&T, FORTRAN technology 
purchases/licenses occurred, there was something going on with Pascal 
that I don't recall at the moment. Some of the investment was 
necessitated by the shift to SPARC and the demands that RISC posed on 
the code generation software. The appeal that these things must be done 
because they're necessary to have good and credible products was 
countered with a business sentiment that the value should manifest as a 
return visible in $.

So I recall it as more textured than just "let's squeeze some $'s" but 
especially if you have the view that "C is part of the system" it's an 
affront.

On 3/1/25 5:17 PM, Larry McVoy wrote:
> The funny thing was that somewhere around then Sun Labs was paying Micheal
> Tiemann to make g++ work.  With a deal that let him retain the rights to
> the code.  I never understood that, one hand wants to charge for cc and
> the other hand is paying for free g++?  The ways of Sun could be strange.

One of Sun's charms was a "let many flowers bloom, even if they 
contradict themselves" kind of culture. Sometimes this yielded successes 
and opportunities. Sometimes it resulted in frictions and periodic 
culls. (The "all the wood behind one arrow" SPARC focus was one such 
consequence, when the array of 68K, 386, and SPARC products got too 
logistically cacophonous and Sun blew a revenue projection in [I think] 
the last FY1989 quarter. The cacophony wasn't in engineering so much as 
the rest of the business: sales forecasting, manufacturing, support, ISV 
relationships. etc.)

"Many flowers bloom" thinking wasn't restricted to just technology and 
extended to business models. The thinking that "investments should 
follow the revenue" visible in the tools unbundling along with 
additional influences led to the "planets" reorganization of Sun (e.g., 
SunSoft, SunPro, etc.) where inter-unit pricing and therefore revenues 
would demonstrate where value was derived. Sun's R&D levels were always 
higher than conventional business wisdom said they should be so 
rationalizing them drove such thinking.

Whatever the merits of the planets model in theory were, they were 
completely lost in the execution. The implementation looked more like 
the State Planning Committee of the Soviet Union than Wall Street. The 
company focused inward rather than outward to the market for a while 
before the whole thing was relaxed back to something more "normal". 
Definitely one of the worst self-inflicted wounds in the company's history.

IMO, such failures emerged from the same environment that permitted the 
exploration of unusual ideas and the taking of big swings. Sun was 
probably better off and certainly more impactful, fun, and interesting 
for being that way even at the cost of some dramatic face plants.

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Sun, Mar 2, 2025 at 1:46 PM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> At 2025-03-02T17:54:01+0000, segaloco via TUHS wrote:
>[snip]
> If I'm understanding Bakul's point correctly, then what you're saying is
> a defensible claim about many aspects of C but emphatically _not_ of its
> type system.  The language does _not_ give you the tools to implement a
> rigorous type system as, Haskell programmers or type theorists would
> conceive of it.  I mean, you could write a Haskell compiler in C, but
> you wouldn't be able to apply its type logic to C's own type system.
> (Maybe you could do it for any types other than the primitive ones
> already supported, with sufficient abuse of the preprocessor.)
>
> This rigid inability was baked into C from day one.  Everything that can
> possibly be represented in a machine register with all bits clear shows
> up as an integral zero literal.
>
> '\0' == 0 == nullptr == struct { } == union { }
>
> The CSRC staked a lot on the typeless B, and clung to that heritage.
> I don't think it's an accident that C's designers expressed type
> _aliasing_ with the keyword "typedef".  Types simply were not taken
> seriously as reasoning tools.  C was a language for people who wanted to
> get that crap out of the way so they could think about binary
> representations.  (Okay, octal.)

I'm sure I've said something like this before, but I do not think this
criticism is fair. Many of the design aspects of C were dictated by
the context in which it was developed, and if judging it in 2025, we
have to bear that in mind. Recall that it had to fit on a machine that
is laughably small by today's standards, and pretty small even in
1972; that imposed real constraints on its structure and semantics.
Did other systems-oriented languages in that era have significantly
richer type systems? Would a compiler for such a language even be
runnable on Unix in the very early 70s? That's a serious question.
Incidentally, the keyword for creating a type alias in Haskell is just
`type`. Same in SML, OCaml, and Rust. I don't know that `typedef` is
appreciably different, nor that it can credibly be cited as some sort
of "tell" about a cavalier attitude towards types.

> C was aggressively oversold, I think more by by its fans than its
> designers.

For the sorts of things one used C for throughout the 70s and into the
80s, what were the alternatives?

> Even its reputation as "portable assembler" withstands
> scrutiny only as long as all you want to port to are models in the
> PDP-11 line.  If you think that claim is crack-headed, review London &
> Reiser's paper on porting Unix to the VAX-11/780.  Even setting aside
> the problems with nroff/troff and the Bourne shell, they pointed their
> fingers at problems that a "portable assembly language" would already
> have considered, like machines having differing alignment requirements,

I didn't read that in their paper. They pointed out four enhancements
to C, related to types, that they felt would enhance portability.
Interestingly, all four have been implemented in more modern dialects
of the language, though the alignment thing is still a bit perilous; I
can't quite tell whether they were referring to "packed" structures
(largely irrelevant when programs are written against a well-defined
ABI) or something closer to `alignas()`/`alignof()`. They did indicate
that alignment makes sharing _binary_ data between VAX and PDP-11
harder, but that's true of other aspects of product types as well.

> or having the standard I/O library's binary I/O functions write and
> interpret some kind of header in the file expressing basic facts like
> the endianness of various integer widths (big, little, or FP-11).  Magic
> numbers were good enough for object file formats, but not applications
> programmers, I guess.

This really doesn't seem like it's the job of the IO library. For that
matter, I don't think more recent languages delegate this to their IO
routines, either. I'm also not sure that's what they said (at least,
that's not how I interpreted their comments).

> I don't doubt that people could be massively more productive in C than
> in PDP-11 assembly language.  But that claim doesn't establish anything
> that wasn't already known about the utility of higher-level languages.
>
> K&R were still trying to warn people in 1988 that C was not a hammer for
> all nails.
>
> "...C offers only straightforward, single-thread control flow: tests,
> loops, grouping, and subprograms, but not multiprogramming, parallel
> operations, synchronization, or coroutines." (_The C Programming
> Language, 2nd edition, p. 2)
>
> I guess we can add a general, flexible algebraic type system to the list
> of missing features.

Sure. But then we're back where we started, talking about a language
that only has a passing resemblance to C.

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

At Sat, 1 Mar 2025 19:00:03 -0800, Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
Subject: [TUHS] Re: Any UNIX With No C In Userland?
>
> .... C is a great portable
> assembler but not so great as a high level language.

Unfortunately modern C isn't a a great portable "assembler" any more.

V is probably one of the better new low-level programming languages.
Development of V has hardly stalled -- it's highly active from what I
see on Github.  I personally think V is very easy to learn for C
programmers, with lots of similarities, and it's very easy to translate
C to V too!

Hare is another interesting new compiled systems-level language.

Both are promising "No Undefined Behaviour" -- since of course the main
Sin Of Modern C is it's all-too-abusive reliance on Undefined Behaviour.

Possibly Jai will be in this realm as well.  Hmm.... Nim?  Maybe.


Regarding the question starting this part of the thread:  Any UNIX with
no C In Userland?

Well there was TUNIS (https://en.wikipedia.org/wiki/TUNIS).

I don't have quick access to my copy of the book about it, but I seem to
recall that there may have been some attempts to be ABI-compatible with
7th Edition Unix, at least on PDP-11.  That Wikipedia article does say:

	Programs that ran under Unix V7 could be run under TUNIS with no
	modification.

But that may have only meant API-compatible.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

On Sun, Mar 2, 2025 at 10:46 AM Larry McVoy <lm@mcvoy.com> wrote:
>  Hanging out there gave me insight into what all
> those execs did.  It's very different from what an engineer does, we
> figure stuff out to the Nth degree.

Very nice note.

[-- Attachment #2: Type: text/html, Size: 606 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]

At 2025-03-02T17:54:01+0000, segaloco via TUHS wrote:
> On Sunday, March 2nd, 2025 at 9:29 AM, Bakul Shah via TUHS
> <tuhs@tuhs.org> wrote:
> > C's Achilles' heel is its type system. No extension can paper over
> > that. Once you fix that it is no longer C. Newer languages can in
> > fact be seen as fixing/adding things like proper strings, default
> > read/write rules, memory allocation rules, modules/packages,
> > object/closures, etc. over C. This is why I said they are not
> > particularly outstanding. A lot of it seems rather adhoc.
> 
> For me though that speaks to the fact that C leaves a lot to the
> imagination.  You've got the building blocks of a number of higher
> level concepts, but implementation thereof is left to the user.  Of
> course you have these various extensions pop up, but the base language
> does not define the "one true way" to do it, rather, each case can be
> engineered with context in mind.

If I'm understanding Bakul's point correctly, then what you're saying is
a defensible claim about many aspects of C but emphatically _not_ of its
type system.  The language does _not_ give you the tools to implement a
rigorous type system as, Haskell programmers or type theorists would
conceive of it.  I mean, you could write a Haskell compiler in C, but
you wouldn't be able to apply its type logic to C's own type system.
(Maybe you could do it for any types other than the primitive ones
already supported, with sufficient abuse of the preprocessor.)

This rigid inability was baked into C from day one.  Everything that can
possibly be represented in a machine register with all bits clear shows
up as an integral zero literal.

'\0' == 0 == nullptr == struct { } == union { }

The CSRC staked a lot on the typeless B, and clung to that heritage.
I don't think it's an accident that C's designers expressed type
_aliasing_ with the keyword "typedef".  Types simply were not taken
seriously as reasoning tools.  C was a language for people who wanted to
get that crap out of the way so they could think about binary
representations.  (Okay, octal.)

C was aggressively oversold, I think more by by its fans than its
designers.  Even its reputation as "portable assembler" withstands
scrutiny only as long as all you want to port to are models in the
PDP-11 line.  If you think that claim is crack-headed, review London &
Reiser's paper on porting Unix to the VAX-11/780.  Even setting aside
the problems with nroff/troff and the Bourne shell, they pointed their
fingers at problems that a "portable assembly language" would already
have considered, like machines having differing alignment requirements,
or having the standard I/O library's binary I/O functions write and
interpret some kind of header in the file expressing basic facts like
the endianness of various integer widths (big, little, or FP-11).  Magic
numbers were good enough for object file formats, but not applications
programmers, I guess.

I don't doubt that people could be massively more productive in C than
in PDP-11 assembly language.  But that claim doesn't establish anything
that wasn't already known about the utility of higher-level languages.

K&R were still trying to warn people in 1988 that C was not a hammer for
all nails.

"...C offers only straightforward, single-thread control flow: tests,
loops, grouping, and subprograms, but not multiprogramming, parallel
operations, synchronization, or coroutines." (_The C Programming
Language, 2nd edition, p. 2)

I guess we can add a general, flexible algebraic type system to the list
of missing features.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[segaloco via TUHS]

On Sunday, March 2nd, 2025 at 9:29 AM, Bakul Shah via TUHS <tuhs@tuhs.org> wrote:

> On Mar 1, 2025, at 7:16 PM, Larry McVoy lm@mcvoy.com wrote:
> 
> > > Anyway, my main point was that please do something innovative and
> > > interesting if you must use a new HLL for an OS!
> > 
> > So little-lang wasn't for OS stuff, it was for userland, but I feel it was
> > plenty innovative. It fit into C syntax but added a bunch of useful stuff.
> > string type that managed the memory in the language, no more malloc/free
> > crap. Case statements that could take variables, regexp as switches.
> > Perl like I/O with regex built in. It was just a pile of pleasant
> > enhancements to C.
> 
> 
> My comment was about innovation in the OS, not about any HLL.
> 
> > And it could be an OS language, I don't see why not.
> 
> 
> Sure.
> 
> > If I had enough money, I'd fund a gcc --lang=Little syntax and the world
> > would be a better place. In. My. Opinion. Not everyone elses but I
> > really believe if gcc had that dialect a lot of C people would move to it.
> > 
> > I'm not pushing my pet language, I'm holding it up as an example of how
> > you could make a new programming language. Take what works, extend it
> > with what works. Preserve people's knowledge rather than force them to
> > learn a new syntax that does the same thing. Extend rather than replace.
> 
> 
> C's Achilles' heel is its type system. No extension can paper over
> that. Once you fix that it is no longer C. Newer languages can in
> fact be seen as fixing/adding things like proper strings, default
> read/write rules, memory allocation rules, modules/packages,
> object/closures, etc. over C. This is why I said they are not
> particularly outstanding. A lot of it seems rather adhoc.

For me though that speaks to the fact that C leaves a lot to the imagination.  You've got the building blocks of a number of higher level concepts, but implementation thereof is left to the user.  Of course you have these various extensions pop up, but the base language does not define the "one true way" to do it, rather, each case can be engineered with context in mind.

I personally wouldn't see a one size fits all "upgrade" of the language gaining steam in this regard, partially because it wouldn't need to.  C is great at what it is for, keeping it simple ensures a solid foundation on which more complex systems can be built without painting any given concern into a corner.  But you know what they say, with great power comes great responsibility.  If folks don't need that power or don't want that responsibility, there are a glut of other languages, both general and focused, for whatever need they may have that C cannot meet.

To spin another quote ask not what your language of choice can do for you, ask what you can do for your language of choice.  In other words, the growth of new features in a language doesn't always need to be an addition to the specification, it instead can be novel use that is then shared with others to the benefit of all that language's adherents.

- Matt G.

[TUHS] Re: Any UNIX With No C In Userland?

[Bakul Shah via TUHS]

On Mar 1, 2025, at 7:16 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
>> 
>> Anyway, my main point was that please do something innovative and
>> interesting if you must use a new HLL for an OS! 
> 
> So little-lang wasn't for OS stuff, it was for userland, but I feel it was
> plenty innovative.  It fit into C syntax but added a bunch of useful stuff.
> string type that managed the memory in the language, no more malloc/free
> crap.  Case statements that could take variables, regexp as switches.
> Perl like I/O with regex built in.  It was just a pile of pleasant
> enhancements to C.

My comment was about innovation in the OS, not about any HLL.

> And it could be an OS language, I don't see why not.

Sure.

> If I had enough money, I'd fund a gcc --lang=Little syntax and the world
> would be a better place.  In.  My.  Opinion.  Not everyone elses but I
> really believe if gcc had that dialect a lot of C people would move to it.
> 
> I'm not pushing my pet language, I'm holding it up as an example of how
> you could make a new programming language.  Take what works, extend it
> with what works.  Preserve people's knowledge rather than force them to
> learn a new syntax that does the same thing.  Extend rather than replace.

C's Achilles' heel is its type system. No extension can paper over
that. Once you fix that it is no longer C. Newer languages can in
fact be seen as fixing/adding things like proper strings, default
read/write rules, memory allocation rules, modules/packages,
object/closures, etc. over C. This is why I said they are not
particularly outstanding. A lot of it seems rather adhoc.

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Sat, Mar 01, 2025 at 08:07:37PM -0600, G. Branden Robinson wrote:
> Until you get to a level where decision makers truly have no
> accountability for anything they do (don't strain yourself looking for
> examples in the news), I've found (from my minuscule sampling of
> industry) that business decisions can usually be explained rationally.
> The problem is that the rationales are often kept secret, sometimes in
> the name of "strategy" but more often, I think, to keep line staff in
> their place instead of critically considering management decisions--
> unless they're willing to join political alliances and thereby make
> themselves (even more) vulnerable to dismissal for unspoken reasons.

As an engineer who was paid to try and convince Sun's execs that the pivot
to Solaris/System V was a mistake, I have a different take.  The 6 months
I spent at the top of PAL-1 where McNealy & Co worked were unsuccessful
but very educational.  Hanging out there gave me insight into what all
those execs did.  It's very different from what an engineer does, we
figure stuff out to the Nth degree.  The execs did not have that luxury.
What they did all day, every day, is make decisions about what to do but
with only about 1/10th the amount of information an engineer would have.
They simply couldn't wait long enough to know everything they wanted to
know, the rest of the industry would pass them by.

I would HATE to have their job.  As I grew to understand their jobs, my
respect for them went up but there is no amount of money that would make
me want that job.

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Sat, Mar 1, 2025, 7:07 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Did Sun's proprietary C compiler also handle C++ at that time?
>

Yes. They had a cfront interim release that we tested, but their SUNWpro
compiler later replaced it with something better, but I don't recall the
exact
details. I do recall SUNWpro was pickier than the older pcc + cfront one
that we used before.

If it did, it _still_ might have made sense, because while I was only
> barely conscious of the C++ marketplace at the time, with the language's
> standardization nigh (for definitions of "nigh" stretching out many more
> years than anyone planned), Sun's compiler guys might have feared giving
> up mindshare and influence on the future ISO C++ to Borland or
> Microsoft.
>

SUNWpro compilers pre-date any standardization efforts...  The ARM
was in this time, and C++ was struggling to finalize enough things to
make it worthwhile to get it to ISO/ANSI.


> The foregoing speculative concern is consistent with the speed of Sun's
> pivot to Oak/Java around the time Microsoft showed that (1) Windows NT
> was going to block further penetration of Unix into the server OS sector
> and substantially erode Unix's place in workstation and high-end PC
> configurations _and_ (2) it was going to destroy Borland C++ with Visual
> C++ by hook or by crook (the sort of stuff that got Bill Gates haled
> into a CSPAN-televised Congressional hearing a few years later, but with
> respect to Web browsers).
>

JAVA post-dates this pivot by a few years...

That said, I'm sure it would surprise no one if the "real reason" turned
> out to be a stupid one.
>

Warner

[-- Attachment #2: Type: text/html, Size: 2699 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Sat, Mar 01, 2025 at 07:00:03PM -0800, Bakul Shah wrote:
> On Mar 1, 2025, at 6:16???PM, Larry McVoy <lm@mcvoy.com> wrote:
> > We did that with https://www.little-lang.org/index.html which is a compiled
> > C like language.   There are a ton of extensions to C that just made sense
> > to me.  It never caught on but it still stands as an example of how you 
> > could take C syntax and extend it to be more useful.  Why people don't 
> > do that is a mystery to me.
> 
> I looked at it when it was mentioned in the past. Didn't like it enough.

Yeah, it has no traction, I don't blame you in the slightest.

> Anyway, my main point was that please do something innovative and
> interesting if you must use a new HLL for an OS! 

So little-lang wasn't for OS stuff, it was for userland, but I feel it was
plenty innovative.  It fit into C syntax but added a bunch of useful stuff.
string type that managed the memory in the language, no more malloc/free
crap.  Case statements that could take variables, regexp as switches.
Perl like I/O with regex built in.  It was just a pile of pleasant
enhancements to C.

And it could be an OS language, I don't see why not.

If I had enough money, I'd fund a gcc --lang=Little syntax and the world
would be a better place.  In.  My.  Opinion.  Not everyone elses but I
really believe if gcc had that dialect a lot of C people would move to it.

I'm not pushing my pet language, I'm holding it up as an example of how
you could make a new programming language.  Take what works, extend it
with what works.  Preserve people's knowledge rather than force them to
learn a new syntax that does the same thing.  Extend rather than replace.

[TUHS] Re: Any UNIX With No C In Userland?

[Bakul Shah via TUHS]

On Mar 1, 2025, at 6:16 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> I took a look at the V language, not a fan.  But I'm a grumpy old C
> programmer and I tend to hate languages that change the syntax for 
> no good reason.

There are quite a few newer languages but none outstanding (IMHO). I
do like V but that may be because I haven't written enough code in it!

> I would much prefer to see C evolved.  Not like C++ but just better C.
> It dismays me that people feel like they need to make a mark with some
> new "better" syntax.  C syntax is fine, it's well understood by a zillion
> programmers.  So why not evolve that syntax to a better C?

AFAIK all such attempts have failed. C is a great portable assembler but
not so great as a high level language.

> We did that with https://www.little-lang.org/index.html which is a compiled
> C like language.   There are a ton of extensions to C that just made sense
> to me.  It never caught on but it still stands as an example of how you 
> could take C syntax and extend it to be more useful.  Why people don't 
> do that is a mystery to me.

I looked at it when it was mentioned in the past. Didn't like it enough.

Anyway, my main point was that please do something innovative and
interesting if you must use a new HLL for an OS! 

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Sat, Mar 01, 2025 at 05:58:15PM -0800, Bakul Shah via TUHS wrote:
> On Feb 28, 2025, at 4:16???PM, segaloco via TUHS <tuhs@tuhs.org> wrote:
> > 
> > Given that anything that obeys the ABI and has assembler entries to the kernel
> > can request services, it seems to me it would be possible to stand up a
> > user-land without C being present.  Have any UNIXen ever done this after the
> > advent of C?
> 
> vinix is written in the V language and can have userland written in V as
> well but so far the compiler compiles to c (so requires a c compiler) so
> not sure it qualifies + its development seems to have stalled somewhat.
> 
> IIRC there is at least one v6 level (toy?) OS written in rust with a
> rust only userland. May be for anything non-toy you'd have to provide
> a C compatible API.
> 
> Personally I don't see much point in reimplementing a 50+ year old OS in
> a new language; at least do something new and innovative (with unix
> emulation for dusty decks) but ??\_(???)_/??

I took a look at the V language, not a fan.  But I'm a grumpy old C
programmer and I tend to hate languages that change the syntax for 
no good reason.

I would much prefer to see C evolved.  Not like C++ but just better C.
It dismays me that people feel like they need to make a mark with some
new "better" syntax.  C syntax is fine, it's well understood by a zillion
programmers.  So why not evolve that syntax to a better C?

We did that with https://www.little-lang.org/index.html which is a compiled
C like language.   There are a ton of extensions to C that just made sense
to me.  It never caught on but it still stands as an example of how you 
could take C syntax and extend it to be more useful.  Why people don't 
do that is a mystery to me.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Any UNIX With No C In Userland?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

At 2025-03-01T20:07:42-0600, G. Branden Robinson wrote:
> If it did, it _still_ might have made sense, because while I was only
> barely conscious of the C++ marketplace at the time, with the language's
> standardization nigh (for definitions of "nigh" stretching out many more
> years than anyone planned), Sun's compiler guys might have feared giving
> up mindshare and influence on the future ISO C++ to Borland or
> Microsoft.

I forgot to mention some support for this argument.  I quote Bjarne
Stroustrup in the 4th edition of his central C++ book.

"Clearly, the 1998 language was far superior in features and in
particular the detail of specification to the 1989 language.  However,
not all changes were improvements.  In addition to the inevitable minor
mistakes, two major features were added that should not have been:

* Exception specifications provide run-time enforcement of which
  exceptions a function is allowed to throw.  They were added at the
  energetic initiative of people from Sun Microsystems.  Exception
  specifications turned out to be worse than useless for improving
  readability, reliability, and performance.  They are deprecated
  (scheduled for removal) in the 2011 standard.  ..." (p. 26)

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

At 2025-03-01T17:17:40-0800, Larry McVoy wrote:
> The funny thing was that somewhere around then Sun Labs was paying
> Micheal Tiemann to make g++ work.  With a deal that let him retain the
> rights to the code.

What would the alternative have been?  If the goal was "to make g++
work", then the code would, at the time, have had to be contributed to
the FSF anyway.  My understanding is that the FSF's copyright assignment
agreements, while scandalous in some circles at the time (and remain so
in a few), were far more generous than today's contributor license
agreements.  So Tiemann would have retained rights to what he wrote, but
neither he nor Sun could have used it to stand up a competing
proprietary C++ compiler without reimplementing the rest of said
compiler, because of [dramatic orchestral sting] the GPL.

> I never understood that, one hand wants to charge for cc

and the other hand is paying for free g++?

Did Sun's proprietary C compiler also handle C++ at that time?

If not, then having a C++ story on SunOS and/or Solaris could easily
have been more important than fear of lost revenue to a C++ compiler
they couldn't offer an alternative to anyway.

If it did, it _still_ might have made sense, because while I was only
barely conscious of the C++ marketplace at the time, with the language's
standardization nigh (for definitions of "nigh" stretching out many more
years than anyone planned), Sun's compiler guys might have feared giving
up mindshare and influence on the future ISO C++ to Borland or
Microsoft.

The foregoing speculative concern is consistent with the speed of Sun's
pivot to Oak/Java around the time Microsoft showed that (1) Windows NT
was going to block further penetration of Unix into the server OS sector
and substantially erode Unix's place in workstation and high-end PC
configurations _and_ (2) it was going to destroy Borland C++ with Visual
C++ by hook or by crook (the sort of stuff that got Bill Gates haled
into a CSPAN-televised Congressional hearing a few years later, but with
respect to Web browsers).

> The ways of Sun could be strange.

Until you get to a level where decision makers truly have no
accountability for anything they do (don't strain yourself looking for
examples in the news), I've found (from my minuscule sampling of
industry) that business decisions can usually be explained rationally.
The problem is that the rationales are often kept secret, sometimes in
the name of "strategy" but more often, I think, to keep line staff in
their place instead of critically considering management decisions--
unless they're willing to join political alliances and thereby make
themselves (even more) vulnerable to dismissal for unspoken reasons.

That said, I'm sure it would surprise no one if the "real reason" turned
out to be a stupid one.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Bakul Shah via TUHS]

On Feb 28, 2025, at 4:16 PM, segaloco via TUHS <tuhs@tuhs.org> wrote:
> 
> Given that anything that obeys the ABI and has assembler entries to the kernel
> can request services, it seems to me it would be possible to stand up a
> user-land without C being present.  Have any UNIXen ever done this after the
> advent of C?

vinix is written in the V language and can have userland written in V as
well but so far the compiler compiles to c (so requires a c compiler) so
not sure it qualifies + its development seems to have stalled somewhat.

IIRC there is at least one v6 level (toy?) OS written in rust with a
rust only userland. May be for anything non-toy you'd have to provide
a C compatible API.

Personally I don't see much point in reimplementing a 50+ year old OS in
a new language; at least do something new and innovative (with unix
emulation for dusty decks) but ¯\_(ツ)_/¯

[TUHS] Re: Any UNIX With No C In Userland?

[Grant Taylor via TUHS]

On 3/1/25 6:46 PM, Peter Yardley wrote:
> We used to build it three times, to be sure, to be sure, to be 
> sure. Once to get a working compiler, again to remove taint and once 
> more to get a build made with a taint free compiler.

I've seen hints of this in Gentoo Stage 1 installs.  Use existing tools 
to build Gentoo versions of the tools.  Then use the Gentoo version of 
the tools to re-build the Gentoo version of the tools.  Then do an empty 
tree rebuild of everything using the Gentoo version of the tools.



-- 
Grant. . . .

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Sat, Mar 01, 2025 at 02:01:11PM -0800, Larry McVoy wrote:
> On Sat, Mar 01, 2025 at 01:51:29PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > segaloco via TUHS writes:
> > > Given that anything that obeys the ABI and has assembler entries to the ker=
> > > nel
> > > can request services, it seems to me it would be possible to stand up a
> > > user-land without C being present.  Have any UNIXen ever done this after th=
> > > e
> > > advent of C?
> > 
> > SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> > and made it a $$$ add on.  That move single-handedly made GCC the
> > reference compiler moving forward.
> 
> I think that OP was asking about a userland compiled with Pascal or Go
> or Rust, anything other than C.  
> 
> I don't think it was a question of commercial C or Gcc (I agree that it
> was a bonehead move on Sun's part).

The funny thing was that somewhere around then Sun Labs was paying Micheal
Tiemann to make g++ work.  With a deal that let him retain the rights to
the code.  I never understood that, one hand wants to charge for cc and
the other hand is paying for free g++?  The ways of Sun could be strange.

[TUHS] Re: Any UNIX With No C In Userland?

[Peter Yardley]

I remember building gcc with the bundled SUN C compiler. Cant’t remember what flags etc were needed.

We used to build it three times, to be sure, to be sure, to be sure. Once to get a working compiler, again to remove taint and once more to get a build made with a taint free compiler.

> On 2 Mar 2025, at 10:37 am, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
> On Sat, Mar 1, 2025 at 4:29 PM Clem Cole <clemc@ccc.com> wrote:
> Larry, you can correct me here, but it was when Sun finally wrote their own - learning from DEC [and Masscomp] that the real Bill Wulf' Green book style optimizer with its C compiler generated better code than the PCC ones.   Unfortunately, Sun's marketing (also ex-DEC) decided it could be a revenue source.  Unlike Masscomp, where we said to our ex-DEC marketing types— "Charge for the Fortran if you want to, but C is part of the system."  
> 
> IIRC: Sun continued to bundled a simple C compiler so you build the kernel, but it was trying to make $s on the compiler suite.
> 
> Yes. I think so. But I also think that said C compiler wasn't adequate to bootstrap gcc or that there were extra steps / workarounds needed to do that. This was during the K&R -> ANSI cutover that Sun did this as well, and the old compiler was definitely K&R only.
>   SW economics can be difficult.   Application firms like CAD or tools firms, of course, make all their money on their SW.   But systems companies make their money on the HW and need the compilers to generate the applications to build the ecosystem to sell the HW.   Funny thing, I have always said huge reason BLISS lost was that DEC charged for $5000 per CPU for it on TOPS or VMS, while  C was free with UNIX - even though the difference is the resulting code was remarkable.   So many people stayed away because they did not want to spend the extra $s.
> 
> Yea, BLISS might have been better, but making the case it was $5k per CPU better was super hard.
> 
> Warner
> 
> On Sat, Mar 1, 2025 at 5:08 PM Dan Cross <crossd@gmail.com> wrote:
> On Sat, Mar 1, 2025 at 5:01 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
> <lyndon@orthanc.ca> wrote:
> > segaloco via TUHS writes:
> > > Given that anything that obeys the ABI and has assembler entries to the ker=
> > > nel
> > > can request services, it seems to me it would be possible to stand up a
> > > user-land without C being present.  Have any UNIXen ever done this after th=
> > > e
> > > advent of C?
> >
> > SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> > and made it a $$$ add on.  That move single-handedly made GCC the
> > reference compiler moving forward.
> 
> I believe that was in the shift to Solaris, aka SunOS 5.x. As I
> recall, even the last versions of SunOS 4 came with a bundled compiler
> (though it was pre-ANSI, and probably PCC based).
> 
>         - Dan C.

.1.3.6.1.4.1.8852.4.2
Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: Any UNIX With No C In Userland?

[segaloco via TUHS]

On Saturday, March 1st, 2025 at 3:37 PM, Warner Losh <imp@bsdimp.com> wrote:

> 
> 
> On Sat, Mar 1, 2025 at 4:29 PM Clem Cole <clemc@ccc.com> wrote:
> 
> > Larry, you can correct me here, but it was when Sun finally wrote their own - learning from DEC [and Masscomp] that the real Bill Wulf' Green book style optimizer with its C compiler generated better code than the PCC ones. Unfortunately, Sun's marketing (also ex-DEC) decided it could be a revenue source. Unlike Masscomp, where we said to our ex-DEC marketing types— "Charge for the Fortran if you want to, but C is part of the system."
> > 
> > IIRC: Sun continued to bundled a simple C compiler so you build the kernel, but it was trying to make $s on the compiler suite.
> 
> 
> Yes. I think so. But I also think that said C compiler wasn't adequate to bootstrap gcc or that there were extra steps / workarounds needed to do that. This was during the K&R -> ANSI cutover that Sun did this as well, and the old compiler was definitely K&R only.
> 
> > SW economics can be difficult. Application firms like CAD or tools firms, of course, make all their money on their SW. But systems companies make their money on the HW and need the compilers to generate the applications to build the ecosystem to sell the HW. Funny thing, I have always said huge reason BLISS lost was that DEC charged for $5000 per CPU for it on TOPS or VMS, while C was free with UNIX - even though the difference is the resulting code was remarkable. So many people stayed away because they did not want to spend the extra $s.
> 
> 
> Yea, BLISS might have been better, but making the case it was $5k per CPU better was super hard.
> 
> 
> Warner
>

I don't think like a business type, but to my mind cheap-to-free, accessible development tools are a no-brainer.  More surface area for devs means more devs able to target your system means more likelihood of killer apps showing up on your platform.  If it's locked up so tight nobody can sustainably write software, then the lifeblood of your OS goes down the tubes.  Again though, not claiming to be an expert on the business side of things, restrictive dev tool access just echoes of the same gripes I have with hardware IP for which the interfaces/datasheets are under expensive and arcane NDAs.  Like, okay, thanks for making the risk of evaluating your platform untenable for a large tract of the software community I guess...eval boards are already expensive enough.

But I digress, I seem to recall reading in another thread here that AIX may have had a fair deal of IBM stuff like perhaps some PL/I or PL/S down in the guts of significant chunks at one point, but I couldn't speak to that with any authority.  I could see IBM what with their legacy in languages bristling at letting C be the star of the show.

- Matt G.

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

I didn't have anything to do with the compiler group so I have no idea what
they were thinking.  So long as cc compiled the kernel without bugs, they
did their own thing.  I have no idea who thought it was a good idea to
unbundle C, I was not a fan but wasn't important enough that my opinion
held sway.

Rob Gingell would likely know.

On Sat, Mar 01, 2025 at 06:28:58PM -0500, Clem Cole wrote:
> Larry, you can correct me here, but it was when Sun finally wrote their own
> - learning from DEC [and Masscomp] that the real Bill Wulf' Green book
> style optimizer with its C compiler generated better code than the PCC
> ones.   Unfortunately, Sun's marketing (also ex-DEC) decided it could be a
> revenue source.  Unlike Masscomp, where we said to our ex-DEC marketing
> types??? "Charge for the Fortran if you want to, but C is part of the
> system."
> 
> IIRC: Sun continued to bundled a simple C compiler so you build the kernel,
> but it was trying to make $s on the compiler suite.
> 
>  SW economics can be difficult.   Application firms like CAD or tools
> firms, of course, make all their money on their SW.   But systems
> companies make their money on the HW and need the compilers to generate the
> applications to build the ecosystem to sell the HW.   Funny thing, I have
> always said huge reason BLISS lost was that DEC charged for $5000 per CPU
> for it on TOPS or VMS, while  C was free with UNIX - even though the
> difference is the resulting code was remarkable.   So many people stayed
> away because they did not want to spend the extra $s.
> ???
> 
> On Sat, Mar 1, 2025 at 5:08???PM Dan Cross <crossd@gmail.com> wrote:
> 
> > On Sat, Mar 1, 2025 at 5:01???PM Lyndon Nerenberg (VE7TFX/VE6BBM)
> > <lyndon@orthanc.ca> wrote:
> > > segaloco via TUHS writes:
> > > > Given that anything that obeys the ABI and has assembler entries to
> > the ker=
> > > > nel
> > > > can request services, it seems to me it would be possible to stand up a
> > > > user-land without C being present.  Have any UNIXen ever done this
> > after th=
> > > > e
> > > > advent of C?
> > >
> > > SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> > > and made it a $$$ add on.  That move single-handedly made GCC the
> > > reference compiler moving forward.
> >
> > I believe that was in the shift to Solaris, aka SunOS 5.x. As I
> > recall, even the last versions of SunOS 4 came with a bundled compiler
> > (though it was pre-ANSI, and probably PCC based).
> >
> >         - Dan C.
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

On Sat, Mar 1, 2025 at 4:29 PM Clem Cole <clemc@ccc.com> wrote:

> Larry, you can correct me here, but it was when Sun finally wrote their
> own - learning from DEC [and Masscomp] that the real Bill Wulf' Green book
> style optimizer with its C compiler generated better code than the PCC
> ones.   Unfortunately, Sun's marketing (also ex-DEC) decided it could be a
> revenue source.  Unlike Masscomp, where we said to our ex-DEC marketing
> types— "Charge for the Fortran if you want to, but C is part of the
> system."
>
> IIRC: Sun continued to bundled a simple C compiler so you build the
> kernel, but it was trying to make $s on the compiler suite.
>

Yes. I think so. But I also think that said C compiler wasn't adequate to
bootstrap gcc or that there were extra steps / workarounds needed to do
that. This was during the K&R -> ANSI cutover that Sun did this as well,
and the old compiler was definitely K&R only.


>  SW economics can be difficult.   Application firms like CAD or tools
> firms, of course, make all their money on their SW.   But systems
> companies make their money on the HW and need the compilers to generate the
> applications to build the ecosystem to sell the HW.   Funny thing, I have
> always said huge reason BLISS lost was that DEC charged for $5000 per CPU
> for it on TOPS or VMS, while  C was free with UNIX - even though the
> difference is the resulting code was remarkable.   So many people stayed
> away because they did not want to spend the extra $s.
>

Yea, BLISS might have been better, but making the case it was $5k per CPU
better was super hard.

Warner

On Sat, Mar 1, 2025 at 5:08 PM Dan Cross <crossd@gmail.com> wrote:
>
>> On Sat, Mar 1, 2025 at 5:01 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
>> <lyndon@orthanc.ca> wrote:
>> > segaloco via TUHS writes:
>> > > Given that anything that obeys the ABI and has assembler entries to
>> the ker=
>> > > nel
>> > > can request services, it seems to me it would be possible to stand up
>> a
>> > > user-land without C being present.  Have any UNIXen ever done this
>> after th=
>> > > e
>> > > advent of C?
>> >
>> > SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
>> > and made it a $$$ add on.  That move single-handedly made GCC the
>> > reference compiler moving forward.
>>
>> I believe that was in the shift to Solaris, aka SunOS 5.x. As I
>> recall, even the last versions of SunOS 4 came with a bundled compiler
>> (though it was pre-ANSI, and probably PCC based).
>>
>>         - Dan C.
>>
>

[-- Attachment #2: Type: text/html, Size: 4058 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

Larry, you can correct me here, but it was when Sun finally wrote their own
- learning from DEC [and Masscomp] that the real Bill Wulf' Green book
style optimizer with its C compiler generated better code than the PCC
ones.   Unfortunately, Sun's marketing (also ex-DEC) decided it could be a
revenue source.  Unlike Masscomp, where we said to our ex-DEC marketing
types— "Charge for the Fortran if you want to, but C is part of the
system."

IIRC: Sun continued to bundled a simple C compiler so you build the kernel,
but it was trying to make $s on the compiler suite.

 SW economics can be difficult.   Application firms like CAD or tools
firms, of course, make all their money on their SW.   But systems
companies make their money on the HW and need the compilers to generate the
applications to build the ecosystem to sell the HW.   Funny thing, I have
always said huge reason BLISS lost was that DEC charged for $5000 per CPU
for it on TOPS or VMS, while  C was free with UNIX - even though the
difference is the resulting code was remarkable.   So many people stayed
away because they did not want to spend the extra $s.
ᐧ

On Sat, Mar 1, 2025 at 5:08 PM Dan Cross <crossd@gmail.com> wrote:

> On Sat, Mar 1, 2025 at 5:01 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
> <lyndon@orthanc.ca> wrote:
> > segaloco via TUHS writes:
> > > Given that anything that obeys the ABI and has assembler entries to
> the ker=
> > > nel
> > > can request services, it seems to me it would be possible to stand up a
> > > user-land without C being present.  Have any UNIXen ever done this
> after th=
> > > e
> > > advent of C?
> >
> > SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> > and made it a $$$ add on.  That move single-handedly made GCC the
> > reference compiler moving forward.
>
> I believe that was in the shift to Solaris, aka SunOS 5.x. As I
> recall, even the last versions of SunOS 4 came with a bundled compiler
> (though it was pre-ANSI, and probably PCC based).
>
>         - Dan C.
>

[-- Attachment #2: Type: text/html, Size: 3226 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Sat, Mar 1, 2025 at 5:01 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
<lyndon@orthanc.ca> wrote:
> segaloco via TUHS writes:
> > Given that anything that obeys the ABI and has assembler entries to the ker=
> > nel
> > can request services, it seems to me it would be possible to stand up a
> > user-land without C being present.  Have any UNIXen ever done this after th=
> > e
> > advent of C?
>
> SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> and made it a $$$ add on.  That move single-handedly made GCC the
> reference compiler moving forward.

I believe that was in the shift to Solaris, aka SunOS 5.x. As I
recall, even the last versions of SunOS 4 came with a bundled compiler
(though it was pre-ANSI, and probably PCC based).

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Larry McVoy]

On Sat, Mar 01, 2025 at 01:51:29PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> segaloco via TUHS writes:
> > Given that anything that obeys the ABI and has assembler entries to the ker=
> > nel
> > can request services, it seems to me it would be possible to stand up a
> > user-land without C being present.  Have any UNIXen ever done this after th=
> > e
> > advent of C?
> 
> SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
> and made it a $$$ add on.  That move single-handedly made GCC the
> reference compiler moving forward.

I think that OP was asking about a userland compiled with Pascal or Go
or Rust, anything other than C.  

I don't think it was a question of commercial C or Gcc (I agree that it
was a bonehead move on Sun's part).
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Any UNIX With No C In Userland?

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

segaloco via TUHS writes:
> Given that anything that obeys the ABI and has assembler entries to the ker=
> nel
> can request services, it seems to me it would be possible to stand up a
> user-land without C being present.  Have any UNIXen ever done this after th=
> e
> advent of C?

SunOS 4.0 or 4.1 was when the Sun geniouses unbundled the C compiler
and made it a $$$ add on.  That move single-handedly made GCC the
reference compiler moving forward.

--lyndon

[TUHS] Re: Any UNIX With No C In Userland?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

I started u-root in 2011 because I did not want to do a yocto or onei or
buildroot ever again. u-root has found wide application in firmware. U-root
runs on anything Go runs on. Andrea Barisini has even targeted Go to bare
metal with Tamago, and u-root runs there too. Tinygo can compile much of it
to its 200 bare metal targets as well.

The late Andrey Mirtchovski, known to many of you, contributed a lot to the
early going.

I should not digress too much from TUHS here, so I'll leave it at that.



On Fri, Feb 28, 2025 at 7:41 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Fri, Feb 28, 2025, 7:11 PM Dan Cross <crossd@gmail.com> wrote:
>
>> On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>> > Given that anything that obeys the ABI and has assembler entries to the
>> kernel
>> > can request services, it seems to me it would be possible to stand up a
>> > user-land without C being present.  Have any UNIXen ever done this
>> after the
>> > advent of C?
>>
>> Kind of. u-root is a userland in Go, but is more targeted towards
>> embedded applications (Ron will correct me if I am mistaken there)
>
>
> Yea. It's reason to exist is for LinuxBoot scripting, though lots of other
> uses are possible. I know it from LinuxBoot...
>
> uutils is a Rust reimplementation of most of the GNU coreutils tools,
>> but not (I don't think) the C library.
>>
>
> Correct. Rust uses it's own library for system calls. This is a never
> ending series of problems for FreeBSD since the C API sometimes differs
> slightly with what's passed to the kernel and those seemingly trivial
> differences cause bugs. Also, new system calls can take a while (years) to
> appear. FreeBSD moved inodes to 64 bits 10 years ago and it was only in the
> last years that rust stopped using the old 32bit inode system calls.
>
> Warner
>
>         - Dan C.
>>
>

[-- Attachment #2: Type: text/html, Size: 3396 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Fri, Feb 28, 2025, 7:11 PM Dan Cross <crossd@gmail.com> wrote:

> On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> > Given that anything that obeys the ABI and has assembler entries to the
> kernel
> > can request services, it seems to me it would be possible to stand up a
> > user-land without C being present.  Have any UNIXen ever done this after
> the
> > advent of C?
>
> Kind of. u-root is a userland in Go, but is more targeted towards
> embedded applications (Ron will correct me if I am mistaken there)


Yea. It's reason to exist is for LinuxBoot scripting, though lots of other
uses are possible. I know it from LinuxBoot...

uutils is a Rust reimplementation of most of the GNU coreutils tools,
> but not (I don't think) the C library.
>

Correct. Rust uses it's own library for system calls. This is a never
ending series of problems for FreeBSD since the C API sometimes differs
slightly with what's passed to the kernel and those seemingly trivial
differences cause bugs. Also, new system calls can take a while (years) to
appear. FreeBSD moved inodes to 64 bits 10 years ago and it was only in the
last years that rust stopped using the old 32bit inode system calls.

Warner

        - Dan C.
>

[-- Attachment #2: Type: text/html, Size: 2264 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Dan Cross]

On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> Given that anything that obeys the ABI and has assembler entries to the kernel
> can request services, it seems to me it would be possible to stand up a
> user-land without C being present.  Have any UNIXen ever done this after the
> advent of C?

Kind of. u-root is a userland in Go, but is more targeted towards
embedded applications (Ron will correct me if I am mistaken there).
uutils is a Rust reimplementation of most of the GNU coreutils tools,
but not (I don't think) the C library.

        - Dan C.

[TUHS] Re: Any UNIX With No C In Userland?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Michel Gien lead a Unix reimplementation in Pascal (French SOL project) in
the late 1970s/early 1980.  Later they did a second version in C++ which
was called Chorus. You'll have to ask Michel but I don’t think Sol required
a C subsystem but I believe it had one to allow code to be imported.

I never knew what compiler his team used but I was once told it was the
Amsterdam compilers.   If that is true, you could claim there is the boot
strap issue if you want to get into the purity of did it need C.

But once running there would not have been any need for it to be required.
Plus, there were many Pascal compilers in Pascal in those days, but most of
the compiler suites that allowed multiple front end were in C (such as the
Amsterdam kit and gcc).


Sent from a handheld expect more typos than usual


On Fri, Feb 28, 2025 at 7:16 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> Given that anything that obeys the ABI and has assembler entries to the
> kernel
> can request services, it seems to me it would be possible to stand up a
> user-land without C being present.  Have any UNIXen ever done this after
> the
> advent of C?
>
> - Matt G.
>

[-- Attachment #2: Type: text/html, Size: 3415 bytes --]

[TUHS] Re: Any UNIX With No C In Userland?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Fri, Feb 28, 2025, 5:16 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> Given that anything that obeys the ABI and has assembler entries to the
> kernel
> can request services, it seems to me it would be possible to stand up a
> user-land without C being present.  Have any UNIXen ever done this after
> the
> advent of C?
>

u-root is a tiny busybox like environment written entirely in go. It goes
one step farther: it demand compiles each binary as it's needed. The
compiler is small enough for it to be a space win and fast enough that the
system performance is adequate for it's primary purpose: using Linux to
boot Linux...

Warner

>

[-- Attachment #2: Type: text/html, Size: 1236 bytes --]