TUHS November 2024

tuhs@tuhs.org

24 participants
12 discussions

by Paul Ruizendaal

In the last months, I've spent a little time on curating John Walker's Unix clone and software stack, including an emulator to run it: https://gitlab.com/marinchip After creating a basic tool chain (edit, asm, link and a simple executive), John set out to find a compiler. Among the first programs were a port of the META 3 compiler-generator (similar to TMG on early Unix) and a port of Birch-Hansen’s Pascal compiler. META was used to create a compiler that generated threaded code. He found neither compiler good enough for his goals and settled on writing his Unix-like OS in assembler. As the 9900 architecture withered after 1980, this sealed the fate of this OS early on -- had he found a good compiler, the code might have competed alongside Coherent, Idris, and Minix during the 80’s. This made me realise once more how unique the Ritchie C compiler was. In my view its uniqueness combines three aspects: 1. The C language itself 2. The ability to run natively on small hardware (even an LSI-11 system) 3. Generating code with modest overhead versus handwritten assembler (say 30%) As has been observed before, working at a higher abstraction level makes it easier to work on algorithms and on refactoring, often earning back the efficiency loss. John Walkers work may be case in point: I estimate that his hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compiled for the 9900 architecture). There are three papers on DMR’s website about the history of the compiler and a compare-and-contrast with other compilers of the era: https://www.bell-labs.com/usr/dmr/www/primevalC.html https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/hopl.html It seems to me that these papers rather understate the importance of generating good quality code. As far as I can tell, BCPL and BLISS came close, but were too large to run on a PDP-11 and only existed as cross-compilers. PL/M was a cross-compiler and generated poorer code. Pascal on small machines compiled to a virtual machine. As far as I can tell, during most of the 70s there was no other compiler that generated good quality code and ran natively on a small (i.e. PDP-11 class) machine. As far as I can tell the uniqueness was mostly in the “c1” phase of the compiler. The front-end code of the “c0” phase seems to use more or less similar techniques as many contemporary compilers. The “c1” phase seems to have been unique in that it managed to do register allocation and instruction selection with a pattern matcher and associated code tables squeezed into a small address space. On a small machine, other native compilers of the era typically proceeded to generate threaded code, code for a virtual machine or poor quality native code that evaluated expressions using stack operations rather than registers. I am not sure why DMR's approach was not more widely used in the 1970’s. The algorithms he used do not seem to be new and appear to have their roots in other (larger) compilers of the 1960’s. The basic design seems to have been in place from the very first iterations of his compiler in 1972 (see V2 tree on TUHS) and he does not mention these algorithms as being special or innovative in his later papers. Any observations / opinions on why DMR’s approach was not more widely used in the 1970’s?

3 weeks, 3 days

Re: v6 Unix Documents

by Jonathan Gray

On Sun, Oct 20, 2024 at 01:23:23AM -0400, Dan Plassche wrote: > > On Sat, 19 Oct 2024, Jonathan Gray wrote: > > > PWB was an early external distribution with troff. > > > > Documents for the PWB/UNIX Time-Sharing System > > https://datamuseum.dk/wiki/Bits:30007124 > > https://bitsavers.org/pdf/att/unix/PWB_UNIX/ > > > > NROFF/TROFF User's Manual > > October 11, 1976 > > datamuseum.dk, pp 325-357 > > bitsavers, pp 217-249 > > > > Addendum to the NROFF/TROFF User's Manual > > May 1977 > > datamuseum.dk, p 358 > > bitsavers, p 250 > > > > fonts described in: > > Administrative Advice for PWB/UNIX > > 23. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES > > datamuseum.dk, p 647 > > Thank you Jonathan. I was previously not sure where to place the > PWB documentation in the timeline but a clearer picture is > emerging. > > Based on the v6 "NROFF User's Manual" revised in 1974 and > published in 1975, I can now see that the PWB documentation with > the "NROFF/TROFF User's Manual" from 1976-77 has most of the > content that later appears in v7. The major change immediately > beforehand was the rewrite of troff into C.[1] Some clear > differences are the combination of nroff and troff manpages and > the addition of troff specific features like the special fonts > into the user's manual. > > [1]. Apparently in 1976: > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-tr… "It was rewritten in C around 1975" Kernighan in CSTR 97, A Typesetter-independent TROFF I've seen references to "Documents for Use with the Phototypesetter (Version 7)" which was likely distributed with the licensed phototypesetter tape in 1977. What may have been the manual distributed with that tape is also close to v7. https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/troff/doc https://www.tuhs.org/Archive/Distributions/Other/Interdata/ tuhs Applications/Spencer_Tapes/unsw3.tar.gz usr/source/formatters/troff/doc/

