TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I have cdb .. How do I exit it. %, CTRL-C, CTRL-D, CTRL-Z, Break, > CTRL-Break, and so on just result in a ? being displayed. CTL-D (EOF on input) works for me? Or maybe the version I have (it was a binary only that came off the Shoppa disks, IIRC) is slightly different from the one you have, and that only works in this version (which has a number of extensions). I don't think I ever found any other way to exit it. Although looking at the code, it seems like probably the only way is to generate a 'quit with core dump' interrupt - I forget what character that is in standard V6. Noel

9 years, 7 months

Missing Documents for use with the Unix Time-Sharing System, Sixth Edition

by Will Senn

All, The Unix Sixth edition programmer's manual and other documents for use with Unix time-sharing system are available online, in html and postscript form from Wolfgang Helbig's site: http://wwwlehre.dhbw-stuttgart.de/~helbig/os/v6/doc/index.html There are papers some missing from the "Documents for use with the Unix Time-Sharing System": RATFOR - A Preprocessor for Rational Fortran NROFF User's Manual A Manual for Tmg Compiler-writing Language On the Security of UNIX The M6 Macro Processor A System for Typesetting Mathematics DC - An Interactive Desk Calculator BC - An Arbitrary Precision Desk-Calculator Language The Portable C Library (on UNIX) UNIX Summary Some of these are more interesting to me than others, but I tend towards shiny objects, so there is no telling when they will be of critical interest in the future. I have done quite a bit of searching for the NROFF document and the portable C library document and while I have found related works, I haven't come across the originals for sixth edition. Do any of y'all know where any or all of these documents are archived in their original/reproduced form? Regards, Will

9 years, 7 months

