TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by jsteve＠superglobalmegacorp.com

For the 99% of us that don’t have a SUN-3, it’ll run on TME. I followed the instructions on abiyo.net on installing SunOS 4.1.1 onto TME ( http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08… ), and then added in the v9.tar file, and walked through the instructions on bootstrapping v9 from SunOS. I just cheated by copying the SunOS disk into a new scsi disk so I didn’t have to go through the fun of labeling it. TME emulates a SUN3-150 although the BIOS appears to be for a SUN3-160(?).. so the kernel unix.v75 will work when altering the proto0a file. TME can be a little (lot!) touchy to get working, but with enough persistence you can get it booting the ‘funinthe’ v9 image. Sent from Mail for Windows 10

8 years, 4 months

Ninth Edition incomplete?

by Norman Wilson

I'll have to have a look at what's actually in the archive, but it's important to understand that there was barely a `distribution' of 8/e and never really any of subsequent systems. There was a distinct V8 tape, assembled mainly by Dennis with some help from me, in the fall of 1984. It did not exactly match the manuals that were printed, I think only for internal use, a few months before. It was sent out to about a dozen universities (and perhaps other sorts of non-commercial places), with an individual letter agreement with each destination to cover licensing. Anything after that from the original Computing Science Research Centre was effectively just random snapshots. There was a Ninth Edition manual printed up, but it still didn't really match the state of the system, partly because nobody felt up to doing the all that work and partly because various parts of the system were still changing rapidly. I remember personally making a few such snapshots at various times, e.g. one for a certain university (again under a one-off letter agreement), another for the official UNIX System Labs folks in Summit (I took the tape over there personally and helped get the system running). I have no idea whether any of those is in Warren's archives, and I don't remember whether anyone else made any such snapshots, though my role in the group by then was such that I'd probably have been involved. The `V9 for Sun' distribution was done by someone from one of our sister groups. He took a snapshot of our system at some point and worked from that. There wasn't any organized way to keep his stuff in sync with ours, and I don't think his stuff got a lot of use in the long run so there was little motivation to fix that. All of that at least partly explains the skew between system and manual pages; it was really like that. (Remember, we were a research group, not a production computing centre or a development shop.) Snapshots may have been made hastily enough that some things were missed, too. The 10/e manual came out in early 1990. It happened because enough of us wanted to have a current manual again, Doug was willing to take on the big task of overall editing for Volume 1, and Andrew Hume was energized to make Volume 2 happen--the first Volume 2 since the Seventh Edition. There was a lot of rewriting, cleanup, merging of related entries, and discarding of stuff we no longer used or no longer considered an official part of the system. I remember that the first printed copies arrived just in time for me to get one before I left the wretched suburbs forever in June 1990. Since I'd spent a lot of time working over the power-of-two sections (2 4 8), I was pleased about that. One thing that helped energize others about that manual, by the way, was that I felt the parts I was responsible for were way, way out of date, and that it was no longer accurate for the system to call itself Ninth Edition when it booted. But Edition always meant the manual, so Tenth Edition would be wrong too. I made the boot message say 9Vr2. I figured that would annoy people enough to help convince them to help get a new manual out. I have no data as to how big a help that was. I don't know how many `V10 distributions' Warren has at this point, but one of them is derived from a snapshot I made during a visit to Bell Labs in 1994 or 1995. I had rescued some MicroVAXes before they disappeared into dumpsters, and decided it would be fun to set up a system or two running Research UNIX for my private enjoyment. (I was working at a university that had a letter agreement for 9/e--one of the tapes I'd made, in fact--and a certain department head at Bell Labs decided that as long as I didn't spread the code around, that was probably enough to keep lawyers happy.) I made rather a raw snapshot of the root, /usr, and the whole master source-code area, but with /etc/passwd trimmed of any real passwords. Some years later (and with the help of the resulting running systems) I made a few tar images for Warren to keep in his secret box pending the license issue (which we were discussing even back then). I removed some stuff that didn't belong to Bell Labs and wasn't really part of the system (e.g. some big mathematical packages, a huge bolus of X11 code that had never compiled and never would), and segregated in a separate tar image some stuff that was arguably part of the system but that might technically belong to others (e.g. our workhorse C compiler was based on pcc2, work scj had done over at USG/USL after he'd left the Research world). None of that was really curated either, and there had certainly been further changes to the system since the final 1990 manual was printed, not all of which had been properly reflected in /usr/man. So don't call those systems distributions, because they're not. More important, don't expect them to be fully coherent, because they aren't: they're snapshots, not formal releases. Norman Wilson Toronto ON

