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