1 month, 3 weeks

Re: Canonical Historic Approach to iconv(1)

by Rudi Blom

The "man 1 iconv" page on both HP-UX 11i 11.23 (Aug 2003) and 11.31 (Feb 2007) remark that iconv was developed by HP. Cheers, uncle rubl -- The more I learn the better I understand I know nothing.

1 month, 3 weeks

Canonical Historic Approach to iconv(1)

by segaloco

So a project I'm working on recently includes a need to store UTF-8 Japanese kana text in source files for readability, but then process those source files through tools only guaranteed to support single-byte code points, with something mapping the UTF-8 code points to single-byte points in the destination execution environment. After a bit of futzing, I've landed on the definition of iconv(1) provided by the Single UNIX Specification to push this character mapping concern to the tip of my pipelines. It is working well thus far and insulates the utilities down-pipe from needing multi-byte support (I'm looking at you Apple). I started thumbing through my old manuals and noted that iconv(1) is not a historic utility, rather, SUS picked it up from HP-UX along the way. Was there any older utility or set of practices for converting files between character encodings besides the ASCII/EBCDIC stuff in dd(1)? As I understand it, iconv(1) is just recognizing sequences of bytes, mapping them to a symbolic name, then emitting them in the complementary series of bytes assigned to that symbolic name in a second charmap file. This sounds like a simple filter operation that could be done in a few other ways. I'm curious if any particular approach was relatively ubiquitous, or if this was an exercise largely left to the individual and so solutions were wide and varied? My tool chain doesn't need to work on historic UNIX, but it would be cool to understand how to make it work on the least common denominator. - Matt G.

1 month, 3 weeks

Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons

by Douglas McIlroy

A worthy objective, but it should not be released without user documentation. Where can one see that? Doug

1 month, 4 weeks

Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Douglas McIlroy

>>> malloc(0) isn't undefined behaviour but implementation defined. >> >> In modern C there is no difference between those two concepts. > Can you explain more about your view There certainly is a difference, but in this case the practical implications are the same: avoid malloc(0). malloc(0) lies at the high end of a range of severity of concerns about implementation-definedness. At the low end are things like the size of ints, which only affects applications that may confront very large numbers. In the middle is the default signedness of chars, which generally may be mitigated by explicit type declarations. For the size of ints, C offers guardrails like INT_MAX. There is no test to discern what an error return from malloc(0) means. Is there any other C construct that implementation-definedness renders useless? Doug

1 month, 4 weeks

Looking for historical vi sources

by Anton Shepelev

Hello, all. Have you an idea where one could find the sources of the various versions of the ex/vi editor, besides those archived at TUHS: 1BSD/ex-1.1 2.11BSD/src/ucb/ex 2.9BSD/usr/src/ucb/ex/ex2 2.9BSD/usr/src/ucb/ex/ex3 2BSD/src/ex 3BSD/usr/src/cmd/ex 4.1cBSD/usr/src/ucb/ex 4.2BSD/usr/src/ucb/ex 4.3BSD-Reno/src/usr.bin/ex 4.3BSD-Tahoe/usr/src/ucb 4.3BSD-UWisc/src/ucb/ex 4.3BSD/usr/src/ucb/ex 4.4BSD/usr/src/usr.bin/ex 4BSD/usr/src/cmd/ex OpenSolaris_b135/cmd/vi There include vv. 1.1, 2.13, 3.2, 3.6, and many variants of 3.7. Has anything else been preserved to your knowledge?

2 months

RIP Darl McBride former CEO of SCO

by Will Senn

It happened in September, apparently, but is only now making the rounds. Darl McBride, known for taking everybody and his brother to court over stolen code, has passed away. https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-a… I actually remember liking SCO back in the day, before the company leadership went dark-side. These days, we get to play with ancient unix cuz of their license. What a topsy turvy world. Is there a concise summary of the SCO suits and fallout out there? I've seen a lot on the AT&T side of things, but other than having lived through it, I've not seen much on what eventually happened and why it all sort of just dissappeared. Will

2 months, 1 week

Fwd: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

---------- Forwarded message --------- From: Warner Losh <imp(a)bsdimp.com> Date: Fri, Nov 8, 2024 at 3:17 PM Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) To: David Barto <barto(a)kdbarto.org> On Fri, Nov 8, 2024 at 1:07 PM David Barto <barto(a)kdbarto.org> wrote: > > > On Nov 8, 2024, at 12:27 PM, Warner Losh <imp(a)bsdimp.com> wrote: > > > > On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > >> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: >> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: >> >> I keep wondering if this assertion of code difference or lack thereof >> can be tested. Are not all these sources available? Which bits are missing? >> > >> > Yes. Great question. >> > >> > https://people.freebsd.org/~imp/pmap/pmap.32v >> > https://people.freebsd.org/~imp/pmap/pmap.4.2 >> > https://people.freebsd.org/~imp/pmap/pmap.4.3 >> > https://people.freebsd.org/~imp/pmap/pmap.net.2 >> >> Hmm; these all 404 for me? > > > Doh! Too much muscle memory. Those should all be bmap: > > https://people.freebsd.org/~imp/bmap/bmap.32v > <https://people.freebsd.org/~imp/pmap/pmap.32v> > https://people.freebsd.org/~imp/bmap/bmap.4.2 > <https://people.freebsd.org/~imp/pmap/pmap.4.2> > https://people.freebsd.org/~imp/bmap/bmap.4.3 > <https://people.freebsd.org/~imp/pmap/pmap.4.3> > https://people.freebsd.org/~imp/bmap/bmap.net.2 > <https://people.freebsd.org/~imp/pmap/pmap.net.2> > > https://people.freebsd.org/~imp/bmap/bmap.32v https://people.freebsd.org/~imp/bmap/bmap.4.2 https://people.freebsd.org/~imp/bmap/bmap.4.3 https://people.freebsd.org/~imp/bmap/bmap.net.2 Not sure why the previous... Warner

2 months, 2 weeks

Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: > > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: > >> I keep wondering if this assertion of code difference or lack thereof > can be tested. Are not all these sources available? Which bits are missing? > > > > Yes. Great question. > > > > https://people.freebsd.org/~imp/pmap/pmap.32v > > https://people.freebsd.org/~imp/pmap/pmap.4.2 > > https://people.freebsd.org/~imp/pmap/pmap.4.3 > > https://people.freebsd.org/~imp/pmap/pmap.net.2 > > Hmm; these all 404 for me? Doh! Too much muscle memory. Those should all be bmap: https://people.freebsd.org/~imp/bmap/bmap.32v <https://people.freebsd.org/~imp/pmap/pmap.32v> https://people.freebsd.org/~imp/bmap/bmap.4.2 <https://people.freebsd.org/~imp/pmap/pmap.4.2> https://people.freebsd.org/~imp/bmap/bmap.4.3 <https://people.freebsd.org/~imp/pmap/pmap.4.3> https://people.freebsd.org/~imp/bmap/bmap.net.2 <https://people.freebsd.org/~imp/pmap/pmap.net.2> which shows the progression before the rewrite in 4.4BSD-lite. Warner

2 months, 2 weeks

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS November 2024