From tuhs at tuhs.org Sat Mar 1 01:03:39 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Fri, 28 Feb 2025 10:03:39 -0500 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: On 2/28/25 12:08 AM, Greg A. Woods wrote: > Some systems, e.g. macOS (nee OS X) somewhat solved the problem by > simply adding more swap space dynamically by creating files in the root > filesystem (until the disk fills). I think this is one of the things macOS inherited from NeXT. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From imp at bsdimp.com Sat Mar 1 01:32:16 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 28 Feb 2025 08:32:16 -0700 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: On Thu, Feb 27, 2025, 10:08 PM Greg A. Woods wrote: > At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent > wrote: > Subject: [TUHS] Re: Having dickens of a time compiling gcc-4.4.7 on tru64 . > > > > On Thu, Feb 27, 2025, 17:07 Phil Budne wrote: > > > > > Arrigo Triulzi wrote: > > > > > > My recall is that 4.2BSD would only give you (writable) memory it > > > could allocate swap space for. > > > > > > I think of the penchant for "overcommitting" memory > > > (and the cold hand of the OOM killer) as Linuxisms > > I'm pretty sure over-commit in virtual memory systems is older than > linux, and of course it's common in the BSDs now too. > I switched from early Linux to FreeBSD because Linux lacked overcommit at the time (or it was so buggy you had to disable it). I thought this was a 4.4bsd thing, but FreeBSD's VM saw heavy work for big workloads right away... VMS 4 or 5 allowed it, with enough tuning. Warner Windows-NT did it, as did early AIX. IBM'S VM does it, as do many other > virtual machine supervisors. Unix System V may even have done it. I > don't know where it originated, and I couldn't find a quick reference > online just now to give a history of it, but likely someone here does. > > AIX also had an "OOM" killer (but I think it was the paging system > itself, no a user-level process) -- which in early releases (the first > version 3 on RS/6000 in 1989 or 1990) just tromped on the biggest > process, which was usually the Xserver. I seem to remember the system > rebooting if X died too. Even earlier (for the RT) IBM had invented > SIGDANGER to warn of a pending OOM condition. Big users of memory could > catch SIGDANGER and know they had to release some memory if they could. > I think catchers of SIGDANGER would avoid the early SIGKILLs too, but I > don't believe the Xserver tried to catch SIGDANGER, at least not in > early releases. > > Some systems, e.g. macOS (nee OS X) somewhat solved the problem by > simply adding more swap space dynamically by creating files in the root > filesystem (until the disk fills). > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Sat Mar 1 01:57:47 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 28 Feb 2025 10:57:47 -0500 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> I’m probably a lost soul on this issue, but swap space is just a way to turn program bugs into performance problems. In HPC one says “real programs need real memory”. At SiCortex we ran 972 node cluster machines without any swap space (4 or 8 GB per node) and it worked fine. Of course we didn’t have any disks either, so we made a virtue of necessity. It is perfectly true that the OOM killer was feared and hated, but only because it couldn’t identify the actual bad apple. I realize this attitude only works when you (pretty much) dedicate a node to running a single program at a time, but that is how most HPC systems of the time worked. -L From drb at msu.edu Sat Mar 1 02:04:49 2025 From: drb at msu.edu (Dennis Boone) Date: Fri, 28 Feb 2025 11:04:49 -0500 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: (Your message of Fri, 28 Feb 2025 10:57:47 -0500.) <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> References: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> > I’m probably a lost soul on this issue, but swap space is just a way > to turn program bugs into performance problems. You're hardly the only one. Some years ago, running Linux web and database servers, I quit creating swap space. A runaway program would turn the system into an infinite game of shuffle-the-pages well before the OOM killer actually decided to kill something, and in that state, one couldn't even reboot. This expanded the time window of "broken" from tens of seconds, and perhaps a service restart, into tens of minutes and a power button recovery. Every #$%^&* time. De From tuhs at tuhs.org Sat Mar 1 02:12:19 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 28 Feb 2025 16:12:19 +0000 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> References: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> Message-ID: On Friday, February 28th, 2025 at 8:04 AM, Dennis Boone wrote: > > I’m probably a lost soul on this issue, but swap space is just a way > > > to turn program bugs into performance problems. > > > You're hardly the only one. Some years ago, running Linux web and > database servers, I quit creating swap space. A runaway program would > turn the system into an infinite game of shuffle-the-pages well before > the OOM killer actually decided to kill something, and in that state, > one couldn't even reboot. This expanded the time window of "broken" > from tens of seconds, and perhaps a service restart, into tens of > minutes and a power button recovery. Every #$%^&* time. > > De I've read several bits of guidance lately suggesting avoiding swap due to the increasing prevalence of solid-state memories. The assertion is that I/O heavy swapping, especially if you get into a thrashing state, is liable to age current storage technologies much more than it would have in the platter disk era. I've heard contrary opinions that it isn't as large of a liability in reality. I haven't settled on one or the other, I keep a swap file around on the microSD that runs my RPi, but I've only needed to swapon, like OP, when compiling gcc. - Matt G. From imp at bsdimp.com Sat Mar 1 02:20:20 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 28 Feb 2025 09:20:20 -0700 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> Message-ID: On Fri, Feb 28, 2025 at 9:12 AM segaloco via TUHS wrote: > On Friday, February 28th, 2025 at 8:04 AM, Dennis Boone > wrote: > > > > I’m probably a lost soul on this issue, but swap space is just a way > > > > > to turn program bugs into performance problems. > > > > > > You're hardly the only one. Some years ago, running Linux web and > > database servers, I quit creating swap space. A runaway program would > > turn the system into an infinite game of shuffle-the-pages well before > > the OOM killer actually decided to kill something, and in that state, > > one couldn't even reboot. This expanded the time window of "broken" > > from tens of seconds, and perhaps a service restart, into tens of > > minutes and a power button recovery. Every #$%^&* time. > > > > De > > I've read several bits of guidance lately suggesting avoiding swap due to > the increasing prevalence of solid-state memories. The assertion is that > I/O heavy swapping, especially if you get into a thrashing state, is liable > to age current storage technologies much more than it would have in the > platter disk era. I've heard contrary opinions that it isn't as large of a > liability in reality. I haven't settled on one or the other, I keep a swap > file around on the microSD that runs my RPi, but I've only needed to > swapon, like OP, when compiling gcc. > Swapping to flash can be fine. The days when a "spot" could be worn out are 20 years in the past. If you use it as a "shock absorber" to cope with transient loads, there's no issues. However a lot depends on which kind of flash you have, you might have trouble if the load is constant. Today there's a wide range of flash drives. Ranging from < .1DWPD drives (you can't write even 10% of the drive's capacity in one day w/o wearing it out in the warranty period) to 3, 5 or 10 DWPD drives. 0.3 and 1.0 seem popular in the consumer / prosumer / low-end-datacenter space. Those can be a problem if you are constantly swapping (but again are fine for coping with transients). The MicroSD is likely to be closer to the .1-.3 DWPD (unless you bought an expensive one). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sat Mar 1 02:42:32 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Fri, 28 Feb 2025 08:42:32 -0800 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> Message-ID: The counterpoint to "just say no to swapping" is that sometimes you really, really, want a job to proceed even if at a glacial pace. Some years ago I had to do a Linux kernel build on a 1GB(maybe less?) MIPS system, and even though it had oodles of swap space, the OOM killer kept biting. Turns out you have to tune "swappiness" in poorly documented ways to get Linux to actually use virtual memory. I think the build took about a week once it worked. On Fri, Feb 28, 2025 at 8:04 AM Dennis Boone wrote: > > I’m probably a lost soul on this issue, but swap space is just a way > > to turn program bugs into performance problems. > > You're hardly the only one. Some years ago, running Linux web and > database servers, I quit creating swap space. A runaway program would > turn the system into an infinite game of shuffle-the-pages well before > the OOM killer actually decided to kill something, and in that state, > one couldn't even reboot. This expanded the time window of "broken" > from tens of seconds, and perhaps a service restart, into tens of > minutes and a power button recovery. Every #$%^&* time. > > De > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drb at msu.edu Sat Mar 1 03:09:49 2025 From: drb at msu.edu (Dennis Boone) Date: Fri, 28 Feb 2025 12:09:49 -0500 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: (Your message of Fri, 28 Feb 2025 16:12:19 +0000.) References: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> Message-ID: <20250228170949.97B694EADFF@yagi.h-net.msu.edu> > I've read several bits of guidance lately suggesting avoiding swap > due to the increasing prevalence of solid-state memories. The > assertion is that I/O heavy swapping, especially if you get into a > thrashing state, is liable to age current storage technologies much > more than it would have in the platter disk era. I was told a few years ago by a smart person I respect that one of the reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB max) was because Apple was shipping SSD in them, so the performance hit wasn't really noticeable. One hopes those were sturdy (DWPD) SSDs, but barring the marketing decisions (removing ports people want), Apple's hardware engineering is usually decent. De From tuhs at tuhs.org Sat Mar 1 03:17:08 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 28 Feb 2025 09:17:08 -0800 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> Message-ID: In Feb 2013 I built the raspbian kernel on the original Raspi (512MB). Took about 10 hours. Don't recall if any swap was used but likely. Not sure how different was the raspbian kernel at that time compared to the stock linux kernel (if there is such a thing). I never wanted to repeat the build though! In contrast the plan9 kernel build took a minute. > On Feb 28, 2025, at 8:42 AM, Tom Lyon wrote: > > The counterpoint to "just say no to swapping" is that sometimes you really, really, want a job to proceed even if at a glacial pace. > > Some years ago I had to do a Linux kernel build on a 1GB(maybe less?) MIPS system, and even though it had oodles of swap space, the OOM killer kept biting. > Turns out you have to tune "swappiness" in poorly documented ways to get Linux to actually use virtual memory. I think the build took about a week once it worked. > > On Fri, Feb 28, 2025 at 8:04 AM Dennis Boone > wrote: >> > I’m probably a lost soul on this issue, but swap space is just a way >> > to turn program bugs into performance problems. >> >> You're hardly the only one. Some years ago, running Linux web and >> database servers, I quit creating swap space. A runaway program would >> turn the system into an infinite game of shuffle-the-pages well before >> the OOM killer actually decided to kill something, and in that state, >> one couldn't even reboot. This expanded the time window of "broken" >> from tens of seconds, and perhaps a service restart, into tens of >> minutes and a power button recovery. Every #$%^&* time. >> >> De -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sat Mar 1 05:35:44 2025 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 28 Feb 2025 11:35:44 -0800 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: <20250228170949.97B694EADFF@yagi.h-net.msu.edu> References: <842124E7-A189-4743-B5C2-2F4E9166B1AB@serissa.com> <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <20250228160449.2FDB04EAE12@yagi.h-net.msu.edu> <20250228170949.97B694EADFF@yagi.h-net.msu.edu> Message-ID: At Fri, 28 Feb 2025 12:09:49 -0500, Dennis Boone wrote: Subject: [TUHS] Re: VM over-commit (and the OOM killers) > > I was told a few years ago by a smart person I respect that one of the > reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB > max) was because Apple was shipping SSD in them, so the performance hit > wasn't really noticeable. One hopes those were sturdy (DWPD) SSDs, but > barring the marketing decisions (removing ports people want), Apple's > hardware engineering is usually decent. That's probably mostly true, but also misguided and ignorant of the actual behaviour of RAM-starved systems. I suspect it was policy based on memory prices at some time in the past, but seemingly hasn't been re-evaluated for modern workloads more recently. MacOS has long been OK at handling a little bit of paging, but seems to get to the state of thrashing far sooner than one would expect it to. I find Apple's default memory provisioning to be half as big as it should be for the real-world uses most people encounter, especially these days with the bloatware that is modern desktop software (especially browsers!) On my BSD systems I always allocate lots of swap space (I try for at least as much as I have RAM, if not more), but I get worried any time I see any of it used. As Warner said, it's fine for transient loads, but if a system starts paging during regular production loads then I have a big problem. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From johnl at taugh.com Sat Mar 1 06:18:36 2025 From: johnl at taugh.com (John Levine) Date: 28 Feb 2025 15:18:36 -0500 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> <20250228170949.97B694EADFF@yagi.h-net.msu.edu> <842 Message-ID: <20250228201836.B76C3BE2FB6B@ary.qy> It appears that Greg A. Woods said: >-=-=-=-=-=- > >At Fri, 28 Feb 2025 12:09:49 -0500, Dennis Boone wrote: >Subject: [TUHS] Re: VM over-commit (and the OOM killers) >> >> I was told a few years ago by a smart person I respect that one of the >> reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB >> max) was because Apple was shipping SSD in them, ... >That's probably mostly true, but also misguided and ignorant of the >actual behaviour of RAM-starved systems. I suspect it was policy based >on memory prices at some time in the past, but seemingly hasn't been >re-evaluated for modern workloads more recently. Current Macbooks all start at 16GB, and the biggest Pro model can have 128GB and an 8TB SSD for the low low price of $7200. I agree it's memory prices to make a balanced system. For a lot of people who are not doing heavy computing 8GB is fine. If you're doing a lot of compiling or ray-tracing, you need more computer. R's, John From tuhs at tuhs.org Sat Mar 1 06:53:20 2025 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Fri, 28 Feb 2025 21:53:20 +0100 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: Message-ID: <218EA880-DBF3-4FAA-B3AB-B73790207181@alchemistowl.org> On 28 Feb 2025, at 20:36, Greg A. Woods wrote: > That's probably mostly true, but also misguided and ignorant of the > actual behaviour of RAM-starved systems. I suspect it was policy based > on memory prices at some time in the past, but seemingly hasn't been > re-evaluated for modern workloads more recently. I strongly agree: as an old Unix hand hitting swap was something you wanted to avoid at all cost, except for certain cases where swap use could be replaced by accurate use of files to swap data in and out of RAM during programme execution because of the predictability of data accesses. It was still bad programming but not as lethal as thrashing. The current macOS is a disappointment in that respect: on a 64GB machine when running the Apple Virtualisation Framework for VMs (UTM and Parallels) I am surprised at how just a couple of 8GB VMs can send the VMM into a frenzy. My FreeBSD bhyve hosts with similar memory and VM load do not exhibit this behaviour at all, despite ZFS ARC. Arrigo From tuhs at tuhs.org Sat Mar 1 10:16:02 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 01 Mar 2025 00:16:02 +0000 Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: 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. From imp at bsdimp.com Sat Mar 1 11:02:35 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 28 Feb 2025 18:02:35 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Fri, Feb 28, 2025, 5:16 PM segaloco via TUHS 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Mar 1 11:15:14 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 28 Feb 2025 20:15:14 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Mar 1 12:10:29 2025 From: crossd at gmail.com (Dan Cross) Date: Fri, 28 Feb 2025 21:10:29 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS 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. From imp at bsdimp.com Sat Mar 1 13:22:41 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 28 Feb 2025 20:22:41 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Fri, Feb 28, 2025, 7:11 PM Dan Cross wrote: > On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Mar 1 14:01:11 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 28 Feb 2025 20:01:11 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: 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 wrote: > > > On Fri, Feb 28, 2025, 7:11 PM Dan Cross wrote: > >> On Fri, Feb 28, 2025 at 7:26 PM segaloco via TUHS 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Mar 1 22:11:47 2025 From: tuhs at tuhs.org (Jason Stevens via TUHS) Date: Sat, 1 Mar 2025 12:11:47 -0000 Subject: [TUHS] DCJ-11 processor with 20k FPGA Message-ID: I assume people have seen this? https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main It's capable of running Unix v1 & some limited amount of v6 among other things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from AliExpress. Kind of neat to combine a real processor with a simple FPGA implementation of the hardware. From lyndon at orthanc.ca Sun Mar 2 07:51:29 2025 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Sat, 01 Mar 2025 13:51:29 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: 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 From lm at mcvoy.com Sun Mar 2 08:01:11 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Mar 2025 14:01:11 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <20250301220111.GB13234@mcvoy.com> 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 From crossd at gmail.com Sun Mar 2 08:07:48 2025 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Mar 2025 17:07:48 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 5:01 PM 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 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. From clemc at ccc.com Sun Mar 2 09:28:58 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Mar 2025 18:28:58 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: 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 wrote: > On Sat, Mar 1, 2025 at 5:01 PM 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Mar 2 09:37:33 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Mar 2025 16:37:33 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 4:29 PM 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. > 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 wrote: > >> On Sat, Mar 1, 2025 at 5:01 PM 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 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Mar 2 09:38:05 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Mar 2025 15:38:05 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <20250301233805.GC13234@mcvoy.com> 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 wrote: > > > On Sat, Mar 1, 2025 at 5:01???PM 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 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 From tuhs at tuhs.org Sun Mar 2 09:46:59 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 01 Mar 2025 23:46:59 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Saturday, March 1st, 2025 at 3:37 PM, Warner Losh wrote: > > > On Sat, Mar 1, 2025 at 4:29 PM 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. > > > 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. From crossd at gmail.com Sun Mar 2 09:46:46 2025 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Mar 2025 18:46:46 -0500 Subject: [TUHS] Compilers (was Re: Any UNIX With No C In Userland?) In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 6:37 PM Warner Losh wrote: > On Sat, Mar 1, 2025 at 4:29 PM 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. > > 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. It's been years but I remember bootstrapping gcc with the `cc` that came with SunOS (was it in /usr/ucb? For some reason that sticks in my memory). I don't recall additional workaround steps, though perhaps one had to install other GNU utilities? Gcc got you ANSI and some amount of compatibility with C++ (which hadn't yet been standardized). I can't remember if Objective-C was in gcc at the time yet, but I suspect it was via NeXT. But beyond raw language compatibility, I don't remember it being a very good compiler at the time. It didn't really start to become competitive until GCC 3 or so. >> 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. People doing HPC locally used to pay for better commercial compilers; GCC and Clang have definitely caught up now, but I'm sure they were only concerned with Fortran at the time. The Portland Group compiler was pretty darned good in the mid-90s when we were starting to look at cheap x86 boxes because of the price/performance ratio: even though the big RISC machines were still better in terms of absolute numbers, they were clearly losing the battle on the cost ratio. - Dan C. >> On Sat, Mar 1, 2025 at 5:08 PM Dan Cross wrote: >>> >>> On Sat, Mar 1, 2025 at 5:01 PM 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 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. From imp at bsdimp.com Sun Mar 2 09:57:39 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Mar 2025 16:57:39 -0700 Subject: [TUHS] Compilers (was Re: Any UNIX With No C In Userland?) In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 4:47 PM Dan Cross wrote: > On Sat, Mar 1, 2025 at 6:37 PM Warner Losh wrote: > > On Sat, Mar 1, 2025 at 4:29 PM 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. > > > > 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. > > It's been years but I remember bootstrapping gcc with the `cc` that > came with SunOS (was it in /usr/ucb? For some reason that sticks in my > memory). I don't recall additional workaround steps, though perhaps > one had to install other GNU utilities? > That may be what I'm recalling... you needed gmake, binutils, bison, flex and maybe a few others for sure... I also recall that 1.x was a lot harder to get going than 2.x on sparc. > Gcc got you ANSI and some amount of compatibility with C++ (which > hadn't yet been standardized). I can't remember if Objective-C was in > gcc at the time yet, but I suspect it was via NeXT. But beyond raw > language compatibility, I don't remember it being a very good compiler > at the time. It didn't really start to become competitive until GCC 3 > or so. > Yea, even gcc2 was a huge win. > >> 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. > > People doing HPC locally used to pay for better commercial compilers; > GCC and Clang have definitely caught up now, but I'm sure they were > only concerned with Fortran at the time. The Portland Group compiler > was pretty darned good in the mid-90s when we were starting to look at > cheap x86 boxes because of the price/performance ratio: even though > the big RISC machines were still better in terms of absolute numbers, > they were clearly losing the battle on the cost ratio. > Yea. There comes a point where large swarms of adequate at a reasonable price is a better call than a few, more expensive things that get the job done in a smaller footprint of floor space or time (but higher cost). For a lot of things that crossover took place in the 2000-2010 time frame. Warner > - Dan C. > > >> On Sat, Mar 1, 2025 at 5:08 PM Dan Cross wrote: > >>> > >>> On Sat, Mar 1, 2025 at 5:01 PM 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Sun Mar 2 10:10:58 2025 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sat, 1 Mar 2025 18:10:58 -0600 Subject: [TUHS] AIX (RT/PC & RS/6000) 1/2/3 compilers [was Re: Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On 3/1/2025 5:46 PM, segaloco via TUHS wrote: > > 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. For all our faults in the AIX team and IBM in general, there was no desire to have legacy IBM languages as primary in AIX. https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ tries to explain why PL.8 code existed in early AIX and how PL.8 code was eliminated in AIX 3 development. AIX for the RT 1&2 bundled pcc (with the HCR optimization phase in AIX 2). Since I left IBM in the midst of AIX 3 development, I'm not certain what happened with compilers after I left. Part of the confusion was IBM Toronto rewriting the Yorktown Research compiler to be a "product worthy" C compiler. There may have been desire to gain revenue for the Toronto compiler, but I assume that some some C compiler was bundled in AIX 3. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From peter.martin.yardley at gmail.com Sun Mar 2 10:46:27 2025 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sun, 2 Mar 2025 11:46:27 +1100 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <77926C79-1344-415A-9D23-BEC53D84CD1E@gmail.com> 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 wrote: > > > > On Sat, Mar 1, 2025 at 4:29 PM 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. > > 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 wrote: > On Sat, Mar 1, 2025 at 5:01 PM 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 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 at gmail.com From lm at mcvoy.com Sun Mar 2 11:17:40 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Mar 2025 17:17:40 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250301220111.GB13234@mcvoy.com> References: <20250301220111.GB13234@mcvoy.com> Message-ID: <20250302011740.GE31995@mcvoy.com> 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. From tuhs at tuhs.org Sun Mar 2 11:33:18 2025 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 1 Mar 2025 19:33:18 -0600 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <77926C79-1344-415A-9D23-BEC53D84CD1E@gmail.com> References: <77926C79-1344-415A-9D23-BEC53D84CD1E@gmail.com> Message-ID: <2a342b4f-b585-4d1f-9a3c-68ff317406a8@spamtrap.tnetconsulting.net> 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. . . . From tuhs at tuhs.org Sun Mar 2 11:58:15 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 1 Mar 2025 17:58:15 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> On Feb 28, 2025, at 4:16 PM, segaloco via TUHS 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 ¯\_(ツ)_/¯ From g.branden.robinson at gmail.com Sun Mar 2 12:07:37 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 1 Mar 2025 20:07:37 -0600 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302011740.GE31995@mcvoy.com> References: <20250301220111.GB13234@mcvoy.com> <20250302011740.GE31995@mcvoy.com> Message-ID: <20250302020737.aw6ef53l6h63pmew@illithid> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Sun Mar 2 12:14:27 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 1 Mar 2025 20:14:27 -0600 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302020737.aw6ef53l6h63pmew@illithid> References: <20250301220111.GB13234@mcvoy.com> <20250302011740.GE31995@mcvoy.com> <20250302020737.aw6ef53l6h63pmew@illithid> Message-ID: <20250302021427.ekjdiyc7eu7446of@illithid> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Sun Mar 2 12:16:57 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Mar 2025 18:16:57 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> Message-ID: <20250302021657.GD13234@mcvoy.com> 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 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 From crossd at gmail.com Sun Mar 2 12:43:56 2025 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Mar 2025 21:43:56 -0500 Subject: [TUHS] AIX (RT/PC & RS/6000) 1/2/3 compilers [was Re: Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 7:21 PM Charles H Sauer (he/him) wrote: > On 3/1/2025 5:46 PM, segaloco via TUHS wrote: > > 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. > > For all our faults in the AIX team and IBM in general, there was no > desire to have legacy IBM languages as primary in AIX. > > https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ > tries to explain why PL.8 code existed in early AIX and how PL.8 code > was eliminated in AIX 3 development. > > AIX for the RT 1&2 bundled pcc (with the HCR optimization phase in AIX 2). > > Since I left IBM in the midst of AIX 3 development, I'm not certain what > happened with compilers after I left. Part of the confusion was IBM > Toronto rewriting the Yorktown Research compiler to be a "product > worthy" C compiler. There may have been desire to gain revenue for the > Toronto compiler, but I assume that some some C compiler was bundled in > AIX 3. As I recall, you needed a license for the compiler suite on AIX 3; the compiler was XL C, and was very highly regarded (other compilers in the same general family were XL C++ and XL Fortran). By AIX 4 this was definitely true. - Dan C. From tuhs at tuhs.org Sun Mar 2 13:00:03 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 1 Mar 2025 19:00:03 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302021657.GD13234@mcvoy.com> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> Message-ID: <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> On Mar 1, 2025, at 6:16 PM, Larry McVoy 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! From lm at mcvoy.com Sun Mar 2 13:16:47 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Mar 2025 19:16:47 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> Message-ID: <20250302031646.GF13234@mcvoy.com> On Sat, Mar 01, 2025 at 07:00:03PM -0800, Bakul Shah wrote: > On Mar 1, 2025, at 6:16???PM, Larry McVoy 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. From imp at bsdimp.com Sun Mar 2 14:31:43 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Mar 2025 21:31:43 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302020737.aw6ef53l6h63pmew@illithid> References: <20250301220111.GB13234@mcvoy.com> <20250302011740.GE31995@mcvoy.com> <20250302020737.aw6ef53l6h63pmew@illithid> Message-ID: On Sat, Mar 1, 2025, 7:07 PM G. Branden Robinson < g.branden.robinson at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Mar 3 01:46:23 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 2 Mar 2025 07:46:23 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302020737.aw6ef53l6h63pmew@illithid> References: <20250301220111.GB13234@mcvoy.com> <20250302011740.GE31995@mcvoy.com> <20250302020737.aw6ef53l6h63pmew@illithid> Message-ID: <20250302154623.GG13234@mcvoy.com> 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. From stuff at riddermarkfarm.ca Mon Mar 3 02:35:21 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 2 Mar 2025 11:35:21 -0500 Subject: [TUHS] AIX (RT/PC & RS/6000) 1/2/3 compilers [was Re: Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <31abe80b-6ecc-26a9-698b-1513224b8a17@riddermarkfarm.ca> On 2025-03-01 21:43, Dan Cross wrote: > On Sat, Mar 1, 2025 at 7:21 PM Charles H Sauer (he/him) > wrote: >> On 3/1/2025 5:46 PM, segaloco via TUHS wrote: >>> 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. >> >> For all our faults in the AIX team and IBM in general, there was no >> desire to have legacy IBM languages as primary in AIX. >> >> https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ >> tries to explain why PL.8 code existed in early AIX and how PL.8 code >> was eliminated in AIX 3 development. >> >> AIX for the RT 1&2 bundled pcc (with the HCR optimization phase in AIX 2). >> >> Since I left IBM in the midst of AIX 3 development, I'm not certain what >> happened with compilers after I left. Part of the confusion was IBM >> Toronto rewriting the Yorktown Research compiler to be a "product >> worthy" C compiler. There may have been desire to gain revenue for the >> Toronto compiler, but I assume that some some C compiler was bundled in >> AIX 3. > > As I recall, you needed a license for the compiler suite on AIX 3; the > compiler was XL C, and was very highly regarded (other compilers in > the same general family were XL C++ and XL Fortran). By AIX 4 this was > definitely true. > > - Dan C. Some decades ago, I was checking whether our product ran properly on AIX (version forgotten). The xlc man page stated that at the highest optimisation level, the "semantics of the source code might not be respected" (or something very similar). I no longer remember the versions. Has anyone else seen this? S. From merlyn at geeks.org Mon Mar 3 02:45:01 2025 From: merlyn at geeks.org (Doug McIntyre) Date: Sun, 2 Mar 2025 10:45:01 -0600 Subject: [TUHS] Compilers (was Re: Any UNIX With No C In Userland?) In-Reply-To: References: Message-ID: On Sat, Mar 01, 2025 at 06:46:46PM -0500, Dan Cross wrote: > On Sat, Mar 1, 2025 at 6:37 PM Warner Losh wrote: >> 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. > > It's been years but I remember bootstrapping gcc with the `cc` that > came with SunOS (was it in /usr/ucb? For some reason that sticks in my > memory). I don't recall additional workaround steps, though perhaps > one had to install other GNU utilities? In that time period, the gcc distribution had a special bootstrap version (older version?) of itself that was capable specificly of being able to be compiled by the cc that SunOS shipped with that was intended to compile the kernel bits shipped to configure in new limits/drivers, etc. The first stages of getting gcc compiled on SunOS was compiling that bootstrap version of itself, and then using that bootstraped special version of gcc to then compile the regular/up-to-date version of gcc. Eventually after some gcc major version, it stopped supporting/bundling this special bootstrap version, and dropped support for bootstrapping itself up on SunOS. From tuhs at tuhs.org Mon Mar 3 03:29:31 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sun, 2 Mar 2025 09:29:31 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302031646.GF13234@mcvoy.com> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> Message-ID: <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> On Mar 1, 2025, at 7:16 PM, Larry McVoy 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. From tuhs at tuhs.org Mon Mar 3 03:54:01 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 02 Mar 2025 17:54:01 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> Message-ID: On Sunday, March 2nd, 2025 at 9:29 AM, Bakul Shah via TUHS wrote: > On Mar 1, 2025, at 7:16 PM, Larry McVoy lm at 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. From g.branden.robinson at gmail.com Mon Mar 3 04:39:05 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 2 Mar 2025 12:39:05 -0600 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> Message-ID: <20250302183905.ibxuwqyvj4pnrihy@illithid> At 2025-03-02T17:54:01+0000, segaloco via TUHS wrote: > On Sunday, March 2nd, 2025 at 9:29 AM, Bakul Shah via TUHS > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rich.salz at gmail.com Mon Mar 3 05:09:37 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 2 Mar 2025 14:09:37 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302154623.GG13234@mcvoy.com> References: <20250301220111.GB13234@mcvoy.com> <20250302011740.GE31995@mcvoy.com> <20250302020737.aw6ef53l6h63pmew@illithid> <20250302154623.GG13234@mcvoy.com> Message-ID: On Sun, Mar 2, 2025 at 10:46 AM Larry McVoy 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Mon Mar 3 06:51:26 2025 From: woods at robohack.ca (Greg A. Woods) Date: Sun, 02 Mar 2025 12:51:26 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> Message-ID: At Sat, 1 Mar 2025 19:00:03 -0800, Bakul Shah via TUHS 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From douglas.mcilroy at dartmouth.edu Mon Mar 3 07:45:40 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 2 Mar 2025 16:45:40 -0500 Subject: [TUHS] Language-lawyers' field day (was Any UNIX With No C In Userland?) Message-ID: > 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 { } Well, some things. 0.0f and other floating-point zero constants are represented by all-zero words (of various sizes) and are not integral constants. NULL does not "show up as an integral zero literal". 0==NULL is true only because 0 can be converted to NULL. Getting really lawyerly, one can cook up any number of bizarre "things that can possibly be represented" by an all-zero word, for example (char[4]){0,0,0,0}, and have no representation as an integral constant. Only 3 of the 5 examples fit the description of possibly being represented by an all-zero word. struct{} and union{} are gnu extensions with size zero. Even if you accept them as C, they have no machine representation and cannot be cast to int. The null pointer makes the list only thanks to the weasel-word "possibly". Although 0 can be cast to the null pointer, the result of casting a null pointer to int depends on its unspecified machine representation. Zero, of course, is a good choice because it's easy to test for, and is easy to omit from virtual address spaces. Doug From kevin.bowling at kev009.com Mon Mar 3 08:43:06 2025 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 2 Mar 2025 15:43:06 -0700 Subject: [TUHS] AIX (RT/PC & RS/6000) 1/2/3 compilers [was Re: Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: On Sat, Mar 1, 2025 at 5:11 PM Charles H Sauer (he/him) wrote: > > > > On 3/1/2025 5:46 PM, segaloco via TUHS wrote: > > > > > 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. > > For all our faults in the AIX team and IBM in general, there was no > desire to have legacy IBM languages as primary in AIX. > > https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ > tries to explain why PL.8 code existed in early AIX and how PL.8 code > was eliminated in AIX 3 development. > > AIX for the RT 1&2 bundled pcc (with the HCR optimization phase in AIX 2). > > Since I left IBM in the midst of AIX 3 development, I'm not certain what > happened with compilers after I left. Part of the confusion was IBM > Toronto rewriting the Yorktown Research compiler to be a "product > worthy" C compiler. There may have been desire to gain revenue for the > Toronto compiler, but I assume that some some C compiler was bundled in > AIX 3. AIX 3 still shipped with a compiler (see, for instance the N40 media https://www.ardent-tool.com/RS6000/7007/AIX.html) although I've never bothered to see if it was separately licensed or not (there is no key/drm). AIX 4 divorced the compiler from base went under a few names over the years: C fo AIX, xl C/C++, VisualAge C/C++. Lately things were rebased onto a clang frontend and called Open XL. The VisualAge one is kind of interesting because it includes the VisualAge SmallTalk derived IDE which eventually spawned the Eclipse IDE project. Slightly less clunky without the Java. > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/mas.to: CharlesHSauer > From bear at typewritten.org Mon Mar 3 09:03:09 2025 From: bear at typewritten.org (r.stricklin) Date: Sun, 2 Mar 2025 15:03:09 -0800 Subject: [TUHS] AIX (RT/PC & RS/6000) 1/2/3 compilers [was Re: Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <2241C6AE-8385-4864-AAAD-517CA297E524@typewritten.org> > On Mar 2, 2025, at 2:43 PM, Kevin Bowling wrote: > > AIX 3 still shipped with a compiler (see, for instance the N40 media > https://www.ardent-tool.com/RS6000/7007/AIX.html ) although I've never > bothered to see if it was separately licensed or not (there is no > key/drm). The N40 CD media may have included the compiler, but it also included a lot of other unbundled software features (e.g. AIXwindows, fax support, LocalTalk, WABI), so I don’t think this should be the benchmark. I’ve personally catalogged many sets of AIX 3 install tapes with only the various language runtime(s), and no compiler present. The tapes were generated for each customer and included only the features that were ordered. ok bear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Mar 3 09:25:39 2025 From: crossd at gmail.com (Dan Cross) Date: Sun, 2 Mar 2025 18:25:39 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250302183905.ibxuwqyvj4pnrihy@illithid> References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: On Sun, Mar 2, 2025 at 1:46 PM G. Branden Robinson 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. From gingell at computer.org Mon Mar 3 18:34:08 2025 From: gingell at computer.org (Rob Gingell) Date: Mon, 3 Mar 2025 00:34:08 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250301233805.GC13234@mcvoy.com> References: <20250301233805.GC13234@mcvoy.com> Message-ID: <3ea0b8a2-de64-4b15-9b0e-c497af27fd50@computer.org> 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. From peter.martin.yardley at gmail.com Mon Mar 3 21:31:13 2025 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Mon, 3 Mar 2025 22:31:13 +1100 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: 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 wrote: > > On Sun, Mar 2, 2025 at 1:46 PM G. Branden Robinson > 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 at gmail.com From paul.winalski at gmail.com Tue Mar 4 02:59:42 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 3 Mar 2025 11:59:42 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Tue Mar 4 03:38:33 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 3 Mar 2025 12:38:33 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> 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 wrote: > > On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Mar 4 03:55:10 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 03 Mar 2025 17:55:10 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> Message-ID: On Monday, March 3rd, 2025 at 9:38 AM, Lawrence Stewart 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. From lm at mcvoy.com Tue Mar 4 04:27:57 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 3 Mar 2025 10:27:57 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> Message-ID: <20250303182757.GR13234@mcvoy.com> 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 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? From imp at bsdimp.com Tue Mar 4 04:29:59 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 3 Mar 2025 11:29:59 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: On Mon, Mar 3, 2025, 10:00 AM Paul Winalski wrote: > On Mon, Mar 3, 2025 at 6:51 AM Peter Yardley < > peter.martin.yardley at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Mar 4 04:31:20 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 3 Mar 2025 11:31:20 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250303182757.GR13234@mcvoy.com> References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: On Mon, Mar 3, 2025, 11:28 AM Larry McVoy 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 > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Mar 4 04:45:21 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 03 Mar 2025 19:45:21 +0100 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: <20250303184521.QKG9ks8K@steffen%sdaoden.eu> Warner Losh wrote in : |On Mon, Mar 3, 2025, 11:28 AM Larry McVoy 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 |> |> 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) From crossd at gmail.com Tue Mar 4 04:50:07 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Mar 2025 13:50:07 -0500 Subject: [TUHS] Compilers (was Re: Any UNIX With No C In Userland?) In-Reply-To: References: Message-ID: On Sun, Mar 2, 2025 at 11:51 AM Doug McIntyre wrote: > On Sat, Mar 01, 2025 at 06:46:46PM -0500, Dan Cross wrote: > > On Sat, Mar 1, 2025 at 6:37 PM Warner Losh wrote: > >> 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. > > > > It's been years but I remember bootstrapping gcc with the `cc` that > > came with SunOS (was it in /usr/ucb? For some reason that sticks in my > > memory). I don't recall additional workaround steps, though perhaps > > one had to install other GNU utilities? > > > In that time period, the gcc distribution had a special bootstrap > version (older version?) of itself that was capable specificly of > being able to be compiled by the cc that SunOS shipped with that was > intended to compile the kernel bits shipped to configure in new limits/drivers, etc. > > The first stages of getting gcc compiled on SunOS was compiling that bootstrap > version of itself, and then using that bootstraped special version of gcc to then compile > the regular/up-to-date version of gcc. > > Eventually after some gcc major version, it stopped supporting/bundling this special bootstrap > version, and dropped support for bootstrapping itself up on SunOS. Huh. I totally believe you, but I have no memory of this. Perhaps I blanked it out; it does sound rather traumatic. - Dan C. From lars at nocrew.org Tue Mar 4 04:52:31 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 03 Mar 2025 18:52:31 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: (Paul Winalski's message of "Mon, 3 Mar 2025 11:59:42 -0500") References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: <7wfrjuj6a8.fsf@junk.nocrew.org> 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. From imp at bsdimp.com Tue Mar 4 05:45:50 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 3 Mar 2025 12:45:50 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250303184521.QKG9ks8K@steffen%sdaoden.eu> References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> <20250303184521.QKG9ks8K@steffen%sdaoden.eu> Message-ID: On Mon, Mar 3, 2025 at 11:45 AM Steffen Nurpmeso wrote: > Warner Losh wrote in > : > |On Mon, Mar 3, 2025, 11:28 AM Larry McVoy 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 > |> > |> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Tue Mar 4 06:20:40 2025 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 3 Mar 2025 15:20:40 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250303182757.GR13234@mcvoy.com> References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: 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. From crossd at gmail.com Tue Mar 4 06:44:20 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Mar 2025 15:44:20 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: On Mon, Mar 3, 2025 at 3:26 PM Steve Nickolas 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. From jnc at mercury.lcs.mit.edu Tue Mar 4 07:20:47 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 3 Mar 2025 16:20:47 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: <20250303212047.920C718C09C@mercury.lcs.mit.edu> > 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 From woods at robohack.ca Tue Mar 4 07:57:39 2025 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 03 Mar 2025 13:57:39 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <5574A68C-069D-4281-B66B-80541AF86B9C@iitbombay.org> <20250302021657.GD13234@mcvoy.com> <77C32157-6FC7-49D2-97B1-1B1A9E1E60C2@iitbombay.org> <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> Message-ID: At Mon, 3 Mar 2025 22:31:13 +1100, Peter Yardley 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From paul.winalski at gmail.com Tue Mar 4 08:00:18 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 3 Mar 2025 17:00:18 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250303182757.GR13234@mcvoy.com> References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: On Mon, Mar 3, 2025 at 1:28 PM Larry McVoy 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gingell at computer.org Tue Mar 4 08:51:06 2025 From: gingell at computer.org (Rob Gingell) Date: Mon, 3 Mar 2025 14:51:06 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> 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.) From crossd at gmail.com Tue Mar 4 09:13:27 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Mar 2025 18:13:27 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> Message-ID: On Mon, Mar 3, 2025 at 6:01 PM Rob Gingell 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. From gingell at computer.org Tue Mar 4 10:02:45 2025 From: gingell at computer.org (Rob Gingell) Date: Mon, 3 Mar 2025 16:02:45 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> Message-ID: <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> 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! From luther.johnson at makerlisp.com Tue Mar 4 12:10:56 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Mon, 3 Mar 2025 19:10:56 -0700 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250302031646.GF13234@mcvoy.com> <41D3852D-865E-4DEF-B28A-D82A53D9FEC1@iitbombay.org> <20250302183905.ibxuwqyvj4pnrihy@illithid> <3034F84A-B1DA-4F59-A8BD-06749D20A959@serissa.com> <20250303182757.GR13234@mcvoy.com> Message-ID: 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 > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Mar 4 16:37:56 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 04 Mar 2025 06:37:56 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250303212047.920C718C09C@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon, 3 Mar 2025 16:20:47 -0500 (EST)") References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> Message-ID: <7w8qpljo6z.fsf@junk.nocrew.org> 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. From lars at nocrew.org Tue Mar 4 16:40:25 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 04 Mar 2025 06:40:25 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> (Rob Gingell's message of "Mon, 3 Mar 2025 14:51:06 -0800") References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> Message-ID: <7w4j09jo2u.fsf@junk.nocrew.org> > 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? From lars at nocrew.org Tue Mar 4 16:46:13 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 04 Mar 2025 06:46:13 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> (Rob Gingell's message of "Mon, 3 Mar 2025 16:02:45 -0800") References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> Message-ID: <7wzfi1i98q.fsf@junk.nocrew.org> 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. From tuhs at tuhs.org Wed Mar 5 01:07:04 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 4 Mar 2025 10:07:04 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> Message-ID: 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 at case.edu http://tiswww.cwru.edu/~chet/ From woods at robohack.ca Wed Mar 5 07:27:09 2025 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 04 Mar 2025 13:27:09 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <7w8qpljo6z.fsf@junk.nocrew.org> References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> Message-ID: At Tue, 04 Mar 2025 06:37:56 +0000, Lars Brinkhoff 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From gingell at computer.org Wed Mar 5 07:55:26 2025 From: gingell at computer.org (Rob Gingell) Date: Tue, 4 Mar 2025 13:55:26 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <7wzfi1i98q.fsf@junk.nocrew.org> References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> <7wzfi1i98q.fsf@junk.nocrew.org> Message-ID: <96a12f63-f74c-4248-8a31-ff8dc8fa77e9@computer.org> 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. From robpike at gmail.com Wed Mar 5 09:54:01 2025 From: robpike at gmail.com (Rob Pike) Date: Wed, 5 Mar 2025 10:54:01 +1100 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> Message-ID: 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 wrote: > At Tue, 04 Mar 2025 06:37:56 +0000, Lars Brinkhoff > 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 > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Mar 5 13:15:42 2025 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Mar 2025 19:15:42 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> Message-ID: <20250305031542.GC24601@mcvoy.com> 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. From woods at robohack.ca Wed Mar 5 13:52:41 2025 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 04 Mar 2025 19:52:41 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> Message-ID: At Wed, 5 Mar 2025 10:54:01 +1100, Rob Pike 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From cmhanson at eschatologist.net Wed Mar 5 16:01:53 2025 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 4 Mar 2025 22:01:53 -0800 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: <8549373B-99FC-4896-B369-1901690CD979@eschatologist.net> On Mar 1, 2025, at 1:51 PM, 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. 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 From jnc at mercury.lcs.mit.edu Wed Mar 5 16:23:20 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 5 Mar 2025 01:23:20 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> > 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 From tuhs at tuhs.org Wed Mar 5 18:38:14 2025 From: tuhs at tuhs.org (Konstantin Belousov via TUHS) Date: Wed, 5 Mar 2025 10:38:14 +0200 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250305031542.GC24601@mcvoy.com> References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> <20250305031542.GC24601@mcvoy.com> Message-ID: 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. From tuhs at tuhs.org Thu Mar 6 00:15:22 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 5 Mar 2025 09:15:22 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <96a12f63-f74c-4248-8a31-ff8dc8fa77e9@computer.org> References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> <7wzfi1i98q.fsf@junk.nocrew.org> <96a12f63-f74c-4248-8a31-ff8dc8fa77e9@computer.org> Message-ID: <58579e53-bb0f-4f0a-b9cb-67d22c711494@case.edu> 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 at case.edu http://tiswww.cwru.edu/~chet/ From henry.r.bent at gmail.com Thu Mar 6 00:26:14 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 5 Mar 2025 09:26:14 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <58579e53-bb0f-4f0a-b9cb-67d22c711494@case.edu> References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> <7wzfi1i98q.fsf@junk.nocrew.org> <96a12f63-f74c-4248-8a31-ff8dc8fa77e9@computer.org> <58579e53-bb0f-4f0a-b9cb-67d22c711494@case.edu> Message-ID: On Wed, 5 Mar 2025 at 09:15, Chet Ramey via TUHS 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Mar 6 00:29:46 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 5 Mar 2025 09:29:46 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: <6dc49d15-e771-444f-aa89-a7b1d07228b1@computer.org> <270ed8eb-8400-4e37-89a5-e5e7e3b5aa2d@computer.org> <7wzfi1i98q.fsf@junk.nocrew.org> <96a12f63-f74c-4248-8a31-ff8dc8fa77e9@computer.org> <58579e53-bb0f-4f0a-b9cb-67d22c711494@case.edu> Message-ID: <200122be-5db7-4b24-a19b-1f4e7a5e7b22@case.edu> 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 at case.edu http://tiswww.cwru.edu/~chet/ From emu at e-bbes.com Thu Mar 6 00:50:07 2025 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 5 Mar 2025 09:50:07 -0500 Subject: [TUHS] DCJ-11 processor with 20k FPGA In-Reply-To: References: Message-ID: <3da18b77-d02d-4916-b272-2d2c925eec2c@e-bbes.com> On 2025-03-01 07:11, Jason Stevens via TUHS wrote: > I assume people have seen this? > > https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main > > > It's capable of running Unix v1 & some limited amount of v6 among other > things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from > AliExpress. > > Kind of neat to combine a real processor with a simple FPGA implementation > of the hardware. I just had a look at it, but he doesn't show the code, which runs on the TangNano? From chopps at chopps.org Thu Mar 6 01:30:54 2025 From: chopps at chopps.org (Christian Hopps) Date: Wed, 05 Mar 2025 10:30:54 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: (Konstantin Belousov via TUHS's message of "Wed, 5 Mar 2025 10:38:14 +0200") References: <20250303212047.920C718C09C@mercury.lcs.mit.edu> <7w8qpljo6z.fsf@junk.nocrew.org> <20250305031542.GC24601@mcvoy.com> Message-ID: Konstantin Belousov via TUHS 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. From jnc at mercury.lcs.mit.edu Thu Mar 6 02:14:49 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 5 Mar 2025 11:14:49 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: <20250305161449.2BD1B18C0A6@mercury.lcs.mit.edu> > 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 From tuhs at tuhs.org Thu Mar 6 04:54:52 2025 From: tuhs at tuhs.org (Jason Stevens via TUHS) Date: Wed, 5 Mar 2025 18:54:52 -0000 Subject: [TUHS] DCJ-11 processor with 20k FPGA Message-ID: the code in the repo is for the FPGA, the processor that is strapped to the FPGA well it runs the real code. It's like the 'minimig' Amiga emulator platform, a real processor, and FPGA to do all the IO heavy lifting. So it's not 100% FPGA but you are executing code on a real processor so you aren't exactly full emulation either. And it doesn't cost a fortune, assuming you can find one of these ancient microprocessors. -----Original Message----- From: emanuel stiebler To: Jason Stevens; 'tuhs at tuhs.org' Sent: 3/5/25 2:50 PM Subject: Re: [TUHS] DCJ-11 processor with 20k FPGA On 2025-03-01 07:11, Jason Stevens via TUHS wrote: > I assume people have seen this? > > https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main > > > It's capable of running Unix v1 & some limited amount of v6 among other > things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from > AliExpress. > > Kind of neat to combine a real processor with a simple FPGA implementation > of the hardware. I just had a look at it, but he doesn't show the code, which runs on the TangNano? From tuhs at tuhs.org Thu Mar 6 05:45:26 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 05 Mar 2025 19:45:26 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250305161449.2BD1B18C0A6@mercury.lcs.mit.edu> References: <20250305161449.2BD1B18C0A6@mercury.lcs.mit.edu> Message-ID: On Wednesday, March 5th, 2025 at 8:14 AM, jnc at mercury.lcs.mit.edu wrote: > > From: Rob Pike > > > > The notion that the struct layout must correspond to the hardware > > > device's layout is about as non-portable as thinking can get. > > > I'm confused; I thought device register layout is inherently about as > non-portable a thing as one could have, generally. > > (Exceptions: 1) the device is basically a single chip, so interfaces on two > machines might be essentially identical, if they use the same chip; 2) someone > made a 68K card that plugged into a QBUS, so drivers on a PDP-11 and that 68K > could be identical.) > > Or did you mean that one could somehow disassociate the struct layout and the > details of the device (assuming it has addressable registers, as became > common)? How (I'm missing it)? > > Noel I got thinking about this more after seeing Rob's reply, it does make sense the more I ponder on it now. While it'd be nice to hand that info to the language and have compilation handle all the details, given that endianness is already an issue, it's a steep order to expect any of the other details of mapping onto a set of registers to actually be easily facilitated. Basically unless the struct can perfectly capture *everything*, in other words, operand size, bit ordering, volatility, padding, and so on, the fact that any assumptions may be made at all precludes trusting a struct to be the means for describing a hardware interface. As much as it may pain one (such as myself...) to put in all the serialization logic for data, expecting any old C compiler to be built with that in mind when it isn't a requirement for the language may be a fool's errand. It is nice when it works out that way on a specific machine and your code need not be portable though. Basically it's a happy accident when it does work, but not an indictment of the language when it doesn't. Plus while C may have grown up with the PDP-11 UNIX kernel, it grew wings and soared in userland applications, of which interacting with hardware I/O registers isn't really an expected application. IBM tried the divorce of user and system code with the PL/I vs PL/S exercise, and one only need take a look around to see what impact that materially had on the longevity of the languages. This sort of discussion really makes me appreciate this list, these are perspectives I don't often find elsewhere outside of footnotes in places I wouldn't know to search for. - Matt G. From phil at ultimate.com Thu Mar 6 06:39:14 2025 From: phil at ultimate.com (Phil Budne) Date: Wed, 05 Mar 2025 15:39:14 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> Message-ID: <202503052039.525KdEoB093322@ultimate.com> 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... From johnl at taugh.com Thu Mar 6 14:03:44 2025 From: johnl at taugh.com (John Levine) Date: 5 Mar 2025 23:03:44 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <202503052039.525KdEoB093322@ultimate.com> References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> <202503052039.525KdEoB093322@ultimate.com> Message-ID: <20250306040344.BE5FFBED180B@ary.qy> It appears that Phil Budne 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 From crossd at gmail.com Thu Mar 6 14:35:07 2025 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Mar 2025 23:35:07 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250306040344.BE5FFBED180B@ary.qy> References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> <202503052039.525KdEoB093322@ultimate.com> <20250306040344.BE5FFBED180B@ary.qy> Message-ID: On Wed, Mar 5, 2025 at 11:11 PM John Levine 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 From johnl at taugh.com Thu Mar 6 15:28:42 2025 From: johnl at taugh.com (John Levine) Date: 6 Mar 2025 00:28:42 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: References: Message-ID: 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 at taugh.com > On Mar 5, 2025, at 23:36, Dan Cross wrote: > > On Wed, Mar 5, 2025 at 11:11 PM John Levine 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 > From lars at nocrew.org Thu Mar 6 16:23:06 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 06 Mar 2025 06:23:06 +0000 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: (Dan Cross's message of "Wed, 5 Mar 2025 23:35:07 -0500") References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> <202503052039.525KdEoB093322@ultimate.com> <20250306040344.BE5FFBED180B@ary.qy> Message-ID: <7weczaisol.fsf@junk.nocrew.org> 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. From emu at e-bbes.com Thu Mar 6 20:50:36 2025 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 6 Mar 2025 05:50:36 -0500 Subject: [TUHS] DCJ-11 processor with 20k FPGA In-Reply-To: References: Message-ID: <6c49ba81-94da-4207-997d-c2e3d5fe7812@e-bbes.com> On 2025-03-05 13:54, Jason Stevens wrote: > the code in the repo is for the FPGA, the processor that is strapped to the > FPGA well it runs the real code. > > It's like the 'minimig' Amiga emulator platform, a real processor, and FPGA > to do all the IO heavy lifting. > > So it's not 100% FPGA but you are executing code on a real processor so you > aren't exactly full emulation either. And it doesn't cost a fortune, > assuming you can find one of these ancient microprocessors. You are right, I just found it. Didn't expect the HDL code in the "applications" folder ... From jnc at mercury.lcs.mit.edu Thu Mar 6 21:42:18 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 6 Mar 2025 06:42:18 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: <20250306114218.90F8D18C086@mercury.lcs.mit.edu> > 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 From jnc at mercury.lcs.mit.edu Thu Mar 6 21:47:36 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 6 Mar 2025 06:47:36 -0500 (EST) Subject: [TUHS] Any UNIX With No C In Userland? Message-ID: <20250306114736.0A79418C086@mercury.lcs.mit.edu> > 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 From clemc at ccc.com Fri Mar 7 03:09:54 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 6 Mar 2025 12:09:54 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <20250306040344.BE5FFBED180B@ary.qy> References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> <202503052039.525KdEoB093322@ultimate.com> <20250306040344.BE5FFBED180B@ary.qy> Message-ID: On Wed, Mar 5, 2025 at 11:03 PM 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 > 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. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Mar 7 05:47:43 2025 From: crossd at gmail.com (Dan Cross) Date: Thu, 6 Mar 2025 14:47:43 -0500 Subject: [TUHS] Any UNIX With No C In Userland? In-Reply-To: <7weczaisol.fsf@junk.nocrew.org> References: <20250305062320.D6F3A18C0A4@mercury.lcs.mit.edu> <202503052039.525KdEoB093322@ultimate.com> <20250306040344.BE5FFBED180B@ary.qy> <7weczaisol.fsf@junk.nocrew.org> Message-ID: On Thu, Mar 6, 2025 at 1:23 AM Lars Brinkhoff 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.