TUHS

tuhs@tuhs.org

6 participants
6532 discussions

by Tony Finch

Another question at the intersection of the Internet-History and TUHS lists... I was wondering about the early history of BIND. I started off wondering about the relative ages of JEEVES (the original PDP10 DNS server) and BIND. Judging by the dates on RFCs 881 - 883, the DARPA contract commissioning BIND, and the Berkeley tech reports, it seems there wasn't much time when the DNS was without BIND. But I was struck by the resolver API set out on page 8 of Berkeley tech report UCB/CSD-84-182: it looks nothing like the familiar API that ended up in 4.3BSD. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/lib/libc/net/n… So I'm wondering if there's anything out there recording the history between the 1984 tech reports and the 4.3BSD release in 1986. (It's also noteworthy that early BIND supported incremental DNS updates and zone transfers, which didn't reappear in standard form until RFC 2136 (1997) and RFC 1995 (1996)...) Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ public services of the highest quality

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by Paul Ruizendaal

Doug, “In fact Dennis's compiler did not use AID instructions for that purpose.” Whilst local variables are indeed accessed as an offset from the base pointer, I’m not sure that the above statement is correct. In the V6 compiler (-sp) was certainly used to push arguments to the stack, and when the register allocation overflowed, the interim results were pushed to the stack as well with (-sp). See c10.c, the case CALL in rcexpr(), the function comarg() and sptab (which is right at the end of table.s) Links: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c10.c https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/table.s For interim result pushing/popping I refer to the FS and SS macro’s. Dennis discusses these in his “A tour of the C compiler” paper. https://www.jslite.net/cgi-bin/9995/doc/tip/doc/old-ctour.pdf Of course this is all implementational detail, not a core design aspect - as Richard Miller showed in his port to the Interdata architecture (including a port of the Ritchie C compiler). Maybe the sentence should have read: "In fact Dennis's compiler did not rely on having AID instructions for that purpose." Paul @Warren: at moments like these I really like having the line highlight feature that we discussed before Summer.

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: John Cowan > That's always true on the PDP-11 and Vax ... because the processor > architecture (which has pre-increment and post-decrement instructions, > but not their counterparts) After Doug's message, I carefull re-read this, and I'm not sure it's correct? The PDP-11 has pre-decrement and post-increment, not the other way around (as above) - unless I'm misunderstanding what you meant by those terms? That's why: *p++ = 0; turns (if p is in R2) into CLR (R2)+ R2 is used, and then incremented after it has been used. Noel

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by Doug McIlroy

> That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. I hadn't heard this urban legend before. A stack is certainly manageable without auto-increment/decrement (AID) instructions. In fact Dennis's compiler did not use AID instructions for that purpose. AID instructions are nice for a LIFO stack, in which a stacked item disappears as soon as it's used--as do intermediate results in expression evaluation. But when the stack contains local variables that are accessed multiple times, the accesses are offset from the stack pointer. If AID instructions set the pointer, then the offset of a particular local varies throughout the code. The compiler can cope with that (I once wrote a compiler that did so), but a debugger will have a devil of a time doing a backtrace when the offset of the return address in each stack frame depends on the location counter. AID instructions are fine for sequentially accessing arrays, and in principle Ken's ++ and -- operators can exploit them. Yet idiomatic C typically wants post-increment and pre-decrement instructions--the opposite of what DEC offered. Examples: char a[N], b[N]; char *ap = a; char *bp = b; int i; for(i=0; i<N; i++) *ap++ = *bp++; int a[N], b[N]; int i = N; while(--i >= 0) a[i] = b[i]; Doug

4 years, 10 months

Memory management in Dennis Ritchie's C Compiler

by Dibyendu Majumdar

Hi, I have a project to revive the C compiler from V7/V10. I wanted to check if anyone here knows about the memory management in the compiler (c0 only for now). I am trying to migrate the memory management to malloc/free but I am struggling to understand exactly how memory is being managed. Thanks and Regards Dibyendu

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by Steve Simon

