TUHS

tuhs@tuhs.org

6532 discussions

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 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