TUHS

tuhs@tuhs.org

61 participants
6532 discussions

Re: [TUHS] Comments in early Unix systems

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> > there is next to no commenting in the early code bases. By 'early' you must mean the first 'C' PDP-11 Unixes, because certainly starting with V6, it is reasonably well commented (to the point where I like to say that I learned how to comment by reading the V6 code), e.g.: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/slp.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/dmr/bio.c to pick examples from each author; and there are _some_ comments in the assembler systems (both PDP-7 and PDP-11). > Given that the comments never made it into the compiled code, there was > no space reason to omit comments. There must have been another reason. I was going to say 'the early disks were really small', but that hypothesis fails because the very earliest versions (in assembler) do have some comments. Although assembler is often so cryptic, the habit of putting a comment on each instruction isn't so unreasonable. So maybe the sort of comments one sees in assembler code (line-by-line descriptions of what's happening; for subroutines, which arguments are in which registers; etc) aren't needed in C code, and it took a while for them to work out what sort of commenting _was_ appropriate/useful for C code? The sudden appearance in V6 does make it seem as if there was a deliberate decision to comment the code, and they went through it and added them in a deliberate campaign. > From: Andy Kosela <akosela(a)andykosela.com> > "Practice of Programming" by Rob Pike and Brian Kernighan. > ... > They also state: "Comments ... do not help by saying things the code > already plainly says ... The best comments aid ... by briefly pointing > out salient details or by providing a larger-scale view of the > proceedings." Exactly. Noel

7 years, 3 months

Happy 25th Birthday NetBSD!

by Jeremy C. Reed

Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.c?rev=1.1&content-ty… Today is commonly considered the birthday of NetBSD. Theo told me (seven years ago) that he, cgd, and glass (and one other person) planned it within 30 minutes after discussing with the CSRG and BSDI guys in the hot tub at the Town & Country Resort in San Diego at the January 25-29 1993 USENIX conference. (Does anyone have more to share about this discussion?) Soon, cgd had setup a CVS repository (forked 386BSD with many patchkits) which was re-rolled a few times (due to corrupted CVS). (So maybe March 21 is later than the real birthday.) As far as I know, it is the oldest continuously-maintained complete open source operating system. (It predates Slackware Linux, FreeBSD, and Debian Linux by some months.) "NetBSD" wasn't mentioned by name in the April 19. 1993 release files (but was named in the announcement). ftp://ftp.netbsd.org/pub/NetBSD/misc/release/NetBSD/NetBSD-0.8 On April 28, the kernel was renamed to /netbsd, the boot loader identified it as NetBSD, and various references of 386BSD were changed to NetBSD. https://github.com/NetBSD/src/commit/a477732ff85d5557eef2808b5cbf221f3c7455… https://github.com/NetBSD/src/commit/446115f2d63299e52f34977fb4a88c289dcae9…

7 years, 3 months

Re: [TUHS] FORTRAN

by Johnny Billquist

On 2018-03-21 14:48, Paul Winalski<paul.winalski(a)gmail.com> wrote: > > On 3/20/18, Clem Cole<clemc(a)ccc.com> wrote: >> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS >> originally - IIRC the one I used came from the universities. I think the >> first Pascal sold was targeted for the VAX. Also, RT11 and RSX were >> 'laboratory' systems and those systems were dominated by Fortran back in >> the day - so DEC marketing thought in those terms. >> > DEC did do a Pascal for RSX. I don't remember if it supported RT11 or > RSTS. DEC did a BASIC compiler for RSTS and RSX. RSX and especially > RT were designed mainly for real-time process control in laboratories. DEC did both COBOL, DIBOL, PASCAL, FORTRAN (-IV, -IV-PLUS, -77), C as well as Datatrieve for RSX and RSTS/E. Some of these were also available for RT-11. Admittedly, the C compiler was very late to the game. > A lot of the programming was in assembler for efficiency reasons > (both time and space). Yes. And MACRO-11 is pretty nice. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 3 months

Happy birthday, PDP-8!

by Dave Horsfall

Let's see how much this thread can drift... The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on the wrong side of the date line). It was the first computer I ever used, back around 1970 (I think I'd just left school and was checking out the local University's computer department, and played with BASIC and FOCAL). And (hopefully) coincidentally the Pentium first shipped in 1993; the infamous FDIV defect was discovered a year later (and it turned out that Intel was made aware of it by a post-grad student a bit earlier), and what followed next was an utter farce, with some dealers refusing to accept the results of a widely-distributed program as evidence of a faulty FPU. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 3 months

Re: [TUHS] FORTRAN

by jnc＠mercury.lcs.mit.edu