I am fairly sure the interdata port from Wollongong used the v6 c compiler, and this lived on in the “official” v7 port from perkin elmer, it still used the v6 compiler. i remember the pain of the global namespace for structure members. -Steve

4 years, 10 months

Re: [TUHS] bare m4 (was BTL summmer employees)

by Doug McIlroy

> >> Even high-school employees could make lasting contributions. I am > >> indebted to Steve for a technique he conceived during his first summer > >> assignment: using macro definitions as if they were units of associative > >> memory. This view of macros stimulated previously undreamed-of uses. > > > Can you give some examples of what this looked like? > See attached for an answer to Arnold's question Doug

4 years, 10 months

BTL pranks [was AT&T Research]

by Doug McIlroy

> Did the non-Unix people also pull pranks like the watertower? One of my favorites was by John Kelly, a Texas original, who refused the department-head perk of a rug so he could stamp his cigarettes out on the vinyl floor. John came from Visual and Acoustics Research, where digital signal processing pressed the frontiers of computing. Among his publications was the completely synthetic recording of "Daisy, Daisy" released circa 1963. Kelly electrified the computer center with a blockbuster prank a year or two before that. As was typical of many machine rooms, a loudspeaker hooked to the low-order bit of the accumulator played gentle white noise in the background. The noise would turn into a shriek when the computer got into a tight loop, calling the operators to put the program out of its misery. Out of the blue one day, the loudspeaker called for help more articulately: "Help, I'm caught in a loop. Help, I'm caught in a loop. ..." it intoned in a slow Texas drawl. News of the talking computer spread instantly and folks croweded into the machine room to marvel before the operators freed the poor prisoner. Doug

4 years, 10 months

Style command source available?

by Richard Salz

Is the style command (and perhaps other DWB programs) legally available anywhere? Replies to me will be summarized for the list. :) tnx.

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by norman＠oclsc.org

