TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Paul Ruizendaal

With some further reading and research (and the kind help of Heinz Lycklama and Jon Steinart) I’ve found that my understanding of early loop networks at Bell Labs confused several different systems. As far as I can currently tell there were at least 4 different loop networks developed around 1970 at Murray Hill. 1. The first one is the “Newhall Loop” (paper published in 1969). This loop used twisted pair cabling, ran at about 3Mhz and used variable sized messages. It seems to have used some sort of token to coordinate between hosts. This might have been the network that Ken Thompson recalled as having been in operation when he arrived at the labs in 1966. 2. The second one appears to have been the “Pierce Loop”, as described in 3 BSTJ papers submitted in 1970/71. This one was coax based, used T1 compatible frames and was used to connect H516 computers with various bits of equipment. It seems to have had a very short life span. Part of my confusion was that the term Pierce Loop also appears to have been used in a generic sense to denote loop networks with fixed-sized frames. 3. The third one is the “Weller Loop” (paper published in 1971). This loop used coax cabling, ran at 3.3Mhz and used fixed 35 bit frames/cells. Each cell carried one address byte and two data bytes. One participant on the loop was the controller and effectively polled the other stations. In its 1971 form it appears to have been for the H516’s only and was referred to as a “Serial I/O bus”. This is what Jon Steinhart was talking about. The Weller loop was later redesigned (memo written in 1973) to interface with PDP-11’s as well. Heinz Lycklama used this loop in 1974 to connect several systems running (rump) Unix - see his paper about peripheral Unix here: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… <https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…> This Serial I/O bus remained in use for several years at least. 4. The fourth and best known one is the “Spider Loop” (memo published in 1974, but operational from 1972). Twisted pair cabling, using T1 compatible frames. In use until about 1978. Main uses appear to have been the ‘nfs’ file store and the ‘npr’ remote printing service. My conclusion from all that is that in 1974 Unix had access to two networks, Spider and the Serial I/O bus. For both, first experiments would have been in 1973. It is hard to be sure which one came first. If I had to venture a guess today, I’d say that Spider connected to Unix several months before the Weller loop (even though the 1st generation Weller loop preceded Spider). Maybe the conclusion is that both happened more or less in parallel: Weller was also one of the designers of the Spider hardware.

5 years, 2 months

Interesting problem

by Gregg Levine

Hello! I normally download items from the Society FTP site rather than from the archival area on the website. And my clients kept getting bounced, claiming that I should stop trying to connect frequently. Oddly enough that was not the case a while ago. Was the archive recently updated regarding hosting software? On Windows it was FileZilla, and spun down to one rather than eight or ten. And on the WSL SLES12 SP3 arrangement it was ncftp. Now downloading the reports to go along with the one Paul made available from the location is not important for today, I can wait until tomorrow or the next day. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

5 years, 2 months

Re: [TUHS] Origins and life of the pg pager

by Norman Wilson

Rob Pike: Yeah, p is all we need. I think it originated with td at UofT. I might have brought it with me to Bell Labs, or recreated it. Probably the former. ==== The former, I think. The source code in V10 is very similar to that you left behind at Caltech (where I first encountered p). Most differences have to do with using opendir and readdir rather than reading raw directories in the SPname code. A further clue is that, even in V10, p.c begins /*%cc p.c pad.o spname.o */ The tool that looked for such lines to tell it how to compile things (I forget its name; was it comp?) doesn't seem to have survived in the archival backup I have from Caltech HEP, but I'm quite sure it came from U of T as well. Norman Wilson Toronto ON

5 years, 2 months

Re: [TUHS] Origins and life of the pg pager

by Doug McIlroy

> less(1) was actually an improvement Hmm. Less is my favorite whipping boy for featuritis. % less --help |wc 242 1331 12202 I am very happy with p. Doug

5 years, 2 months

v7 K&R C

by Adam Thornton

The C in v7 is, canonically, the language described in K&R, right? I must be doing something dumb. I am getting Webb Miller’s “s” editor built there, and I am down to one function. /* chop_arg - chop a function's argument to a maximum length */ static chop_arg(fcn, arg, maxlen) int (*fcn)(); int maxlen; char *arg; { char save; save = arg[maxlen]; arg[maxlen] = '\0'; fcn(arg); arg[maxlen] = save; } This doesn’t like the function pointer. $ cc -c choparg.c choparg.c:11: Call of non-function So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7? Adam