8 years, 4 months

Ninth Edition incomplete?

by Diomidis Spinellis

First, many thanks to all people who made it possible to release v8 to v10 and especially to Warren for bringing them together. I went through the files in the Ninth Edition available at http://www.tuhs.org/Archive/Distributions/Research/Norman_v9/ and I fear that the distribution may be incomplete. The manual pages for most sections are missing. Also, many v8 /usr/src/cmd commands are not available in v9 /cmd. This is the list of the difference between the two sets. 2621 300 300s 4014 450 512restor ac accton Admin apply arcv arff as asa ascii asd at awk bad144 basename bcd bundle byteyears c2 cal calendar cb cbt cc ccom cflow cflow checkeq chgrp clri col comm compact compat config cref crypt csh ct ctags cvcrypt cyntax daemon dcheck deroff des descrypt diction diff3 dircmp dired dmesg dskcpy dump dumpcatch dumpdir efl ether ex expand f77 factor false fcopy finddev flcopy fold fsplit fstat getopt getuid graph group gsi head hideblock hist hoc hp icheck ideal idiff inet install iostat kasb labmake last lcomp ld learn lfactor lint load log logdir look m4 mail Mail makekey man map mesg mips mkbitfs mkstr monk morse ncheck neqn netfsbug newer news nm number numdate oops pack paste pcc1 PDP11 plot primes prof pstat pti ptx punct qed quot random rarepl ratfor rcp readslow refer reloc renice reset restor rev rp07dump rp07rest sa savecore sdb sdiff seq server settod showq snocone spell spline split struct style sum swapon tabs tape tcat tk tp tpr tr trace track trim tsort ul und unexpand uniq units upas uucp uudecode uuencode v8 value view2d vis where wwb wwv xref xstr yacc yes Anyone knows what is going on? Does someone have a more complete distribution of the Ninth Edition that Warren can put online? Diomidis

8 years, 4 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by Nelson H. F. Beebe

I was pleased to see the announcement from David du Colombier <0intro(a)gmail.com> of a SIMH VAX image for the newly-released 8th Edition Research Unix, and I had it downloaded and running in short order. I compiled and ran the traditional hello-world test in C, successfully, but the C++ and Fortran companions would not link: # cat hello.cpp #include <stream> int main(void) { cout << "Hello, world...this is C++" << endl; return (0); } # CC hello.cpp cc hello.cpp -lC ld:hello.cpp: bad magic number I also tried extensions .C, .cxx, and .cc, with the same error. With Fortran, I get # cat hello.f print *,'hello ... This is a Fortran 77 program!' end # f77 hello.f hello.f: MAIN: Undefined: __bufendtab _setvbuf The missing symbols do not appear to be defined anywhere in /lib or /usr/lib, suggesting that some V8 libraries have been lost. David reports privately that he sees the same issues that I see. Can anyone on this list identify the problem? Normally, Unix compilers should supply the necessary libraries for standard-conforming code, and f77 would silently add -lI77 and -lF77. The C++ compiler issue seems to be quite different: adding the -v (trace) option shows what it does: # CC -v hello.cpp cc -v hello.cpp -lC + ld -X /lib/crt0.o hello.cpp -lC -lc ld:hello.cpp: bad magic number The source code, rather than the object code, is passed to the loader. This may have to do with the choice of extension: what did early C++ compilers expect for filenames? ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

8 years, 4 months

Tenth Edition: /usr/include + get it running

by Warren Toomey

