TUHS

tuhs@tuhs.org

16 participants
6536 discussions

Re: [TUHS] Claim your early Unix contributions on GitHub

by Norman Wilson

Marc Rochkind: BSD is the new kind on the block. I don't think it came along until 1977 or so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in the PWB releases, if you don't count the earlier version in SNOBOL4 for the IBM mainframes. ===== Correct. We never needed no stinkin' revision control in Research. More fairly, early systems like SCCS were so cumbersome that a community that was fairly small, in which everyone talked to everyone, and in which there was no glaring need wasn't willing to adopt them. I remember trying SCCS for a few small personal projects back in 1979 or so (well before I moved to New Jersey), finding it just too clunky for the benefits it gave me, and giving up. Much later, I found RCS just as messy. One thing that really bugged me was those systems' inherent belief that you rarely want to keep a checked-out copy of something except while you're working on it. Another, harder to work around, is that in any nontrivial project there are often stages when I want to make changes of scope broader than a single file: factor common stuff out into a new file, merge things into a single file, rename files, etc. CVS was a big step forward, but not enough. Subversion was the first revision-control that didn't feel like a huge burden to me. None of which is to say that SCCS and RCS were useless; they were important pioneers, and for the big projects that originally spawned them I'm sure they were indispensible. But I can't imagine Ken or Dennis putting up with them for very long, and I'm glad I never had to. Norman Wilson Toronto ON

9 years, 3 months

Used punched cards. (was Early non-Unix filesystems?)

by Doug McIlroy

> These are USED cards. That's OK. No duty! Quite the opposite happened to me in Britain. I wanted to import an early computer-generated film to show. When I inquired whether there would be any customs implications, I was asked whether the film was exposed or not. Britain charged duty only on exposed film. With apologies for straying ever farther from Unix, Doug

9 years, 3 months

Re: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > That makes sense, and someone forgot to document it... Or perhaps it was added precisely to get rid of the window, and then someone discovered that it could be used to freeze the system, so they decided they'd better not document it? If the system had MOS memory, and you had to power cycle the machine to get it out of this state, there wouldn't be any evidence left of who did the deed (unless the system was writing extensive audit trailing to disk), so it would be a great 'system assasin' (aka vandal) tool. Noel PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic!

9 years, 3 months

Re: [TUHS] Early non-Unix filesystems?

by Nemo

On 21 March 2016 at 17:43, Greg 'groggy' Lehey <grog(a)lemis.com> wrote: > On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote: >> >> Walking down the corridors of Comp Sci, a student in front of me >> dropped his entire deck of approx 2000 cards, all over the floor... >> I have no idea whether he got them sorted, but I sure as hell used >> rubber bands after that! > > But that's what the sequence numbers in columns 73 to 80 are for! I did that religiously, even with my small PL/C runs -- PL/C runs were free. One day, they decided to extend the code area to the entire card.... and so I learned another feature of the card punch. N. > > Greg > --

9 years, 3 months

Re: [TUHS] PDP-11/70 SPL

by Johnny Billquist

Thanks for some additional information. On 2016-03-28 18:16, Milo Velimirović wrote: > >> On Mar 28, 2016, at 9:44 AM, Johnny Billquist <bqt(a)update.uu.se> wrote: >> >> On 2016-03-28 16:18, Noel Chiappa wrote: >>> > From: Dave Horsfall <dave(a)horsfall.org> >>> > > [ Wait & RK discussion snipped.] > >> >> >>> > I know that Kevin Dawson (I think) tried it on my /40 as well >>> >>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor >>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) >> >> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant? > > These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine. Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but this would definitely not block interrupts for the next instruction. So at least in that case, a WAIT could result in the kernel sitting around waiting for the next interrupt. I don't really think DEC intend WAIT to be used in the way Unix uses it, and it don't really have the properties that would be ideas for Unix. Also somewhat indicated by the fact that DEC did not use WAIT this way themselves. 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

9 years, 3 months

Re: [TUHS] PDP-11/70 SPL

by Johnny Billquist