5 years, 2 months

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

by jnc＠mercury.lcs.mit.edu

> From: Diomidis Spinellis > From the 2.11 BSD sources I understand that the PDP-11/70 MMU address > and data registers, KDSA and KDSD, start at 0172360 and 0172320 > respectively ... Expressed as 16-bit addreses, on a PDP-11 with mapping disabled, yes. > I checked this by looking at /dev/mem. I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS; on a /70 it's a separate 22-bit address bus). In the /70 memory address space, the 'I/O page' (which is where the PxR's live) is at the top end of it, i.e. the registers are at 017772360 (KDSAR0), etc. > What am I missing? PDP-11's have a plethora of address spaces, of different sizes. You need to always be aware of which one you're working in. > My goal is to access from the console the kernel's u area. According to > mem(4) and the symbols in /unix, this should be at address 0140000. In the kernel virtual address space, yes. > Indeed, accessing it through /dev/kmem I get the expected results for > e.g. u_comm and u_uid. Because /dev/kmem gives access to kernel address space for the _current_ process. > I have been unable to find it in the machine's physical memory By far and away the easiest thing, for the _current_ process, is to use /dev/kmem, which automagally applies the correct mapping. For other processes, if the process is swapped in, there's some field in the proc structure which says where in physical memory it us. IIRC, the user struct and the kernel stack are stored in the very bottom of that. (This article: http://gunkies.org/wiki/Unix_V6_dump_analysis#Memory_layouts goes into some detail for V6. Not sure how different 2.11 is; I know it uses one block of kernel address space to map in code overlays, but I don't know all the details of how it works.) Anyway, using that, one could read the user area in /dev/mem, at the appropriate location. For swapped-out processes, a similar algorithm applies, but you'll have to look in the swap device (obviously). Noel

5 years, 2 months

Re: [TUHS] v7 K&R C [really lexers]

by Doug McIlroy

Interesting. My "speak" program had a trivial lexer that recognized literal tokens, many of which were prefixes of others, by maximum-munch binary search in a list of 1600 entries. Entries gave token+translation+rewrite. The whole thing fit in 15K. Many years later I wrote a regex recognizer that special-cased alternations of lots of literals. I believe Gnu's regex.c does that, too. (My regex also supported conjunction and negation-- legitimate regular-language operations--implemented by continuation-passing to avoid huge finite-state machines.) We have here a case of imperfect communication in 1127. Had I been conscious of the lex-explosion problem, I might have thought of speak and put support for speak-like tables into lex. As it happened, I only used yacc/lex once, quite successfully, for a small domain-specific language. Doug Steve Johnson wrote: I also gave up on lex for parsing fairly early. The problem was reserved words. These looked like identifiers, but the state machine to pick out a couple of dozen reserved words out of all identifiers was too big for the PDP-11. When I wrote spell, I ran into the same problem. I had some rules that wanted to convert plurals to singular forms that would be found in the dictionary. Writing a rule to recognize .*ies and convert the "ies" to "y" blew out the memory after only a handful of patterns. My solution was to pick up words and reverse them before passing them through lex, so I looked for the pattern "sei.*", converted it to "y" and then reversed the word again. As it turned out, I only owned spell for a few weeks because Doug and others grabbed it and ran with it.

5 years, 2 months

Accessing the PDP-11/70 MMU registers and the kernel's u area

by Diomidis Spinellis