All, I've just had an e-mail from someone to say that the two 10th Edition versions we now have in the Unix Archive are missing /usr/include: ----- Forwarded message from someone ----- /usr/include is missing from both Dan's and Norman's archive. Here it is (with a README). The timestamp on these files is: -rw-r--r-- 1 root staff 307 Sep 3 1997 README -rw-r--r-- 1 root staff 829440 Sep 3 1997 r70include.tar ----- End forwarded message ----- I've put these files into http://www.tuhs.org/Archive/Distributions/Research/Norman_v10/ Now that we have 9th Edition up and running, it would be good to see 10th Edition also up and running. I know there are people out there who can help with this, so this is a call out for help and for volunteers. Cheers, Warren P.S The UUCP project is now up to 23 sites: https://github.com/DoctorWkt/4bsd-uucp/blob/4.3BSD/uucp.png

8 years, 4 months

TUHS GitHub org

by Cory Smelosky

All, I have created a TUHS-related github org to store: 1). UUCP-related patched software 2). patched/maintained c-news 3). forks et al of newsreaders Largely just to give a central locatiom. Usual disclaimers apply...if you want me to delete the org/change name/transfer ownership/etc just shoot me an email. https://github.com/TUHS -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

8 years, 4 months

Re: [TUHS] Pi, samuel, cin and 8th, 9th, 10th Edition Unix

by Doug McIlroy

> If anyone has any information about 'samuel' or 'cin', > I would be delighted to hear from him or her. cin appears in the v9 and v10 manuals. Thus if the program is found in the wild, there should be no compunction about adding it to the tuhs archive. Doug

8 years, 4 months

Re: [TUHS] [Uucp] bringing systems up

by Cory Smelosky

