TUHS June 2024

tuhs@tuhs.org

82 participants
40 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?

1 month, 1 week

Sad but not unexpected news about the LCM-L

by Clem Cole

https://www.geekwire.com/2024/seattles-living-computers-museum-logs-off-for… These folks hosted the UNIX 50th Celebration and had a physical PDP-7 that was used to bring up UNIX V0 (after first getting it running on SIMH). That later was not easy because the original PDP-7s (like the one Ken had access to) did not have disk storage. BTL had paid DEC's Custom Special Systems (CSS) to splice a Burrough's disk that DEC was selling using for the 15 and later the PDP-9. It started with splicing reverse engineering that code to build a simulation of that disk into the simh, so we could ensure that UNIX ran—finally, modeling that HW with a custom microprocessor-based board with an SD card with a functional replica of a PDP-7 I/O interface on one side obeying the device registers and operations that UNIX expected to see. The LCM-L folks were incredibly gracious and generous. I am so sad to see their collection go away. In particular, I hope the PDP-7s and the CDC-6500 find new homes. Clem

7 months, 2 weeks

most direct Unix descendant

by Andrew Lynch

Hi Out of curiosity, what would be considered the most direct descendent of Unix available today? Yes, there are many descendants, but they've all gone down their own evolutionary paths. Is it FreeBSD or NetBSD? Something else? I don't think it would be Minix or Linux because I remember when they came along, and it was well after various Unix versions were around. Does such a thing even exist anymore? I remember using AT&T Unix System V and various BSD variants back in college in the 1980's. System V was the "new thing" back then but was eventually sold and seems to have faded. Maybe it is only available commercially, but it does not seem as prominent as it once was. Any thoughts? Thanks, Andrew Lynch

7 months, 2 weeks

Re: On the term "justification"

by Douglas McIlroy

Oops, my last post ascribed Runoff to the 15th century, "sixty decades" ago. Doug

7 months, 2 weeks

Re: Documenting a set of functions with -man

by Douglas McIlroy

> The lack of a monospaced font is, I suspect, due either to > physical limitations of the C/A/T phototypesetter[1] or fiscal > limitations--no budget in that department to buy photographic > plates for Courier. Since the C/A/T held only four fonts, there was no room for Courier. But when we moved beyond that typesetter, inertia kept the old ways . Finally, in v9, I introduced the fixed-width "literal font", L, in -man and said goodbye to boldface in synopses. By then, though, Research Unix was merely a local branch of the Unix evolutionary tree, so the literal-font gene never spread. Doug

7 months, 2 weeks

The thread about standards is now closed

by Warren Toomey

All, I've decided to bring the ANSI C/POSIX thread to a close. While initially the thread was informative, it's recently become host to comments which are inappropriate and certainly well out of scope for a mailing list about UNIX and its history. If someone wants to resurrect a thread about standards, feel free to use the COFF list. But please, keep the conversation on-topic. Thanks, Warren

7 months, 2 weeks

another OSX 100% less Unix

by ron minnich

I have a directory, t: ronsexcllentmbp:t rminnich$ ls -li total 0 23801442 -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a 23801443 -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b 23801443 -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c note that b and c are the same inode. let's make a cpio. ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio a b c ^D 1 block what's in it? ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c link to b "c link to b"? wtf? Who thought that was a good idea? because ... ronsexcllentmbp:t rminnich$ touch 'c link to b' ronsexcllentmbp:t rminnich$ ls -l total 0 -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:22 c link to b and ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio a b c c link to b ^D ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c link to b -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:22 c link to b so ... it looks like a file is there twice, because somebody thought it was a good idea to confuse a file name and file metadata. And, anyway, it's just as accurate to have it say -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b link to c -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c link to b -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:22 c link to b Right? :-) From the same people who brought you this: ronsexcllentmbp:t rminnich$ bc >>> Somebody needs to get the osx folks a unix manual set :-)

7 months, 2 weeks

Re: Sad but not unexpected news about the LCM-L

by jnc＠mercury.lcs.mit.edu

> From: Aron <aki(a)insinga.com> > Now if only his family would take those wishes of his into account and > tell the lawyers to finish the job. I suspect that was his real mistake; he trusted that his family would do what he wanted (perhaps so that instead of putting the final bow on this, he could pay attention to something else that was more important to him) after he was gone - and they decided not to. My suspicion is that there is something else that is more important to his sister (probably political), and she decided that the pittance she'd get from flushing the LCM would be better put towards her project(s). I've just been re-reading Thucydides' extraordinarily outstanding meditation on the revolution on Corcyra (which is really a meditation on the death of the Greek polei - and is a pre-epitaph on the death of many democracies since), and if my pupposition is correct, it applies to this too I wonder what'll happen to all the less-valuable stuff that was given to the LCM? A PDP-10 will fetch 10K's of $, but a lot of the rest is worth pennies. I hope they don't scrap it for pennies, or throw it in the trash. I'm sure that someone who would ignore her brother's wishes about important pieces of history that meant a lot to him would have no qualms about doing either. Noel

7 months, 2 weeks

ANSI (C) vs IEEE (POSIX) Standards Body Selection

by segaloco

Good morning, I was wondering if anyone has the scoop on the rationale behind the selection of standards bodies for the publication of UNIX and UNIX-adjacent standards. C was published via the ANSI route as X3.159, whereas POSIX was instead published by the IEEE route as 1003.1. Was there every any consideration of C through IEEE or POSIX through ANSI instead? Is there an appreciable difference suggested by the difference in publishers? In any case, both saw subsequent adoption by ISO/IEC, so the track to an international standard seems to lead to the same organizations. - Matt G.

7 months, 2 weeks

ACM Software System Award to Andrew S. Tanenbaum for MINIX

by Nelson H. F. Beebe

This announcement just arrived on the ACM Bulletins list: >> ... >> Andrew S. Tanenbaum, Vrije Universiteit, receives the ACM Software >> System Award (http://awards.acm.org/software-system) for MINIX, which >> influenced the teaching of Operating Systems principles to multiple >> generations of students and contributed to the design of widely used >> operating systems, including Linux. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 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 June 2024