From the 2.11 BSD sources I understand that the PDP-11/70 MMU address and data registers, KDSA and KDSD, start at 0172360 and 0172320 respectively [1]. Yet, when I read the register contents I don't get what I would expect to see: increasing by 0200 memory values for KDSA and the same constant value for KDSD [2]. I checked this by looking at /dev/mem. # od -o /dev/mem 0172360 | head -1 0172360 000002 000016 001403 012700 000400 000402 012700 000200 # od /dev/mem 0172320 | head -1 0172320 101016 005064 000026 005067 175456 016467 000006 175430 I get the same results when I examine the memory through SIMH: sim> examine 172360 172360: 000002 sim> examine 172362 172362: 000016 sim> examine 172364 172364: 001403 sim> examine 172320 172320: 101016 sim> examine 172322 172322: 005064 The MMU kernel instruction registers, KISA and KISD, contain similarly nonsensical values as do the registers located at a different memory location (077320, 0772360) indicated in another source [3]. What am I missing? My goal is to access from the console the kernel's u area. According to mem(4) and the symbols in /unix, this should be at address 0140000. Indeed, accessing it through /dev/kmem I get the expected results for e.g. u_comm and u_uid. However, I have been unable to find it in the machine's physical memory, hence my question regarding the MMU's operation. [1] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L346 [2] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L247 [3] https://gunkies.org/wiki/PDP-11_Memory_Management Diomidis

5 years, 2 months

non-blocking IO

by Paul Ruizendaal

This time looking into non-blocking file access. I realise that the term has wider application, but right now my scope is “communication files” (tty’s, pipes, network connections). As far as I can tell, prior to 1979 non-blocking access did not appear in the Spider lineage, nor did it appear in the NCP Unix lineage. First appearance of non-blocking behaviour seems to have been with Chesson’s multiplexed files where it is marked experimental (an experiment within an experiment, so to say) in 1979. The first appearance resembling the modern form appears to have been with SysIII in 1980, where open() gains a O_NDELAY flag and appears to have had two uses: (i) when used on TTY devices it makes open() return without waiting for a carrier signal (and subsequent read() / write() calls on the descriptor return with 0, until the carrier/data is there); and (ii) on pipes and fifo’s, read() and write() will not block on an empty/full pipe, but return 0 instead. This behaviour seems to have continued into SysVR1, I’m not sure when EAGAIN came into use as a return value for this use case in the SysV lineage. Maybe with SysVR3 networking? In the Research lineage, the above SysIII approach does not seem to exist, although the V8 manual page for open() says under BUGS "It should be possible [...] to optionally call open without the possibility of hanging waiting for carrier on communication lines.” In the same location for V10 it reads "It should be possible to call open without waiting for carrier on communication lines.” The July 1981 design proposals for 4.2BSD note that SysIII non-blocking files are a useful feature and should be included in the new system. In Jan/Feb 1982 this appears to be coded up, although not all affected files are under SCCS tracking at that point in time. Non-blocking behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is returned instead of 0 when progress is not possible. The non-blocking behaviour is extended beyond TTY’s and pipes to sockets, with additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not the same error number as EGAIN. It would seem that the differences between the BSD and SysV lineages in this area persisted until around 2000 or so. Is that a fair summary? - - - I’m not quite sure why the Research lineage did not include non-blocking behaviour, especially in view of the man page comments. Maybe it was seen as against the Unix philosophy, with select() offering sufficient mechanism to avoid blocking (with open() the hard corner case)? In the SysIII code base, the FNDELAY flag is stored on the file pointer (i.e. with struct file). This has the effect that the flag is shared between processes using the same pointer, but can be changed in one process (using fcntl) without the knowledge of others. It seems more logical to me to have made it a per-process flag (i.e. with struct user) instead. In this aspect the SysIII semantics carry through to today’s Unix/Linux. Was this semantic a deliberate design choice, or simply an overlooked complication?

5 years, 2 months

Unix V6: Assembler Listings

by Paul Ruizendaal

> I am now writing code in assembly for the PDP-11. I remember reading > somewhere that the output from "AS" (my caps) is a bit meagre. I can't find > an option to produce a text listing. Is it possible from AS, using command > options (I can't see one) or perhaps from "LD"? > > Paul > > *Paul Riley* I had the same problem. As I was porting to a different mini I had to write a new assembler. As you have undoubtedly seen, early ‘as’ was written in assembler and not so easy to use as a base. Hence I used Richard’s Miller’s AS for the Interdata as a base (available on Tuhs): https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/as Later I discovered that the TUHS archive has source code for the original ‘as’ rewritten in C, a work by Roger Jaeger: https://minnie.tuhs.org/Archive/Distributions/USDL/Mini-Unix/ Maybe adding a listing module to this version of ‘as’ is another possible route.

5 years, 2 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