Due to having an actual NSA VAX...I think I should get NSAVAX ;) Sent from my iPhone > On Mar 30, 2017, at 23:13, Dave Horsfall via Uucp <uucp(a)minnie.tuhs.org> wrote: > >> On Thu, 30 Mar 2017, Kurt H Maier via Uucp wrote: >> >> kremvax and moskvax are online. What's the policy on uucp.map entries >> for hosts that never really existed in the first place? > > Hmmm... I wouldn't mind having "kgbvax" in that case (I've relinquished > "utzoo" to Henry Spencer himself). Or possibly "ciavax" or "fbivax"... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 4 months

Pi, samuel, cin and 8th, 9th, 10th Edition Unix

by Noel Hunt

I was just the other day apprised of the fact that Warren Toomey had finally got permission to make public sources from Eight, Ninth and Tenth Edition Unix. It was Paul McJones from the Software Preservation Group who made me aware of this because some months ago I was in touch with him in regard to the status of source for 'pads/pi' which is on the SPG website. That was donated by Bjorn Stroustrup in 2004 I believe, as an example of a large C++ project, along with sources for 'cfront'. I myself have been working on pads/pi in a desultory fashion since 1990 when I left the Basser Department of Computer Science at the University of Sydney; we had an Eighth Edition licence, hence source code, and all of the blit/jerq utilities. I ported 'pads' to the Plan9 graphics model many years ago, and finally started to port 'pi' to Solaris 11 a couple of years ago. This works in a rudimentary fashion, but needs a Dwarf interface. Given that Bjorn Stroustrup released this code long ago (a much later version than what I had), I daresay there are no problems with its publication. I have, however, also worked on 'samuel' and ported its functionality to the Plan9 'sam'. 'samuel' does not appear in any of the archives that Wareen Toomey has made available, so I am wondering what its status may be. It was written by John Puttress at the labs in the late '80s, when he was apparently working under Ted Kowalski. Ted Kowalski is also a 'person of interest' because he wrote 'cin', the C interpreter, an interface to which exists in 'samuel'. Ted Kowalski unfortunately passed away some years ago and no-one seems to know where the source is. It again, isn't in any of the archives that Wareen Toomey has been able to make available. If anyone has any information about 'samuel' or 'cin', I would be delighted to hear from him or her. Bruce Ellis, who wrote 'cyntax', told me that he worked on 'cin' a lot (in the '90s I think, when he worked at Bell Labs) but it was succeeded by something named 'vice', about which I can find no information. Again, I would be grateful for any information about this. Regards, Noel Hunt

8 years, 4 months

Re: [TUHS] Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Joerg Schilling: This is done on a UNIX implementation that uses STREAMS. SVr4 is such a UNIX. ====== I know that SVr4 has STREAMS (somewhat more elaborate than the original stream I/O system, but the same principles), and knew (though I'd forgotten) that Ethernet devices are stream-capable. I did an implementation of the late lamented Coraid's AoE protocol that took advantage of that. Somewhat like the Research IP implementation, in fact: there was an AoE line discipline to be pushed onto an Ethernet device, coupled to devices in /dev/dsk and /dev/rdsk. But is IP done that way in SVr4 (or at least in Solaris, its most-visible descendant)? I had the impression that the IP stack was more like the BSD one, with everything coupled together within the kernel and a fundamentally socket interface. I've never actually looked at the code, though. Norman Wilson Toronto ON

8 years, 4 months

Re: [TUHS] Release of 8th, 9th and 10th Editions Unix

by Norman Wilson

Arnold: > Well, I'll take credit for pushing Norman yet again. :-) ARGGH. That should have been Well, I'll take credit for pushing Warren ... ^^^^^^ ===== I confess I didn't notice the fumble the first time. But in fact Warren has had the dubious pleasure of pushing me for something more than once. So just think of it as another level of indirection. Norman Wilson Toronto ON

8 years, 4 months

Re: [TUHS] Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Ron Natalie: It's a violation of the network layering concept to require or even allow the user to bind the application data streams to a physical device. ===== Oh, come on. If you mean an applications programmer shouldn't have to wallow in low-level network details, I agree. That's one of the reasons I think the socket interface now standard in nearly every UNIX is an abomination. It reminds me of the binary data structures you had to assemble just to open a file in TOPS-10, only ten times worse. But if you mean it's a violation of layering for the kernel to expose the pieces and let user-mode code to the work, I strongly disagree. By that argument, the very idea of inetd is an abomination. Possibly even the ifconfig command. And don't even get the hypothetical you started on microkernels. User-mode code for device drivers or file systems? Outrageous violation of layering! Send in the New Jersey Inquisition!! Or perhaps you misunderstand how it all works. Device files for Ethernet devices, /dev/ip*, and so on are like those for disk devices: you could allow anyone to read and write them, but in practice you probably wouldn't: you'd restrict access to the super-user and perhaps a special group to admit some sort of privilege reduction (like the group allowed to read disks on some systems, or to read /dev/kmem). That parts of the stack are assembled in user mode is a feature, not a bug. The one glaring flaw, as I said, is that no permissions are checked when pushing a stream line discipline onto a file. I think that happened because when Dennis first wrote the code, he was thinking about modules to implement canonical-tty semantics, or to invoke the very-different Datakit networking model. It's a fundamental flaw, though. I have had thoughts about fixing it, but never enough time nor enough motivation. (My technical mind is pretty much filled up by what I am paid to do these days; I haven't done much hobby computing in years.) Norman Wilson Toronto ON

8 years, 4 months

Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Josh Good: Which brings up a question I have: why didn't UNIX implement ethernet network interfaces as file names in the filesystem? Was that "novelty" a BDS development straying away from AT&T UNIX? ====== Remember that UNIX has long been a family of systems; it's risky to make blanket statements! The following is from memory; I haven't looked at this stuff for a while and am a few kilometers from my manuals as I type this. I can dig out the complete story later if anyone wants it; for now, this is just the flavour and the existence proof. Research UNIX, once it supported Ethernet at all, did so using devices in /dev; e.g. /dev/qe0[0-7] were the conventional names for the first DEQNA/DELQA device on a MicroVAX. There were eight subdevices per physical device, each a channel that might receive datagrams of a particular 16-bit type, programmed by an ioctl. To set up what we now call an IP interface, one did the following: a. Open an unused channel for the proper Ethernet physical device. (I think the devices were exclusive- open to make this easier: open /dev/qe00, then qe01, and so on until one succeeds.) b. Issue the ioctl to set the desired datagram type, usually 0x800. c. Push the IP stream line discipline onto the open file. d. Issue an ioctl to inform that IP instance of its address and netmask. Now datagrams of the specified type arriving on that device are fed to the IP subsystem, and the IP subsystem uses the IP address and mask and possibly other information to decide which datagrams to route to that IP instance, which sends them out that physical device. I forget how ARP and Ethernet encapsulation fit in. I know that they were someone more naive early on, and that in the 10/e systems I can now admit I have running at home I made things a bit smarter and less brittle. But that's the basic architecture. So how does one actually make, say, a TCP connection? Another layer of the same sort: There are devices /dev/ipX, served by an IP device driver that is part of the IP subsystem. Originally minor device X was hard-connected to IP protocol X; I later changed that to be ioctl-configured as well. To make TCP usable: a. Open /dev/ip6 (old school), or find an unused /dev/ipX (again they are exclusive-open) and configure it to accept protocol 6. b. Push the TCP stream line discipline onto the open file. c. There are probably things one could then configure, but I don't remember them offhand. To make a TCP call, open an unused /dev/tcpNN device; write something to it (or maybe it was an ioctl) with the desired destination address; wait for an error or success. On success, writes to the file descriptor send to the network, encapsulated as a TCP stream; reads receive. To receive a TCP call, open an unused /dev/tcpNN device, and write something (or ioctl) to say `I want to listen on this local port.' Then read the file. When a call arrives, you will read a message saying who's calling, and what /dev/tcpXX device you should open to accept the call. Notice the general scheme: for both TCP and IP (and there was a primitive UDP at one point, but it has fallen out of use on my systems), the protocol implementation comprises: 1. A line discipline: push it onto devices that will transport your data. 2. A device driver: use those devices to send and receive calls. The two are inextricably coupled inside the operating system, of course. There are all sorts of unfortunate details surrounding communications; e.g. the TCP code knows it is talking to IP, and constructs datagrams with partly-filled-in IP headers. (It is not clear one can do better than that in practice, because the protocols themselves really are linked, but I still think it's unfortunate.) On the other hand, that the junctions between plumbing are accessible makes some things very simple. I wrote a PPP implementation in user mode, with no kernel changes: to plug itself into IP, it just pushed the IP line discipline onto one end of a pipe, and read and wrote datagrams on the other. I later extended it to PPPoE by having it open an Ethernet device set to the proper datagram types (there is one for data and another for connection setup). On the other other hand, there are no permissions on stream line disciplines, so an untrustworthy person (if I allowed such on my systems) could push the IP line discipline onto his own pipe and send whatever datagrams he liked. This is decidedly a flaw. Those familiar with the original stream-system implementation have already spotted a lesser flaw: the file descriptor with IP pushed on (or TCP, or whatever) must remain open; when it is closed, everything shuts down. In practice it is usually useful to have a daemon listening to that file anyway; that's a good way for the system to report errors or confusion. In practice, TCP incalls and outcalls all went through a special daemon anyway, so that programs didn't have to be full of TCP-specific crap; that's what Dave Presotto's `connection server' is all about. Norman Wilson Toronto ON

8 years, 4 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by Jason Stevens

Thanks for the hints, and whatnot... I got v8 running! > ---------- > From: Tim Newsham > Sent: Wednesday, March 29, 2017 7:50 AM > To: David du Colombier > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] 8th Edition Research Unix on SIMH > > Would be great if someone scripted it up to make it dog-simple. > Here's how I did it for v6: http://www.thenewsh.com/~newsham/myv6/README > (I should do this, but I'm not sure I'll have time in the near future). > > On Tue, Mar 28, 2017 at 8:58 AM, David du Colombier < 0intro(a)gmail.com> > wrote: > > > Here are my notes to run 8th Edition Research Unix on SIMH. > > http://9legacy.org/9legacy/doc/simh/v8 > > These notes are quite raw and unpolished, but should be > sufficient to get Unix running on SIMH. > > Fell free to use, improve and share. > > -- > David du Colombier > > > > > > -- > > Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | > thenewsh.blogspot.com >

8 years, 4 months

Searching for 9th Edition Research Unix mail / Mail / mailx

by Steffen Nurpmeso

I am maintaining a BSD Mail derivative and one goal of the project is to have the complete history of Unix mail and BSD Mail in the repository. There yet exists a [timeline] branch, which has been fed with data from TUHS (thank you!) and CSRG; but it is coarse and further linear history and so the new V8 and V10 cannot be inserted, i will need to add new [unix-mail] and [bsd-Mail] (and maybe [bsd-csrg] with all commits preserved, like Spinellis did so in the Unix-history repository). Thanks to TUHS the former can be almost completed, except that there is no trace of 9th Edition mail. It would be fantastic if finally this project could provide the complete history of Unix mail. I would be thankful for informations where to get a copy of 9th Edition mail. Thank you. P.S.: apologizing for capturing the other thread with such a coarse message. --steffen

8 years, 4 months

Release of 8th, 9th and 10th Editions Unix

by Warren Toomey

All, today after some heroic efforts by numerous people over many years, Nokia-Alcatel has issued this statement at https://media-bell-labs-com.s3.amazonaws.com/pages/20170327_1602/statement%… Statement Regarding Research Unix Editions 8, 9, and 10 Alcatel-Lucent USA Inc. (“ALU-USA”), on behalf of itself and Nokia Bell Laboratories agrees, to the extent of its ability to do so, that it will not assert its copyright rights with respect to any non-commercial copying, distribution, performance, display or creation of derivative works of Research Unix®1 Editions 8, 9, and 10. The foregoing does not (i) transfer ownership of, or relinquish any, intellectual property rights (including patent rights) of Nokia Corporation, ALU-USA or any of their affiliates, (ii) grant a license to any patent, patent application, or trademark of Nokia Corporation, ALU-USA. or any of their affiliates, (iii) grant any third-party rights or licenses, or (iv) grant any rights for commercial purposes. Neither ALU-USA. nor Nokia Bell Laboratories will furnish or provided support for Research Unix Editions 8, 9, and 10, and make no warranties or representations hereunder, including but not limited to any warranty or representation that Research Unix Editions 8, 9, and 10 does not infringe any third party intellectual property rights or that Research Unix Editions 8, 9, and 10 is fit for any particular purpose. There are some issues around the copyright of third party material in 8th, 9th and 10th Editions Unix, but I'm going to bite the bullet and make them available in the Unix Archive. I'll post details later today. Cheers, Warren

8 years, 4 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by jnc＠mercury.lcs.mit.edu

> From: Tim Newsham > Would be great if someone scripted it up to make it dog-simple. But if people just have to press a button (basically), they won't learn anything. I guess I'm not understanding the point of the exercise? To say they have V6 running? So what? All they did was press a button. If it's to experience a retro-computing environment, well, a person who's never used one of these older systems is going to be kind of lost - what are they going to do, type 'ls -ls' and look at the output? Not very illuminating. (On V6, without learning 'ed', they can't even type in a small C program, and compile and run it.) Sorry, I don't mean to be cranky, but I'm not understanding the point. Noel

8 years, 4 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by jnc＠mercury.lcs.mit.edu

> From: Grant Taylor > However, I've had to teach enough people to know that they need a way to > boot strap themselves into an environment to start learning. Right, but wouldn't they learn more from a clear and concise hand-holding which explains what they are doing and why - 'do this which does that to get this'? There is no more a royal road to knowing a system, than there is to mathematics. > I do consider what (I believe) Warren put together for the UUCP project > to be a very good start. Simple how to style directions that are easy > to follow that yield a functional system. Exactly.... Noel

8 years, 4 months

Re: [TUHS] Happy birthday, PDP-8!

by Johnny Billquist

On 2017-03-28 09:37, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > > From: Johnny Billquist > > > the PDP-11 have the means of doing this as well.... If anyone ever > > wondered about the strangeness of the JSR instruction of the PDP-11, it > > is precisely because of this. > > ... > > I doubt Unix ever used this, but maybe someone know of some obscure > > inner kernel code that do. :-) > > Actually Unix does use JSR with a non-PC register to hold the return address > very extensively; but it also uses the 'saved PC points to the argument' > technique; although only in a limited way. (Well, there may have been some > user-mode commands that were not in C that used it, I don't know about that.) > > First, the 'PC points to arguments': the device interrrupts use that. All > device interrupt vectors point to code that looks like: > > jsr r0, _call > _iservice > > where iservice() is the interrupt service routine. call: is a common > assembler-language routine that calls iservice(); the return from there goes > to later down in call:, which does the return from interrupt. Ah. Thanks for that. I hadn't dug into those parts, but that's the kind of place where I might have suspected it might have been, if anywhere. > Use of a non-PC return address register is used in every C routine; to save > space, there is only one copy of the linkage code that sets up the stack > frame; PDP-11 C, by convention, uses R5 for the frame pointer. So that common > code (csv) is called with a: > > jsr r5, csv > > which saves the old FP on the stack; CSV does the rest of the work, and jumps > back to the calling routine, at the address in R5 when csv: is entered. (There's > a similar routine, cret:, to discard the frame, but it's 'called' with a plain > jmp.) Hah! Thinking about it, I actually knew that calling style, but didn't reflect on it, as you're not passing any arguments in the instruction stream in that situation. But it's indeed not using the PC as the register in the call, so I guess it should count in some way. :-) Johnny

8 years, 4 months

Re: [TUHS] 'Command subcommand ...' history

by Doug McIlroy

In some sense the "command subcommand" syntax dates from ar in v1, though option flags were catenated with the mandatory subcommand. The revolutionary notion that flags/subcommands might be denoted by more than one letter originated at PWB (in "find", IIRC). Doug

8 years, 4 months

Eigth Edition UNIX Status

by Cory Smelosky

Closer... : hp(0,0)nunix 136484+52868+370724 start 0xf48 Unix 8th Edition Fri Mar 26 17:47:30 GMT 1976 real mem = 8322048 nbuf = 254 nswbuf = 126 avail mem = 6350848 mcr0 at tr1 mcr1 at tr2 uba0 at tr3 dz0 at uba0 csr 160100 vec 0300 ipl x15 dz1 at uba0 csr 160110 vec 0310 ipl x15 dz2 at uba0 csr 160120 vec 0320 ipl x15 dz3 at uba0 csr 160130 vec 0330 ipl x15 mba0 at tr8 hp0 at mba0 drive 0 hp1 at mba0 drive 1 mba1 at tr9 ht0 at mba1 drive 0 tu0 at ht0 slave 0 It's booted...;) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

8 years, 4 months

Re: [TUHS] Happy birthday, PDP-8!

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > the PDP-11 have the means of doing this as well.... If anyone ever > wondered about the strangeness of the JSR instruction of the PDP-11, it > is precisely because of this. > ... > I doubt Unix ever used this, but maybe someone know of some obscure > inner kernel code that do. :-) Actually Unix does use JSR with a non-PC register to hold the return address very extensively; but it also uses the 'saved PC points to the argument' technique; although only in a limited way. (Well, there may have been some user-mode commands that were not in C that used it, I don't know about that.) First, the 'PC points to arguments': the device interrrupts use that. All device interrupt vectors point to code that looks like: jsr r0, _call _iservice where iservice() is the interrupt service routine. call: is a common assembler-language routine that calls iservice(); the return from there goes to later down in call:, which does the return from interrupt. Use of a non-PC return address register is used in every C routine; to save space, there is only one copy of the linkage code that sets up the stack frame; PDP-11 C, by convention, uses R5 for the frame pointer. So that common code (csv) is called with a: jsr r5, csv which saves the old FP on the stack; CSV does the rest of the work, and jumps back to the calling routine, at the address in R5 when csv: is entered. (There's a similar routine, cret:, to discard the frame, but it's 'called' with a plain jmp.) Noel

8 years, 4 months

'Command subcommand ...' history

by Tim Bradshaw

Lots of tools now seem to use this strategy: there's some kind of wrapper which has its own set of commands (which in turn might have further subcommands). So for instance git remote add ... is a two layer thing. Without getting into an argument about whether that's a reasonable or ideologically-correct approach, I was wondering what the early examples of this kind of wrapper-command approach were. I think the first time I noticed it was CVS, which made you say `cvs co ...` where RCS & SCCS had a bunch of individual commands (actually: did SCCS?). But I think it's possible to argue that ifconfig was an earlier example of the same thing. I was thinking about dd as well, but I don't think that's the same: they're really options not commands I think. Relatedly, does this style originate on some other OS? --tim (I realise that in the case of many of these things, particularly git, the wrapper is just dispatching to other tools that do the werk: it's the command style I'm interested in not how it's implemented.)

8 years, 4 months

Re: [TUHS] Happy birthday, PDP-8!

by Johnny Billquist

On 2017-03-27 04:00, Greg 'groggy' Lehey <grog(a)lemis.com> wrote: > On Monday, 27 March 2017 at 6:49:30 +1100, Dave Horsfall wrote: >> And as for subroutine calls on the -8, let's not go there... As I dimly >> recall, it planted the return address into the first word of the called >> routine and jumped to the second instruction; to return, you did an >> indirect jump to the first word. Recursion? What was that? > This was fairly typical of the day. I've used other machines (UNIVAC, > Control Data) that did the same. Later models added a second call > method that stored the return address in a register instead, only > marginally easier for recursion. > > At Uni I was given a relatively simple task to do in PDP-8 assembler: > a triple precision routine (36 bits!) to clip a value to ensure it > stayed between two limits. Simple, eh? Not on the PDP-8. Three > parameters, each three words long. only one register, no index > registers. I didn't finish it. Revisiting now, I still don't know > how to do it elegantly. How *did* the PDP-8 pass parameters? This is probably extremely off-topic, so I'll keep it short. This is actually very simple and straight forward on a PDP-8, but it might seem strange to people used to todays computers. Essentially, you pass parameters in memory, as a part of the code stream. Also, the PDP-8 certainly do have index registers. The first thing one must do is stop thinking of the AC as a register. The accumulator is the accumulator. Memory is registers. Some memory locations autoincrement when used indirectly, they are called index registers. That said, then. A simple example of a routine passing two parameters (well, three): First the calling: CLA TAD (42 / Setup AC with the value 42. JMS COUNT BUFPTR BUFSIZ . / Next instruction executed, with AC holding number of matching words in buffer. . Now, this routine is expected to count the number of occurances of a specific word in a memory buffer with a specific size. At calling, AC will contain the word to search for, while the address following the JMS holds the address, and the following address holds the size. The routine: COUNT, 0 CIA DCA CHR / Save the negative of the word to search for. CMA TAD I COUNT DCA PTR / Setup pointer to the address before the buffer. ISZ COUNT / Point to next argument. TAD I COUNT CIA DCA CNT / Save negative value of size. DCA RESULT / Clear out result counter. LOOP, TAD I PTR / Get next word in buffer. TAD CHR / Compare to searched for word. SNA / Skip if they are not equal. ISZ RESULT / Equal. Increment result counter. ISZ CNT / Increment loop counter. JMP LOOP / Repeat unless end of buffer. CLA / All done. Get result. TAD RESULT JMP I COUNT / Done. PTR=10 CNT=20 CHR=21 RESULT=22 Addresses 10-17 are the index registers, so the TAD I PTR instruction will autoincrement the pointer everytime, and the increment happens before the defer, which is why the initial value should be one less than the buffer pointer. Hopefully this gives enough of an idea, but unless you know the PDP-8 well, you might be a little confused by the mnemonics. As you can see, the return address at the start is used for more than just doing a return. It's also your argument pointer. Johnny

8 years, 4 months

Re: [TUHS] > I really

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > As Erdos would say of a particularly elegant proof, "It comes from the > Book," i.e. had divine inspiration. Just to clarify, Erdos felt that a deity (whom he referred to as the 'Supreme Facist') was unlikly to exist; his use of such concepts was just a figure of speech. 'The Book' was sort of a Platonic Ideal. Nice concept, though! Noel

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