Dan Cross: I'll confess I haven't looked _that_ closely, but I rather imagine that the V10 compiler is a descendant of PCC rather than Dennis's V6/V7 PDP-11 compiler. ==== Correct. From 8/e to the end of official Research UNIX, cc was pcc2 with a few research-specific hacks. As Dan says, lcc was there too, but not used a lot. I'm not sure which version of lcc it was; probably it was already out-of-date. In my private half-backed 10/e descendant system, which runs only on MicroVAXes in my basement, cc is an lcc descendant instead. I took the lcc on which the book was based and re-ported it to the VAX to get an ISO- compliant C compiler, and made small changes to libc and /usr/include to afford ISO-C compliance there too. The hardest but most-interesting part was optimizing. lcc does a lot of optimization work by itself, and initially I'd hoped to dispense with a separate c2 pass entirely, but that turns out not to be feasible on machines like the VAX or the PDP-11: internally lcc separates something like c = *p++; into two operations c = *p; p++; and makes two distinct calls to the code generator. To sew them back together from cvtbl (p),c incl p to cvtbl (p)+,c requires external help; lcc just can't see that what it thinks of as two distinct expressions can be combined. It's more than 15 years since I last looked at any of this stuff, but I vaguely remember that lcc has its own interesting (but ISO/POSIX-compatible) memory-allocation setup. It allows several nested contexts' worth of allocation, freeing an inner context when there's no longer any need for it. For example, once the compiler has finished with a function and has no further need for its local symbols, it frees the associated memory. See the lcc book for details. Read the book anyway; it's the one case I know of in which the authors followed strict Literate Programming rules and made a big success of it. Not only is the compiler well- documented, but the result is a wonderful tour through the construction and design decisions of a large program that does real work. Norman Wilson Toronto ON

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: Dibyendu Majumdar > the C compiler from V7/V10. I wanted to check if anyone here knows > about the memory management in the compiler (c0 only for now). I am > trying to migrate the memory management to malloc/free but I am > struggling to understand exactly how memory is being managed. Well, I don't know much about the V7 compiler; the V6 one, which I have looked at, doesn't (except for the optimizer, C2) use allocated memory at all. The V7 compiler seems to use sbrk() (the system call to manage the location of the end of a process' data space), and manage the additional data space 'manually'; it does not seem to use a true generic heap. See gblock() in c01.c: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V7/usr/src/cmd/c/c01.c which seems to use two static variables (curbase and coremax) to manage that additional memory: p = curbase; if ((curbase =+ n) >= coremax) { if (sbrk(1024) == -1) { error("Out of space"); exit(1); } coremax =+ 1024; } return(p); My guess is that there's no 'free' at all; each C source file is processed by a new invocation of C0, and the old 'heap' is thrown away when the process exits when it gets to the EOF. Noel

4 years, 10 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: Larry > It's possible the concept existed in some other OS but I'm not aware of > it. It's pretty old. Both TENEX and ITS had the ability to map file pages into a process' address space. Not sure if anything else of that vintage had it (not sure what other systems back then _had_ paging, other than Atlas; those two both had custom KA10 homebrew hardware mods to support paging). Of course, there's always Multics... (sorry, Ken :-). Noel

4 years, 10 months

bsdcan talk

by Andrew Hume

fyi warner, in your talk, you referred to Alex Fraser at bell labs. he was my first director, and always went by “sandy”. i asked my wife (who was a secretary at the time) and she said he was occasionally referred to as Alex. certainly, every time i saw anything written by him or references to a talk by him always used “sandy”. andrew

4 years, 10 months

Re: [TUHS] TUHS Digest, Vol 55, Issue 9

by Will Senn

> > Message: 6 > Date: Fri, 5 Jun 2020 16:51:27 -0600 > From: Warner Losh <imp(a)bsdimp.com> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] My BSDcan talk > Message-ID: > <CANCZdfpq8tiDYe2iVeFh1h0VMDK+4B=kXuGSJ3iNmtjbzHQT6Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > OK. Must be off my game... I forgot to tell people about my BSDcan talk > earlier today. It was streamed live, and will be online in a week or > three... > > It's another similar to the last two. I've uploaded a version to youtube > until the conference has theirs ready. It's a private link, but should work > for anybody that has it. Now that I've given my talk it's cool to share > more widely... https://www.youtube.com/watch?v=NRq8xEvFS_g > > The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is > the proper link. > > Please let me know what you think. > > Warner > Just saw your BSDcan talk. Great stuff, so much progress in the last five years. Just wanna say thanks. When I started looking into ancient systems, it was hard finding anything coherent on the historical side beyond manuals and this list (thankful to Warren & co for the list). Your talk is packed with interesting information and really pulls together the recent pieces. Great job, Warner.

4 years, 10 months

BSTJ archives

by Kirk McKusick