> From: "Steve Johnson" So, I have this persistent memory that I read, in some early Multics (possibly CTSS, but ISTR it was Multics) document, a footnote explaining the origin of the term 'daemon'. I went looking for it, but couldn't find it in a 'quick' scan. I did find this, though, which is of some interest: R. A. Freiburghouse, "The Multics PL/1 Compiler" (available online here: http://multicians.org/pl1-raf.html if anyone is interested). > There was a group that was pushing the adoption of PL/1, being used to > code Multics, but the compiler was late and not very good and it never > really caught on. So, in that I read: The entire compiler and the Multics operating system were written in EPL, a large subset of PL/1 ... The EPL compiler was built by a team headed by M. D. McIlroy and R. Morris ... Several members of the Multics PL/1 project modified the original EPL compiler to improve its object code performance, and utilized the knowledge acquired from this experience in the design of the Multics PL/1 compiler. The EPL compiler was written when the _original_ PL/1 compiler (supposedly being produced by a consulting company, Digitek) blew up. More detail is available here: http://multicians.org/pl1.html I assume it's the Digitek compiler you were thinking of above? Noel

7 years, 3 months

RIP John Backus

by Dave Horsfall

We lost computer pioneer John Backus on this day in 2007; amongst other things he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because FORTRAN has no syntax to speak of. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 3 months

Timelines of 15, 596 documented Unix facilities from 1970 until today

by Diomidis Spinellis

I've put online at https://dspinellis.github.io/unix-history-man/ nine timelines detailing the evolution of 15,596 unique documented facilities (commands, system calls, library functions, device drivers, etc.) across 93 major Unix releases tracked by the Unix history repository. For each facility you get a timeline starting from the release it first appeared. Clicking on the timeline opens up the manual page for the corresponding release. (Sadly, the formatting is often messed up, because more work is needed on the JavaScript troff renderer I'm using.) The associated scripts and the raw data are all available on GitHub. Diomidis

7 years, 3 months

mt Xinu Unix manuals

by Deborah Scherrer

A while ago someone was asking about the mt Xinu Unix manuals. I have a found a complete set, currently owned by Vance Vaughan, one of the mt Xinu founders. He is willing to donate them to Warren's Unix archive. However, they are too expensive to ship to Australia. Would anyone be willing to scan them in for the archive? Ah, there are a lot of them (8? volumes). If so, I might be able to ship them to somewhere in the US. Let me know. Thanks. Deborah

7 years, 3 months

Re: [TUHS] daemons are not to be exorcised

by Nelson H. F. Beebe