Re: [TUHS] v6 debugging

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > How did folks debug assembly routines in Unix v6, back in the day? There are three different questions here, although you may not realize it: - How did folks debug assembly routines in user programs in Unix v6 - How did folks debug assembly routines in the kernel in Unix v6 - How did folks debug assembly routines in PDP-11 standalone code created with Unix v6 I did all three, and I used different methods for each. For user code, there was no source-level debugger, so debugging C programs and debugging code written in assembler were the same thing. I used 'adb' (which is, stricly speaking, slightly post-V6 - our system at MIT was actually sort of an early PWB clone), but V6 itself provides 'db' (and also, IIRC, 'cdb'); all three are very similar. For standalone code (in my case, a packet switch that ran on PDP-11's), I used a version of DDT that was linked in with the rest of the code. The original version was one in MACRO-11 which I inherited from Jim Mathis at SRI, but I eventually re-wrote it in portable C, and it was used on the 68K, uVax and 29K. For kernel assembler code... I can't remember what I did! Although I wrote a fair amount of it (I modified m45.s very extensively, to work with the Able ENABLE card), so I must have done _something_, but I have no idea what. In theory I could have linked DDT in with the kernel, but I don't think I ever did so? Recently I was debugging some kernel code (the splice() system call we were discussing here), and I debugged it using... printf()'s! It was written in C, but I don't really differentiate between debugging C code, and assembler. > 2. No map file created by ld. LD normally includes a symbol table in the output file, which 'nm' can dump. > 3. No debugger that I can find. See above. > My workarounds include using OD to view the generated machine code Use db/cdb/adb if you want to look at compiled code. Also, for 'cc', use the -S flag. Noel

9 years, 7 months

v6 debugging

by Will Senn

All, I'm finally returning to my study of v6 after digging a bit further into assembly language and "other" pdp-11 operating systems. I even managed to get hello, world working in assembly in v6 and interestingly enough, I actually see how it works... for the most part :). Mini-note here: http://decuser.blogspot.com/2016/01/hello-world-in-assembly-on-research.html My question for y'all today is as follows (asked previously with a much larger gap in understanding): How did folks debug assembly routines in Unix v6, back in the day? I realize that most folks didn't do assembly, but some did and I'm curious what their approach might have been. After having worked with RT-11 for a bit, I can see how I might develop using RT-11 and then "port" a program across, but that seems less than ideal. Here is my short list of missing features as I see them: 1. No listing file/cross reference list created by as. 2. No map file created by ld. 3. No debugger that I can find. 4. This is not a missing feature, but it deserves inclusion in the list, the command as has possibly the most terse error messages I have ever seen - B 12? Really? Thankfully, the awesome man command comes to the rescue with the list of error codes. My workarounds include using OD to view the generated machine code and adding mesg calls. Thoughts? Will

9 years, 7 months

Another book

by Warren Toomey

All, Don Libes and Sandy Ressler just donated a PDF of their book "Life with Unix" to the archive. It's at: http://minnie.tuhs.org/Archive/Documentation/Books/ I've also found PDF copies of a bunch of other books, so look through http://wiki.tuhs.org/doku.php?id=publications:books for links. Cheers, Warren

9 years, 7 months

PDF of "A Quarter Century of Unix"

by Warren Toomey

All, I asked Peter Salus if there is an electronic version of his great book "A Quarter Century of Unix". There isn't one, so I scanned my book in. Peter has given TUHS the right to distribute the scanned version. I've just added a link to the PDF of the scan here: http://wiki.tuhs.org/doku.php?id=publications:quarter_century_of_unix But, if you can, buy the paper version as well! Many thanks to Peter for his generosity. Cheers, Warren

9 years, 7 months

Missing pages in Berkeley_Unix_History.pdf

by markus schnalke

Hoi. Yesterday, I came across the file Berkeley_Unix_History.pdf on my disk. It contains scanned articles of UNIX Review January 1985, October 1985 and January 1986. Searching the web brought up this online location for the file: http://simson.net/ref/free_software/Berkeley_Unix_History.pdf I read the articles for the first time and had a great time doing so. Especially the ``Berkeley Underground'' article was pure fun! Here, have some impression: We modified the kernel to support asynchronous I/O, distri- buted files, security traces, "real- time" interrupts for subprocess multitasking, limited screen editing, and various new system calls. We wrote compilers, ass- emblers, linkers, disassemblers, database utilities, cryptographic utilities, tutorial help systems, games, and screen-oriented ver- sions of standard utilities. User friendly utilities for new users that avoided accidental file deletion, libraries to support common operations on data structures such as lists, strings, trees, sym- bol tables, and libraries to perform arbitrary precision arithmetic and symbolic mathematics were other contributions. We suggested im- provements to many system calls and to most utilities. We offered to fix the option flags so that the dif- ferent utilities were consistent with one another. To Us, nothing was sacred, and We saw a great deal in UNIX that could stand improvement. Much of what We implemented, or asked to be allowed to implement, is now a part of System V and 4.2 BSD; others of our innovations are still missing from all versions of UNIX. Despite these accom- plishments, it seemed that whenever We asked The Powers That Be to install Our software and make it available to the rest of the system's users, We were greeted with stony silence. Unfortunately, the scan is not complete as some pages are missing. For example, page 43 (the title page of the mentioned article) is among them. Does anyone know where to get the full articles? meillo

9 years, 7 months

Re: [TUHS] etymology of cron

by jnc＠mercury.lcs.mit.edu

> From: Ronald Natalie > a new GADS (Gateway Architecture and Data Structures) under Dave > Mills's leadership would form which I attended until they morphed it > into the IETF To give a bit more detail, GADS was not producing needed stuff as fast as was needed, so it was split into InArc and InEng, with Dave running InArc and Corrigan (initially, Gross later) in charge. Noel

9 years, 7 months

Re: [TUHS] etymology of cron

by David

It has been updated again: The origin of the name cron is from the Greek word for time, χρόνος (chronos).[2][3] (Ken Thompson, author of cron, has confirmed this in a private communication with Brian Kernighan.) So it would appear that if enough people bang on enough keyboards on the Wikipedia site, things can change. David

9 years, 7 months

More wiki work: free Unix licenses

by Warren Toomey

All, although I can't contribute to the actual history of Unix, I can at least document what happened "afterwards". Here's a piece about the journey to make free Unix source code licenses available: http://wiki.tuhs.org/doku.php?id=events:free_licenses Comments welcome. Cheers, Warren

9 years, 7 months

Re: [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

by Johnny Billquist

On 2016-01-06 01:54, Dave Horsfall <dave(a)horsfall.org> wrote: > On Mon, 4 Jan 2016, Ronald Natalie wrote: >> >Just never figured out how to make good use of the MARK instruction on >> >the PDP-11. > RSX-11 probably used it, though, as could've RSTS... Nope. Nothing in RSX uses it. As others said, probably nothing anywhere used it. And, as I pointed out, if you use MARK, then you cannot really use split I/D-space, since the stack (data) needs to be in instruction space. 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, 7 months

Re: [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

by Johnny Billquist

On 2016-01-05 18:43, Ronald Natalie<ron(a)ronnatalie.com> wrote: > > Just never figured out how to make good use of the MARK instruction on the PDP-11. Not surprising. As others noted, few ever did. And apparently none responding actually do either. It *is* a stupid instruction in many ways. And it's not for multiple returns either. It's an odd way of handling stack cleanup without a frame pointer. It's extremely bad, since it actually requires the stack to be in instruction space. And yes, you are expected to execute on the stack. The idea is that the caller pushes arguments on the stack, but the cleanup of the stack is implicitly done in the subroutine itself, and at the same time you get an argument pointer. Example: Calling: MOV R5,-(SP) ; Save old R5 MOV <argn>,-(SP) MOV <argn-1>,-(SP) . MOV <arg1>,-(SP) MOV #MARKN,-(SP) ; Where the N in MARK N is the number of arguments you just pushed. MOV SP,R5 JSR PC,SUB . . In the subroutine you then have the arguments available relative to R5. So that arg1 is available at 2(R5) for example. SUB: . . . RTS R5 There is a lot going on at this point. The trick is to note that the code does an RTS R5 to return. If people remember what happens at that point, PC gets loaded with R5, while R5 gets loaded with the PC that we actually would like to return to (since that's what is at the top of the stack). And R5 is pointing into the stack, at the MARK instruction, so execution continues with actually performing the MARK. MARK, in turn, will case SP <- PC + 2*N, thus restoring the stack pointer to point to the place where the original R5 was stored. Next, it does a PC <- R5, so that we now have the PC point to where we actually want to return. Next it does a R5 <- (SP)+, meaning we actually restored the original R5. And so we have cleaned up the stack, preserved R5, and returned to the caller again. Also notice that the subroutine could have pushed any amount of data on the stack before the return, and I suspect the idea was that the process would not have needed to clean that up either. However, that fails, since the RTS needs the return address at the top. But you can essentially solve that by pushing -2(R5) before returning. Ugly, isn't it? :-) Johnny

9 years, 7 months

Early Unix function calls: expensive?

by Warren Toomey

I just re-found a quote about Unix processes that I'd "lost". It's by Steve Johnson: Dennis Ritchie encouraged modularity by telling all and sundry that function calls were really, really cheap in C. Everybody started writing small functions and modularizing. Years later we found out that function calls were still expensive on the PDP-11, and VAX code was often spending 50% of its time in the CALLS instruction. Dennis had lied to us! But it was too late; we were all hooked... http://www.catb.org/esr/writings/taoup/html/modularitychapter.html Steve, can you recollect when you said this, was it just a quote for Eric's book or did it come from elsewhere? Does anybodu have a measure of the expense of function calls under Unix on either platform? Cheers, Warren

9 years, 7 months

Re: [TUHS] TUHS Digest, Vol 2, Issue 5

by David

The comments in the rp06 walking across the floor reminds me of a time when I was installing netnews at a very new company and as the data transferred from the tape (we didn’t have a modem yet, that was to happen in a week or so) to the disk the disk got into a walking state. I was standing with my foot against the front of the drive to keep it from moving when a friend walked into the machine room and asked what I was doing. I said ‘keeping it all together’ and he asked about my foot. I moved it, the disk walked out a small amount and I replace my foot. He laughed and walked away. About 15 or 20 minutes later it was all back to ‘normal’ and I never had another problem with it. David > On Jan 2, 2016, at 1:31 PM, tuhs-request(a)minnie.tuhs.org wrote: > > several > RP06 (200MB) removable disks (for a picture and description, see > > http://www.columbia.edu/cu/computinghistory/rp06.html

9 years, 7 months

Re: [TUHS] Early Unix function calls: expensive?

by norman＠oclsc.org

As late as 1990, every UNIX I knew of still used the expensive calls/ret instructions for subroutine calls. I vaguely remember a consensus (and I certainly shared the feeling) that in hindsight it would have been better to use jsb/rsb, but changing everything would have been so much work that nobody wanted to do it. 1990 was already past peak VAX in the UNIX world, so I can't imagine anyone bothering to make such a change to an existing system after then. Especially a system that already had many existing installations who would have to deal with the resulting compatibility problem. During the latter part of the 1990s, I was actively supporting a private UNIX system just for myself on a few MicroVAXes at home. One of the things I did was to write a VAX code generator for the then-current version of lcc (the one around which the book was written), so as to have an ISO-compatible compiler and convert all of /usr/src (not so big even in those days) to ISO. It was an interesting exercise and I learned a lot, but even then, I wasn't brave enough to adopt an incompatible subroutine-calling convention. Another big time waste in the original VAX UNIX was the system-call interface: arguments were left on the stack (where they had been put before calling the syscall stub routine in libc); the kernel then had to do a full-fledged copyin to get them. It occurred to me more than once to change the convention and have the syscall stubs copy the arguments into registers before executing the chmk (syscall) instruction. That instruction didn't touch the registers; the kernel saved them early in the chmk trap routine, in its own address space, so no copying or access checking would have been required to fetch their call-time contents. That would still have been a messy change to make, because I'd have to be sure every program had been relinked with the new-style libc before changing the kernel. (This was a system without shared libraries.) But on a personal system it would have been doable. I never did. It's possible that current UNIX-descended/cloned systems that have VAX ports, like Linux or Open/Free/NetBSD, have had a chance to start over and do better on subroutine calls and system calls. Does anyone know? Norman Wilson Toronto ON

9 years, 7 months

Re: [TUHS] Early Unix function calls: expensive?

by jnc＠mercury.lcs.mit.edu

> that's 28+13 = 41 memory cycles. > ... > purely in overhead (counting putting the args on the stack as overhead). Oh, I missed an instruction for de-stacking the arguments, which was typically something like 'add #N, sp', so another two instruction word fetches, or 43 cycles. Ironically, if N=4, the compiler used to emit a 'cmp (sp)+, (sp)+', which is more efficient space-wise (one word instead of two), but less time-wise (3 cycles instead of 2). Noel

9 years, 7 months

Re: [TUHS] Early Unix function calls: expensive?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > I just re-found a quote about Unix processes > .. > Years later we found out that function calls were still expensive > on the PDP-11 > .. > Does anybodu have a measure of the expense of function calls under Unix > on either platform? Procedure calls were not cheap on the PDP-11 with the V6/V6 C compiler (which admittedly was not the most efficient with small routines, since it always saved all three non-temporary registers, no matter whether the called routine used them or not). This was especially true when compared to the code produced by the compiler with the optimizer turned on, if the programmer was careful about allocating 'register' variables, which was pretty good. On most PDP-11's, the speed was basically linearly related to the number of memory references (both instruction fetch, and data), since most -11 CPU's were memory-bound for most instructions. So for that compiler, a subroutine call had a fair amount of overhead: inst data call 4 1 2 0 if any automatic variables 1 1 minimum per single-word argument csv 9 5 cret 9 5 (In V7, someone managed to bum one cycle out of csv, taking it down to 8+5.) So assume a pair of arguments which were not register variables (i.e. automatics, or in structures pointed to by register variables), and some automatics in the called routine, and that's 4+2 for the arguments, plus 6+1, a subtotal of 10+3; add in csv and cret, that's 28+13 = 41 memory cycles. On a typical machine like an 11/40 or 11/23, which had roughly 1 megacycle memory throughput, that meant 40 usec (on a 1 MIP machine) to do a procedure call, purely in overhead (counting putting the args on the stack as overhead). We found that, even with the limited memory on the -11, it made sense to run the time/space tradeoff the other way for short things like queue insertion/removal, and do them as macros. A routine had to be pretty lengthy before it was worth paying the overhead, in order to amortize the calling cost across a fair amount of work (although of course, getting access to another three register variables could make the compiled output for the routine somewhat shorter). Noel

9 years, 7 months

Re: [TUHS] Early Unix function calls: expensive?

by Clem Cole

Folks remember, VAX was not designed with UNIX in mind. It had two primary influences, assembly programmers (Cutler et al) and FORTRAN compiler writers. The truth is, the Vax was incredibly successful in both UNIX and its intended OS (VMS) sites, even if a number of the instructions it has were ignored by the C compiler writers. The fact the C did not map to it as well as it would for other architectures later is not surprising given the design constraints - C and UNIX were not part of the design. But it was good enough (actually pretty darned good for the time) and was very, very successful - I certainly stopped running a PDP11 when Vaxen were generally available. I would not stop doing that until the 68000 based workstations came along. >From my own experience, when Dave (Patterson) was writing the RISC papers in the early 1980s, a number of us ex-industry grad student types @ USB were taking his architecture course having just come off some very successful systems from the Vax, DG Eagle, Pr1me 750, etc.. [I'll leave the names of said parties off to protect the innocent]. But what I will say is that the four of used sit in the back of his calls and chuckle. We used to remind Dave that a lot of the choices that were made on those machines, we not for "CS" style reasons. IMO: Dave really did not "get it" -- all of those system designers did make architectural choices, but the drivers were the code base from the customer sites not how how well spell or grep worked. And those commercial systems generally did mapped well at what the designers considered and >>why<< those engineers considered what they did [years later a HBS professor Clay Christensen's book explained why]. I've said this in other forums, but I contend that when we used pure CS to design world's greatest pure computer architecture (Alpha) we ultimately failed in the market. The computer architecture was extremely successful and many of miss it. Hey, I now work for a company with one of the worst instruction sets/ISA from a Computer Science standpoint - INTEL*64 (C), and like the Vax, it's easy to throw darts at the architecture from a purity standpoint. Alpha was great, C and other languages map to it well, and the designers followed all of the CS knowledge at the time. But as a >>system<< it could not compete with the disruption caused by the 386 and later it's child, INTEL*64. And like Vaxen, INTEL*64 is ugly, but it continues to win because of the economics. At Intel we look at very specific codes and how they map and the choices of what new things to add, how the system morphs are directly defined by what we see from customers and in the case of scientific codes, how well the FORTRAN compiler can exploit it -- because it is the same places (the national labs and very large end users like weather, automotive, oil/gas or life sciences) that have the same Fortran code that still need to run ;-) This is just want DEC did years ago with the VAX (and Alpha). As an interesting footnote, the DNA from the old DEC Fortran compiler lives on "ifort" (and icc). Some of the same folks are still working on the code generator, although they are leaving us fairly rapidly as they approach and pass their 70s. But that's a different story ;-) So the question is not a particular calling sequence or set of instructions is good, you need to look at the entire economics of the system - which to me begs the question of if the smartphone/tablet and ARM be the disruptor to INTEL*64 - time will tell. Clem On Sun, Jan 3, 2016 at 7:42 PM, <scj(a)yaccman.com <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=scj@yaccman.com>> wrote: > Well, I certainly said this on several occasions, and the fact that it is > recorded more or less exactly as I remember saying it suggests that I may > have even written it somewhere, but if so, I don't recall where... > > As part of the PCC work, I wrote a technical report on how to design a C > calling sequence, but that was before the VAX. Early calling sequences > had both a stack pointer and a frame pointer, but for most machines it > was possible to get by with just one, so calling sequences got better as > time went on. Also, RISC machines with many more registers than the > PDP-11 also led to more efficient calls by putting some arguments in > registers. Later standardizations like varargs were painful on some > architectures (especially those which had different registers for pointers > and integers). > > The CALLS instruction was indeed a pig -- a space-time tradeoff in the > wrong direction! For languages like FORTRAN it might have been justified, > but for C it was awful. It is my memory too that CALLS was abandoned, > perhaps first at UCB. But I actually had little hands-on experience with > the VAX C compiler... > > Steve > > > > > > I just re-found a quote about Unix processes that I'd "lost". It's by > > Steve Johnson: > > > > Dennis Ritchie encouraged modularity by telling all and sundry that > > function calls were really, really cheap in C. Everybody started > > writing small functions and modularizing. Years later we found out > > that function calls were still expensive on the PDP-11, and VAX code > > was often spending 50% of its time in the CALLS instruction. Dennis > > had lied to us! But it was too late; we were all hooked... > > http://www.catb.org/esr/writings/taoup/html/modularitychapter.html > > > > Steve, can you recollect when you said this, was it just a quote for > > Eric's book or did it come from elsewhere? > > > > Does anybodu have a measure of the expense of function calls under Unix > > on either platform? > > > > Cheers, Warren > > > > >

9 years, 7 months

Re: [TUHS] Early Unix function calls: expensive?

by Johnny Billquist

On 2016-01-04 00:53, Tim Bradshaw <tfb(a)tfeb.org> wrote: >> >On 3 Jan 2016, at 23:35, Warren Toomey<wkt(a)tuhs.org> wrote: >> > >> >Does anybodu have a measure of the expense of function calls under Unix >> >on either platform? >> > > I don't have the reference to hand, but one of the things Lisp implementations (probably Franz Lisp in particular) did on the VAX was not to use CALLS: they could do this because they didn't need to interoperate with C except at known points (where they would use the C calling conventions). This change made a really significant difference to function call performance and meant that on call-heavy code Lisp was often very competitive with C. > > I can look up the reference (or, really, ask someone who remembers). > > The VAX architecture and its performance horrors must have killed DEC, I guess. I don't know if that is a really honest description of the VAX in general, nor DEC. DEC thrived in the age of the VAX. However, the CALLS/CALLG and RET instructions were really horrid for performance. Any clever programmer started using JSB and RSB instead. as they give you the plain straight forward call and return semantics without all the extra stuff that the CALL instructions give. But, for assembler programmers, the architecture was nice. For compilers, it's more difficult to do things optimal, and of course, it took quite a while before hardware designers had the tools, skill and knowledge how to implement complex instruction sets fast in hardware. But nowadays, that is definitely not a problem, and it was more or less already solved by the time of the NVAX chip as well, which was actually really fast compared to a lot of stuff when it came out. 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, 7 months

Re: [TUHS] Unix Circuit Design System [and FOSS]

by Nelson H. F. Beebe

Clem cole <clemc(a)ccc.com> writes on Thu, 31 Dec 2015 23:04:04 -0500 about SPICE: >> ... >> Anyway SPICE1 was actually started in the late 1960's by dop [Don >> Pederson]. Ellis Cohen wrote SPICE2 for the CDC 6400 in the mid 70's, >> added some new device models and created really novel bit of self >> modifying Fortran the compiled the inner loop. >> >> You are correct it was really the first widely available FOSS code - >> an idea that you correctly note dop created. >> ... SPICE wasn't the only such package, or even the earliest! Still, I'll be grateful to list readers for pointers off-list (or on) to early publications about SPICE that I can add to the bibliography archives. The EISPACK system, which predated LINPACK, and both of which led to the current LAPACK, and descendants like CLAPACK and ScaLAPACK, has an older vintage. It began with Algol routines published in the German/English journal Numerische Mathematik http://www.math.utah.edu/pub/tex/bib/nummath.bib http://www.math.utah.edu/pub/tex/bib/nummath2000.bib http://www.math.utah.edu/pub/tex/bib/nummath2010.bib [change .bib to .html for a similar view with live hyperlinks] The first such routine may have been that in entry Martin:1965:SDPa in nummath.bib, which appeared in Num. Math. 79(5) 355--361 (October 1965) doi:10.1007/BF01436248. That journal did not then record "received" dates, so the best that I can do for now is to claim "October 1965" as the start of published code for free and open source software in the area of numerical analysis. Publication of related algorithms continued for 6 years, and then they were collected in the famous HACLA (Handbook for Automatic Computation: Linear Algebra) volume in 1971 (ISBN 0-387-05414-6). Because Algol was little used in the USA, a project was begun in that country to translate the Algol code to Fortran. That project was called NATS, which originally stood for the groups at (read their names vertically) Northwestern University Argonne National Laboratory Texas, University of (at Austin) Stanford but as more groups joined in the effort, and EISPACK begat LINPACK, NATS was changed to mean National Activity to Test Software. The EISPACK book appeared in two editions in 1976 (ISBN 0-387-06710-8) and 1977 (0-387-08254-9), volumes 6 and 51, respectively of Springer's Lecture Notes in Computer Science (now around 9000 published volumes). The LINPACK book appeared in 1979 (ISBN 0-89871-172-X). The LAPACK book has three editions, in 1992 (ISBN 0-89871-294-7), 1995 (ISBN 0-89871-345-5), and 1999 (ISBN 0-89871-447-8). In between them, the ScaLAPACK book appeared in 1997 (ISBN 0-89871-400-1). There were several other packages described in the 1984 book Sources and Development of Mathematical Software ISBN 0-13-823501-5 (entry Cowell:1984:SDM), including FUNPACK, MINPACK, IMSL, SLATEC, Boeing, AT&T PORT, and NAG. Some are free, and others are commercial. The Algol code from Numerische Mathematik, like the ACM Collected Algorithms, the Applied Statistics algorithms, and the Transactions on Mathematical Software algorithms, was intended to be freely available to anyone for any purpose, and no license of any kind was claimed for it. That tradition continues with all of its descendants in the *PACK family. I have old archives of source code for EISPACK and LINPACK, but comment documentation in EISPACK does not include revision dates, just references to page numbers in the HACLA volume from 1971, and rarely, to journal articles from 1968, 1970 and 1973. My filesystem dates, alas, only reflect the copying from distribution tape to disk, and my oldest file date for EISPACK is 20-Apr-1981. The LINPACK comments appear be almost entirely without dates: I found only one: snrm2.for:11:C C.L.LAWSON, 1978 JAN 08 The bibliography on the GNU Project at http://www.math.utah.edu/pub/tex/bib/gnu.bib records most of the books mentioned above, and it also contains as its first entry, Galler:1960:LEC, a letter published in the April 1960 issue of Communications of the ACM from Bernie Galler, with this field: remark = "From the letter: ``\ldots{} it is clear that what is being charged for is the development of the program, and while I am particularly unhappy that it comes from a university, I believe it is damaging to the whole profession. There isn't a 704 installation that hasn't directly benefited from the free exchange of programs made possible by the distribution facilities of SHARE. If we start to sell our programs, this will set very undesirable precedents.''", That is so far the earliest reference that I have found for the notion that software should be free, long before Richard Stallman, Eric Raymond, Linus Torvalds, and others became such well-known proponents of that idea, and we had large and profitable companies like Red Hat and SUSE devoted to supporting, for a fee, such software. I was a graduate student in quantum chemistry at the Quantum Theory Project (QTP) at the University of Florida in Gainesville in the late 1960s and early 1970s, and we had a general practice of sharing of code among various university research groups, most notably through the Quantum Chemistry Program Exchange (QCPE) hosted at the University of Indiana in Bloomington, IN. A search through my bibliography archives found my earliest recording, a 6-Apr-1971 publication (by me), with mention of QCPE. Library searches found a catalog entry for QCPE Catalog volume 19 (1987), so perhaps volume 1 appeared in 1968. But no --- I just found in its home institution's library catalog http://www.iucat.iu.edu/?utf8=%E2%9C%93&search_field=all_fields&q=QCPE&high… an entry dated 1963, with details Publishing history: 1 (Apr. 1963)- Ceased with 71 (Nov. 1980). Other widely-distributed programs of that time included Enrico Clementi's IBM Research group's IBMOL (about 1965), and others named MOLECULE (pre-1975), POLYATOM (1963), and Gaussian (1970). The POLYATOM year appears to be the earliest of those: see the paper by Michael Barnett at http://dx.doi.org/10.1103/RevModPhys.35.571 It appears in a July 1963 journal issue, again without a "received" date. It begins: A system of programs is being written by Dr. Malcolm C. Harrison, Dr. Jules W. Moskowitz, Dr. Brian T. Sutcliffe, D. E. Ellis, and R. S. Pitzer, to perform nonempirical calculations for small molecules. I have met, or been in the same group as (Don Ellis), most of those, and it is worth noting their affiliations to emphasize the broad character of that work: Malcolm Courant Institute of Mathematical Sciences, New York University, NY Jules New York University, NY Brian York University, York, UK Don University of Florida (later, Northwestern University) Russ Harvard, Cambridge, MA (later, Ohio State University) Michael MIT, Cambridge, MA and various UK sites in academia and industry (see https://en.wikipedia.org/wiki/Michael_P._Barnett) On the subject of the Gaussian program, developed at Carnegie-Mellon University, see the two sites https://en.wikipedia.org/wiki/Gaussian_%28software%29 http://www.bannedbygaussian.org/ The second decries the loss of openness of Gaussian, which remains a widely-used commercial product. There is also a book on the subject of mathematics whose use is encumbered by patents and copyrights: Ben Klemens Ma$+$h you can't use: patents, copyright, and software ISBN 0-8157-4942-2 (entry Klemens:2006:MYC in http://www.math.utah.edu/pub/tex/bib/master.bib) ---------------------------------------- P.S. A final sad personal note on computing history: When our DEC-20/60 (Arpanet node UTAH-SCIENCE, later science.utah.edu and still later, math.utah.edu) was retired on 31-Oct-1990 (its predecessor, a DEC-20/40 began operating in March 1978) we were faced with several cabinets full of 9-track tapes (about 25MB each), several RP06 (200MB) removable disks (for a picture and description, see http://www.columbia.edu/cu/computinghistory/rp06.html ) and the contents of three washing-machine sized RP07 (600MB) disks, and were moving to a new machine room in an adjacent building. We were able to copy over the RP0[67] disk contents, and I still have them online on my desktop, but the tapes were financially infeasible for us to copy to disk on the new VAX 8600 server, and we were leaving 9-track tape technology behind. There were probably 500 to 1000 of those tapes, and all that we could do was fill a dumpster with them, because we had no place to store the physical volumes at the new site, and no money for their bits. I have deeply regretted that loss of 25 years of my, and our, early computing history ever since. Computers were for far too long crippled by too little memory and too little permanent storage, and only post-2000 has that situation been alleviated with radical reductions in storage costs per byte of data. My new desktop 8TB drive is 3.6 million times cheaper per byte than an RP06 drive was. Had we been able to foresee that dramatic growth in capacity, we could have archived those tapes in an off-campus warehouse for later (attempted) data retrieval. ------------------------------------------------------------------------ P.P.S. Besides VAX VMS, our migration path from TOPS-20 was primarily to Unix, first on the Wollongong distribution of BSD (3.x, I think) running on VAX 750 machines in the early 1980s, then on Sun 3 MC68000-based workstations in 1988 that ultimately evolved to an eclectic mixture of CPUs and vendors. My software test lab now has about 70 flavors of Unix on assorted physical and virtual machines, with ARM, MIPS, PowerPC, SPARC, x86, and x86-64 processors. Our last DEC Alpha CPU died with its power supply 16 months ago, and a colleague still has a runnable MC68020 box (an old NeXT desktop). ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

9 years, 7 months

Re: [TUHS] etymology of cron

by jnc＠mercury.lcs.mit.edu

> From: Jacob Goense <dugo(a)xs4all.nl> > Mills's 1983 RFC889[2] calls the original PING Packet InterNet Groper. I have a strong suspicion that Packet-etc is a 'backronym' from Dave Mills. Note that the use of the term "echo" for a packet returned dates back quite a while before that, see e.g. IEN 104, "Minutes of the Fault Isolation Meeting", from March 1979: "ability to echo packets off any gateway" When ICMP was split from GGP (see IEN-109, RFC-777), the functionality migrated from GGP to ICMP, and was generalized so that all hosts provided the capability, not just routers. Noel

9 years, 7 months

Re: [TUHS] etymology of cron

by Norman Wilson

Personally, I lean away from listing the nine billion debunked names of cron. It's like adding a disclaimer to cat(1) to explain that cat just copies data to standard output, it doesn't transform it or compute how long it would take to send the data over UUCP. But it probably shows that I have been trying to write a couple of manual pages lately (for some personal stuff, plus some docs for work that are not technically manual pages but deserve the same sort of conciseness). Maybe Wikipedia-page format should admit an optional BUGS section. Norman Wilson Toronto ON PS: seriously, though I wouldn't bother including the debunking text myself, save perhaps on the Talk page to encourage editors to delete any future attempts to revive the un-names, I have no problem with Grog doing it. More power to him if he has the energy!

9 years, 7 months

Unix Circuit Design System

by Michele Ghisolfo

Hello all! While I was reading the article "A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual" from Douglas McIlroy, I learnt of a set of utilities for designing electronic circuits. Here is a brief quote of this article: "CDL (v7 pages 60-63) Although most users do not encounter the UNIX Circuit Design System, it has long stood as an important application in the lab. Originated by Sandy Fraser and extended by Steve Bourne, Joe Condon, and Andrew Hume, UCDS handles circuits expressed in a common design language, cdl. It includes programs to create descriptions using interactive graphics, to lay out boards automatically, to check circuits for consistency, to guide wire-wrap machines, to specify combinational circuits and optimize them for programmed logic arrays (Chesson and Thompson). Without UCDS, significant inventions like Datakit, the 5620 Blit terminal, or the Belle chess machine would never have been built. UCDS appeared in only one manual, v7." I looked it up on the 7th Edition's Manual and I haven't found references of this system. I also searched a v7 system image downloaded from TUHS and got no results. However I got some references of this system in USENET archives. In particular, two hierarchies, net.draw and after net.ucds were dedicated to it. Apparently two of the binaries of the system were called "draw" and "wrap". I also found a manual of a similar system which I suppose is the UCDS descendant in the 1st Edition of Plan 9. This is the link of the document: http://doc.cat-v.org/plan_9/1st_edition/cda/ However that edition of Plan 9 is not publicly released and I could not find it in following editions. But since v7 Unix is available, I hope it may be possible to get hold of an older release at least. Does anyone have any information? Thank you in advance! --- Michele

9 years, 7 months

Old newsletters

by Warren Toomey

I was going through the old AUUG newsletters at http://www.tuhs.org/Archive/Documentation/AUUGN/ looking for wiki material. They are a mine of information! I've sent an e-mail off to the UKUUG folk to see if they have any on-line newsletters. Does anybody know what happened to EUUG, especialy if any of their newsletters have been digitised? And Usenix ;login, are any of their old newsletters available? If not, who can I lobby to get this done? There's only 3 1/2 years left before the 50th anniversary! Cheers, Warren

9 years, 7 months

Re: [TUHS] v6 RK05 bootloader question

by jnc＠mercury.lcs.mit.edu

> From: Wolfgang Helbig > The HALT instruction of the real PDP11 only stops the CPU I have this bit set that on at least some models of the real machine, when the CPU is halted, it does not do DMA grants? If so, on such machines, the trick of depositing in the device registers directly would not work; the device could not do the bus cycles to do the transfer to memory. Anyone know for sure which models do service DMA requests while halted? Noel

9 years, 7 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