I needed to look up something in the Bell System Technical Journal (Wikipedia didn't have it) and discovered that the old Alcatel-Lucent site that used to host a free archive of BSTJ no longer seems extant. (No surprise, the Web is nothing if not ephemeral.) After a bit of Googling, I did find that the archives are now residing at <https://archive.org/details/bstj-archives> and found what I was looking for there. Hope others find this link useful. At least until it too "sublimaates". Kirk McKusick

4 years, 10 months

CR delay for VT05

by Richard Tobin

Looking at the 6th edition man page tty(2), I see Carriage-return delay type 1 lasts about .08 seconds and is suitable for the Terminet 300. Delay type 2 lasts about .16 seconds and is suitable for the VT05 and the TI 700. Delay type 3 is unimplemented and is 0. New-line delay type 1 is dependent on the current column and is tuned for Teletype model 37's. Type 2 is useful for the VT05 and is about .10 seconds. Type 3 is unimplemented and is 0. Why would the VT05 (a VDU) need a delay for carriage return? I can just about imagine that it might need one for linefeed if it shifted the characters in memory. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 years, 11 months

Re: [TUHS] [simh] 2bsd tarball

by Johnny Billquist

On 2020-07-29 15:17, Paul Koning wrote: > > >> On Jul 29, 2020, at 5:50 AM, Johnny Billquist <bqt(a)softjar.se> wrote: >> >> Just a small comment. Whoever it was that thought DECtape was a tape was making a serious mistake. DECtapes are very different from magtapes. >> >> Johnny > > Depends on what you're focusing on. Most tapes are not random-write. DECtape and EL-X1 tape are exceptional in that respect. But tapes, DECtape include, have access time proportional to delta block number (and that time is large) unlike disks. > > From the point of view of I/O semantics, the first point is significant and the second one not so much. True. But seek times are in the end only relevant as an aspect of the speed of the thing, nothing else. However, seek times on DECtape aren't really comparable to magtape either. Because DECtape deals with absolute block numbers. So you can always, no matter where you are, find out where you are, and how far you will need to move to get to the correct block. With magtapes, this is pretty much impossible. You'll have to rewind, and then start seeking. 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

4 years, 11 months

2bsd tarball

by Will Senn

OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the archive. Neither is an installation tape. It appears that they are just tarballs of their respective systems (there are very minor differences between the two). In the TAPE file in the tarball, it talks about reading the tar program off of the tape using: dd if=/dev/mt0 bs=1b skip=1 of=tar Well, tar is definitely not located at that address, which implies that the tarball isn't a distro tape. This note in the archive used to read: ... The remaining gzipped tar files are other 2BSD distributions supplied by Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer. They do not contain installation tape images. The 2.9BSD-Patch directory contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic. ... now it reads: ... 2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came from Henry Spencer. ... I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? Thanks, Will Here's where I found the tarballs: https://www.tuhs.org/Archive/Distributions/UCB/ -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

in memoriam - Bill English, mouse co-creator

by Will Senn

All, About a week ago, Bill English passed away. He was a Xerox guy, who along with Douglas Engelbart of "Mother of all demos" fame, created our beloved mouse: https://www.bbc.com/news/technology-53638033 I remember, back in the mid-1980's being part of a focus group evaluating Microsoft's mouse. Wow, time flies. -Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

Re: [TUHS] BTL summer employees

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL > 8 written in C by Eliot Moss. > ... > When sending to the DOVER, the spooler waits until Spruce is > free before sending another file. Ah, so there was a spooler on the ITS machine as well; I didn't know/remember that. I checked on CSR, and it did use TFTP to send it to the Alto spooler: HOST MIT-SPOOLER, LCS 2/200,SERVER,TFTPSP,ALTO,[SPOOLER] I vaguely recall the Dover being named 'Spruce', but that name wasn't in the host table... I have this vague memory that 'MIT-Spooler' was the Alto which prove the Dover, but now that I think about it, it might have been another one (which ran only TFTP->EFTP spooler software). IIRC the Dover as a pain to run, it required a very high bit rate, and the software to massage it was very tense; so it may have made sense to do the TFTP->EFTP (I'm pretty sure the vanilla Dover spoke EFTP, but maybe I'm wrong, and it used the PUP stream protocol) in another machine. It'd be interesting to look at the Dover spooler on ITS, and see if/how one got to the CHAOS network from C - and if so, how it identified the protocol translating box. Noel

4 years, 11 months

Re: [TUHS] 211bsd kermit working

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > $c > 0177520: ~signal(016,01) from ~sysinit+034 > 0177542: ~sysinit() from ~main+010 > 0177560: _main() from start+0104 > If this means it got signal 16... or 1 from the sysinit call (called > from main) I'm not sure that interpretation is correct. I think that trace shows signal() being called from sysinit(). On V6, signal() was a system call which one could use to set the handlers for signals (or set them to be ignored, or back to the default action). In. 2.11 it seems to be a shim layer which provides the same interface, but uses the Berserkly signal system interface underneath: https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.h https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0 So maybe the old binary for kermit is still trying to use the (perhaps now-removed) signal system call? Noel

4 years, 11 months

Re: [TUHS] BTL summer employees

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > the Dover printer spooler was written using Snyder's C compiler I'm not sure if that's correct. I don't remember with crystal clarity all the details of how we got files to the Dover, but here's what I recall (take with 1/2 a grain of salt, my memory may have dropped some bits). To start with, there were different paths from the CHAOS and TCP/IP worlds. IIRC, there was a spooler on the Alto which ran the Dover, and the two worlds had separate paths to get to it. >From the CHAOS world, there was a protocol translation which ran on whatever machine had the AI Lab's 3Mbit Ethernet interface - probably MIT-AI's CHAOS-11? If you look at the Macro-11 code from that, you should see it - IIRC it translated (on the fly) from CHAOS to EFTP, the PUP prototocol which the spooler ran 'natively'. >From the IP world, IIRC, Dave Clark had adapted his Alto TCP/IP stack (written in BCPL) to run in the spooler alongside the PUP software; it included a TFTP server, and people ran TFTP from TCP/IP machines to talk to it. (IP access to the 3Mbit Ethernet was via another UNIBUS Ethernet interface which was plugged into an IP router which I had written. The initial revision was in Macro-11; a massive kludge which used hairy macrology to produce N^2 discrete code paths, one for every pair of interfaces on the machine. Later that was junked, and replaced with the 'C Gateway' code.) I can, if people are interested, look on the MIT-CSR machine dump I have to see how it (a TCP/IP machine) printed on the Dover, to confirm that it used TFTP. I don't recall a role for any PDP-10 C code, though. I don't think there was a spooler anywhere except on the Dover's Alto. Where did that bit about the PDP-10 spooler in C come from, may I enquire? Was it a CMU thing, or something like that? Noel

4 years, 11 months

BTL summer employees

by Doug McIlroy

> My unscientific survey of summer students was that they either came > from scouts, or were people working on advanced degrees in college. Not all high-school summer employees were scouts (or scout equivalents - kids who had logins on BTL Unix machines). I think in particular of Steve Johnson and Stu Feldman, who eventually became valued permanent employees. The labs also hired undergrad summer employees. I was one. Even high-school employees could make lasting contributions. I am indebted to Steve for a technique he conceived during his first summer assignment: using macro definitions as if they were units of associative memory. This view of macros stimulated previously undreamed-of uses. Doug

4 years, 11 months

211bsd kermit working

by Will Senn

I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working on a tap interface both inbound and outbound. I still have a few issues hanging around that are bugging me, but I'll eventually get to them. One that is of concern at the moment is kermit. It is in the system under /usr/new/kermit. When I call it, I get: kermit Bad system call - core dumped I don't see core anywhere and if I did, I'd need to figure out what to do with it anyway (mabye adb), but I'm wondering if anyone's used kermit successfully who is on pl 431 or knows what's going on? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 months

Regular Expressions

by Will Senn

I've always been intrigued with regexes. When I was first exposed to them, I was mystified and lost in the greediness of matches. Now, I use them regularly, but still have trouble using them. I think it is because I don't really understand how they work. My question for y'all has to do with early unix. I have a copy of Thompson, K. (1968). Regular expression search algorithm. Communications of the ACM, 11(6), 419-422. It is interesting as an example of Thompson's thinking about regexes. In this paper, he presents a non-backtracking, efficient, algorithm for converting a regex into an IBM 7094 (whatever that is) program that can be run against text input that generates matches. It's cool. It got me to thinking maybe the way to understand the unix regex lies in a careful investigation into how it is implemented (original thought, right?). So, here I am again to ask your indulgence as the latecomer wannabe unix apprentice. My thought is that ed is where it begins and might be a good starting point, but I'm not sure - what say y'all? I also have a copy of the O'Reilly Mastering Regular Expressions book, but that's not really the kind of thing I'm talking about. My question is more basic than how to use regexes practically. I would like to understand them at a parsing level/state change level (not sure that's the correct way to say it, but I'm really new to this kind of lingo). When I'm done with my stepping through the source, I want to be able to reason that this is why that search matched that text and not this text and why the search was greedy, or not greedy because of this logic here... If my question above isn't focused or on topic enough, here's an alternative set to ruminate on and hopefully discuss: 1. What's the provenance of regex in unix (when did it appear, in what form, etc)? 2. What are the 'best' implementations throughout unix (keep it pre 1980s)? 3. What are some of the milestones along the way (major changes, forks, disagreements)? 4. Where, in the source, or in a paper, would you point someone to wanting to better understand the mechanics of regex? Thanks! Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 11 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