Peter Guthrie Tait (1831--1901) seems to have recorded the oldest mention of the thermodynamic demon of James {Clerk Maxwell} in the page 213 image from Tait's book ``Sketch of Thermodynamics'' at https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up that was posted to this list by Bakul Shah <bakul(a)bitblocks.com> on Tue, 20 Mar 2018 12:10:37 -0700. I've been working on a bibliography (still unreleased) of Clerk Maxwell, and the oldest reference that I had so far found to Maxwell's demon is from an address by Sir William Thomson (later raised to Lord Kelvin) entitled The sorting demon of Maxwell: [Abstract of a Friday evening Lecture before the Royal Institution of Great Britain, February 28, 1879] Proceedings of the Royal Institution of Great Britain 9, 113--114 (1882) However, I've not been able to find that volume online. Hathi Trust has only volumes 30--71, with numerous holes, and often, it will not show page contents at all. The journal issue is old enough that few university libraries are likely to have it, but it is probably available through the Interlibrary Loan service. I had also recorded Harold Whiting Maxwell's demons Science (new series) 6(130), 83, July 1885 https://doi.org/10.1126/science.ns-6.130.83 and W. Ehrenberg Maxwell's demon Scientific American 217(5) 103--110, November 1967 https://doi.org/10.1038/scientificamerican1167-103 plus numerous later papers and books. I also went through a score of books on my shelf about physics or thermodynamics, and finally found a brief mention of Maxwell's demon in G. N. Lewis & M. Randall's famous text ``Thermodynamics'', first published in 1923 (I have a 1961 reprint). The other books that I checked remain strangely silent on that topic. The Oxford English Dictionary (OED) online has this definition and etymology: >> ... >> Maxwell's demon n. (also Maxwell demon) an entity imagined by Maxwell >> as allowing only fast-moving molecules to pass through a hole in one >> direction and only slow-moving ones in the other direction, so that if >> the hole is in a partition dividing a gas-filled vessel, one side >> becomes warmer and the other cooler, in contradiction of the second >> law of thermodynamics. >> >> 1879 W. Thomson in Proc. Royal Inst. 9 113 Clerk Maxwell's `demon' is >> a creature of imagination.., invented to help us to understand the >> `Dissipation of Energy' in nature. >> >> 1885 Science 31 July 83/1 (heading) Maxwell's demons. >> >> 1956 E. H. Hutten Lang. Mod. Physics iv. 152 It would require a >> Maxwell demon..to select the rapidly moving molecules according to >> their velocity and concentrate them in one corner of the vessel. >> >> 1971 Sci. Amer. Sept. 182/2 Maxwell's demon became an intellectual >> thorn in the side of thermodynamicists for almost a century. The >> challenge to the second law of thermodynamics was this: Is the >> principle of the increase of entropy in all spontaneous processes >> invalid where intelligence intervenes? >> >> 1988 Nature 27 Oct. 779/2 Questions about the energy needed in >> measurement began with Maxwell's demon. >> ... For the word `daemon', the OED has this: >> ... >> Etymology: Probably an extended use of demon .... >> >> A program (or part of a program), esp. within a Unix system, which >> runs in the background without intervention by the user, either >> continuously or only when automatically activated by a particular >> event or condition. A distinction is sometimes made between the form >> daemon, referring to a program on an operating system, and demon, >> referring to a portion of a program, but the forms seem generally to >> be used interchangeably, daemon being more usual. >> >> 1971 A. Bhushan Request for Comments (Network Working Group) >> (Electronic text) No. 114. 2 The cooperating processes may be >> `daemon' processes which `listen' to agreed-upon sockets, and >> follow the initial connection protocol. >> >> 1983 E. S. Raymond Hacker's Dict. 53 The printer daemon is just a >> program that is always running; it checks the special directory >> periodically, and whenever it finds a file there it prints it >> and then deletes it. >> >> 1989 DesignCenter ii. 41/3 The file server runs a standard set of >> HP-UX system and network daemons. >> >> 1992 New Scientist 18 Jan. 35/2 These programs, which could recognise >> simple patterns, were made up of several independent >> information-processing units, or `demons', and a `master >> demon'. >> >> 2002 N.Y. Times 7 Mar. d4/5 A mailer daemon installed on an e-mail >> system can respond to a piece of incorrectly addressed e-mail >> by generating an automated message to the sender that the >> message was undeliverable. >> ... ---------------------------------------- >From The Hacker's Dictionary (1983), reproduced in the Emacs info node Jargon, I find another `explanation' of daemon: >> ... >> :daemon: /day'mn/ or /dee'mn/ /n./ [from the mythological >> meaning, later rationalized as the acronym `Disk And Execution >> MONitor'] A program that is not invoked explicitly, but lies >> dormant waiting for some condition(s) to occur. The idea is that >> the perpetrator of the condition need not be aware that a daemon is >> lurking (though often a program will commit an action only because >> it knows that it will implicitly invoke a daemon). For example, >> under {{ITS}} writing a file on the {LPT} spooler's directory >> would invoke the spooling daemon, which would then print the file. >> The advantage is that programs wanting (in this example) files >> printed need neither compete for access to nor understand any >> idiosyncrasies of the {LPT}. They simply enter their implicit >> requests and let the daemon decide what to do with them. Daemons >> are usually spawned automatically by the system, and may either >> live forever or be regenerated at intervals. >> >> Daemon and {demon} are often used interchangeably, but seem to >> have distinct connotations. The term `daemon' was introduced to >> computing by {CTSS} people (who pronounced it /dee'mon/) and >> used it to refer to what ITS called a {dragon}. Although the >> meaning and the pronunciation have drifted, we think this glossary >> reflects current (1996) usage. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - 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 years, 3 months

Re: [TUHS] PDP-11 DIV instruction lossage

by jnc＠mercury.lcs.mit.edu

> I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix > it for real, instead of my kludgy fix (which extended it to work for > 16-bit results). :-) > ... > And on the -11/23: > Note that the returned 'quotient' is simply the high part of the dividend. Heh. I had decided that the easiest clean and long-lived fix was to just to do it right, using the long division routine used in the V7 C compiler runtime: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/crt/ldiv.s and I vaguely recalled reading a DMR story that talked about that, so just for amusement I decided to re-read it, and looked it up: https://www.bell-labs.com/usr/dmr/www/odd.html (the section "Comments I do feel guilty about"), and it's lucky I did, because I found this: Addendum 18 Oct 1998 Amos Shapir of nSOF (and of long memory!) just blackened (or widened) the spot a bit more in a mail message, to wit: 'I gather the "almost" here is because this trick almost worked... It has a nasty bug which I had to find the hard way! The "clever part" relies on the fact that if the "bvc 1f" is not taken, it means that the result could not fit in 16 bits; in that case the long value in r0,r1 is left unchanged. The bug is that this behavior is not documented; in later models (I found this on an 11/34) when the result does fit in 16 bits but not in 15 bits ... which makes this routine provide very strange results!' So this code won't work on an 11/23 either (which bashes the low register of the pair; above). I'd have been groveling in buggy math, again... Caveat Haquur (if you're trying to run stock V7 on a /23 or /34)! Noel

7 years, 3 months

Jump to page:

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