TUHS March 2018

tuhs@tuhs.org

72 participants
50 discussions

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."

6 years, 9 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

6 years, 9 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."

6 years, 9 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

6 years, 9 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

6 years, 9 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/ - -------------------------------------------------------------------------------

6 years, 9 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

6 years, 9 months

PDP-11 DIV instruction lossage

by jnc＠mercury.lcs.mit.edu

So, I have discovered, to my astonishment, that the double-word version of the DIV instruction on the PDP-11 won't do a divide if the result won't fit into 15 bits. OK, I can understand it bitching if the quotient wouldn't fit into 16 bits - but what's the problem with returning an unsigned quotient? And, just for grins, the results left in the registers which hold the quotient and remainer is different in the -11/23 (KDF11-A) and the -11/73 (KDJ11-A). (Although, to be fair, the PDP-11 Architecture Manual says 'register contents are unpredictable if there's an overflow'.) Oh well, guess I'll have to redo my kludgy fix to gmtime() (the distributed version of which in V6 qhas a problem when the number of 8-hour periods since the epoch overflows 15 bits)! I guess I'll have to fix it for real, instead of my kludgy fix (which extended it to work for 16-bit results). :-) I discovered this when I plugged in an -11/73 to make sure the prototype QSIC (our RK11/etc emulator for the QBUS) worked with the -11/73 as well as the -11/23 (which is what we'd mostly been using - when we first started working on the DMA and interrupts, we did try them both). I noticed that with the -11/73, the date printed incorrectly: Sun Mar 10 93:71:92 EST 1991 After a certain amount of poking and prodding, I discovered the issue - and on further reading, discovered the limitation to 15-bit results. For those who are interested in the details, here's a little test program that displays the problem: r = ldiv(a, b, d); m = ldivr; printf("a: 0%o %d. b: 0%o %d. d: 0%o %d.\n", a, a, b, b, d, d); printf("q: 0%o %d. r: 0%o %d.\n", r, r, m, m); and, for those who don't have V6 source at hand, here's ldiv(): mov 2(sp),r0 mov 4(sp),r1 div 6(sp),r0 mov r1,_ldivr rts pc So here are the results, first from a simulator: tld 055256 0145510 070200 a: 055256 23214. b: 0145510 -13496. d: 070200 28800. q: 0147132 -12710. r: 037110 15944. This is _mathematically_ correct: 055256,0145510 = 1521404744., 070200 = 28800., and 1521404744./28800. = 0147132. And on the -11/23: a: 055256 23214. b: 0145510 -13496. d: 070200 28800. q: 055256 23214. r: 037110 15944. Note that the returned 'quotient' is simply the high part of the dividend. And on the -11/73: a: 055256 23214. b: 0145510 -13496. d: 070200 28800. q: 055256 23214. r: 037110 15944. Note that in addition to the quotient behaviour, as with the /23, the 'remainder' is the low part of the dividend. Noel

6 years, 9 months

Re: [TUHS] RIP John Backus

by jnc＠mercury.lcs.mit.edu

> From: Paul McJones <paul(a)mcjones.org> > I suspect the CPU architect (Gene Amdahl -- not exactly a dullard) > intended programmers store array elements at increasing memory > addresses, and reference an array element relative to the address of the > last element plus one. This would allow a single index register (and > there were only three) to be used as the index and the (decreasing) > count. I suspect the younger members of the list, who've only ever lived in a world in which one lights ones cigars with mega-gates, so to speak, may be missing the implication here. Back when the 704 (a _tube_ machine) was built, a register meant a whole row of tubes. That's why early machines had few/one register(s). So being able to double up on what a register did like this was _HYYUUGE_. Noel

6 years, 9 months

Re: [TUHS] RIP John Backus

by Paul McJones

On 3/17/2018 8:54 AM, Dave Horsfall <dave(a)horsfall.org> wrote: > ... Was it the 704, or the 709? I recall that the > array indexing order mapped directly into its index register or something > ... It first ran on the IBM 704, whose index registers subtracted (as did the follow-on 709, 7090, etc), so array indexing went from higher memory addresses to lower. > The bookshelf: I had most of those books once; what's the one on the > bottom right? It has a "paperback" look about it, but I can't quite make > it out because of the reflection on the spine. I'm not sure, and things have shifted since then on the shelves, but I sent the original photo to your email address.

6 years, 9 months

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 March 2018