TUHS

tuhs@tuhs.org

37 participants
6478 discussions

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