On 2016-03-27 23:49, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > > From: Johnny Billquist > > > It would also be interesting if anyone can come up with a good reason > > why SPL should work that way. > > So that when doing: > > SPL 0 > WAIT > > you don't lose by having the interrupt happen between the SPL and the WAIT? Hmm. A good point. If you depend on WAIT waking you up at an interrupt, then you need SPL to block here. But this also means that you must be at SPL 7 before any of this, otherwise you are still exposed to this problem (nothing says that the interrupt won't happen before the SPL as well). In general, I would say that this is not the way I would write code, but checking in RSX and 2.11BSD I can tell that RSX do not use this pattern, and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by WAIT. And the routine in 2.11BSD is also called at SPL 7. So obviously, both ways have been done, and 2.11BSD will work potentially with a slight degration if the SPL do not block interrupts. It will still work fine, as you will, at a minimum, get an interrupt at the next clock tick, which will wake it up. But it might possibly be sitting in a WAIT slightly longer than required. RSX in fact just loops after the WAIT. If an interrupt should cause the system to be able to do something more productive, it will not return to the idle loop. So yes, it also detects in the interrupt exit processing, that it was/is in the idle loop. I still haven't had time to investigate properly. But at least processor and chip manuals do not say that SPL will block interrupts. But that is no guarantee that it don't in reality. 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

9 years, 3 months

Re: [TUHS] PDP-11/70 SPL

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > SPL 7 was only used by the clock interrupt Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only interested in accuracy.) > even the published Unibus spec was known to be wrong, in order to keep > 3rd-party kit out of it (it was something subtle to do with buss timing, > so sometimes the card worked, and sometimes it didn't, doing wonders for > your reputation). I don't know about that, but we built two UNIBUS DMA networking devices, relying on the UNIBUS description in the 1975 Peripherals Handbook, and they both worked fine (one became a product for Proteon). > Slightly longer? I think it was Lions himself who used to teach us that > a lost interrupt is nasty :-( The interrupt isn't lost, it's just that the OS does a WAIT when it should perhaps return and start up some user process - but that resumption of doing user computations is delayed by at most 1 clock tick (some other device may interrupt during the WAIT, before the clock does). > Anyone here remember overlapped seeks on the RK-11 failing under Unix I'd be interested in the details of this. The V6 RK driver didn't use them, but the RK11-D does claim to support them (having spent a modest amount of time looking at the drawings), so I'd very much like to know what the bug was. > I know that Kevin Dawson (I think) tried it on my /40 as well The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) > Christ, but this is starting to sound like some religion or other. I am only interested in correct data. Noel

9 years, 3 months

Re: [TUHS] PDP-11/70 SPL

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > this also means that you must be at SPL 7 before any of this Yes, I assumed that (since it wouldn't make sense otherwise :-). > In general, I would say that this is not the way I would write code, but > ... 2.11BSD do an SPL 0 followed by WAIT. Right; even if one does something like have every interrupt set a flag (which is cleared while interrupts are disabled), and check that after lowering the priority, but before doing the WAIT, there's _still_ a window between that check, and the WAIT (although I guess it's less likely to be hit, since the interrupt request would have to be posted _in that window_, not be hanging around waiting to be serviced). The only way (that I can work out) to atomically lower the priority and wait is to do an RTI with the PC on the stack pointing to the WAIT instruction, but I'm not sure even that is guaranteed to work. I guess it all depends on the CPU implementation: does it check for pending interrupts before each instruction, or only at the end of each instuction, or what? If before, and there's an interrupt pending, it will go off before the WAIT is executed. Although I suppose if it's at the end, it would do the check at the end of the RTI, and do the interrupt then. And whether it's at the end, or the beginning, WAIT itself must be special cased, to check for pending interrupts during the execution (which can take an indeterminate amount of time). > 2.11BSD will work potentially with a slight degration if the SPL do not > block interrupts. It will still work fine, as you will, at a minimum, > get an interrupt at the next clock tick, which will wake it up. But it > might possibly be sitting in a WAIT slightly longer than required. Yes, exactly. > RSX in fact just loops after the WAIT. If an interrupt should cause the > system to be able to do something more productive, it will not return to > the idle loop. So yes, it also detects in the interrupt exit processing, > that it was/is in the idle loop. Does it detect if it was _before_ the WAIT instruction? I would assume it does, but I don't know anything sbout RSX. > But at least processor and chip manuals do not say that SPL will block > interrupts. Yes, I looked too, in a variety of places (PDP-11 Architecture, including in the 'model differences' table, 11/73 Tech Manual, etc). Crickets... Noel

9 years, 3 months

Re: [TUHS] Teletype simulator?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > I thought it would be nice to get a feel for what it was like to use a > real tty Make sure it only prints 10 characters per second, then. (I think TTY's were 10 cps?) R-e-a-l-l-y s-l-o-w. Noel

9 years, 3 months

Re: [TUHS] Character sets (was: Command-line options)

by Johnny Billquist

On 2016-03-27 08:18, Greg 'groggy' Lehey<grog(a)lemis.com> wrote: > Isn't it wonderful that we no longer have issues with character > representation? I hope that comment was meant as a joke, ironic, cynical, or whatever... 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

9 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