It's a bit off-topic but Warren OK'd it: I'm trying to tidy the absolute
dragon's hoard I call an office, so I'm looking to give away some books
I haven't touched in years. These are free for the taking for anybody
who wants to drive to SF and get them. I'd really prefer for somebody to
take them all at once, of course.
- DEC PDP11/70 Processor Handbook
- DEC VAX11 Architecture Handbook
- DEC PDP11 Peripherals and Interfacing Handbook
- DEC Introduction to Programming (PDP-8)
- Programming Languages: History and Fundamentals (Sammet)
- Computer Networks, 1st ed (Tanenbaum)
- Modern Operating Systems, 2nd ed (Tanenbaum)
- Operating Systems Design and Implementation, 1st ed (Tanenbaum)
- Advanced Programming in the UNIX Environment (Stevens)
- Computer Architecture and Organization, 2nd ed (Hayes)
- Compilers: Principles, Techniques, and Tools (Aho, Sethi, Ullman)
- The Undocumented PC, 2nd ed (van Gilluwe)
- Cybernetics (Wiener)
If you want these, please email me *off-list* to set it up.
John
> From: Ron Minnich
> Ed got tired of watching the bootstrap slowness
This may be a dumb question (in which case, my apologies), but which part of
booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a
'quick reboot'? (I'm having a bit of a hard time working it out.) I can think
of the following stages as potentially being 'slow':
1 - reading in the kernel image from disk
2 - sizing/clearing main memory
3 - loading running /etc/init
3A - creating all the 'loqin's
3B - starting all the daemons/etc with /etc/rc
(There's obviously a conflict between 2 and 3*; one can't avoid 3* if one
does 2.)
Which ones did he want to avoid?
Avoiding 3* puts some limitations on the system, obviously, because it means
one has to keep running processes around; the process table has to have the
same format (and be in the same location - or it has to be moved before the
new system is started). (Technically, I guess one would have to save the
inode and file tables, too; there isn't enough saved data in the kernel to
re-open files, plus there are file read/write ocation pointers, etc.)
One could sort of do 2 also, if one were prepared to 1) swap all processes
out to secondary storage before 'rebooting', and ii) saving the process table.
> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel"
> or was there something before?
Are you talking about for UNIX, or across all operating systems? I don't have
that broad a memory any more, to know - did TWENEX have something like that?
Noel
Apropos of the virtue of negative subscripts.
> by pointing into the middle of another data structure you've created a
data aliasing situation
Not if all references are relative to the offset pointer. The following
example is silly, but I recently used exactly this trick to simplify
calculations on a first-quadrant (x,y) grid by supplying "out-of-bounds"
zeroes at (x,-2), (x,-1) and (-1,y). It was much cleaner to access the
zeroes like ordinary elements than to provide special code to handle the
boundary conditions.
/* Fill an N-element array with Fibonacci numbers, f(i), where 0<=i<N.
The recursion accesses a zero "out of bounds" at i=-1 */
const int N = 100;
int base[N+1];
#define fib(i) base[(i)+1]
void fill() {
int i;
fib(0) = 1;
for(i=1; i<N; i++)
fib(i) = fib(i-2) + fib(i-1);
}
Doug
Hello all,
I know that this isn't strictly a "UNIX history" question, but as I am
working with historic UNIX and this list contains a great number of people
who were instrumental in its development, I figured it would be appropriate
to ask here. If there's a better place for these sorts of questions,
please let me know.
I'm trying to figure out how the array size limits are set in the 2.11BSD
pcc compiler. I've looked through quite a bit of documentation but I don't
see anything that describes this. In theory on a 16 bit system I would
think that the maximum array size would be 64K, but the actual limit that I
found through trial and error is (2^15)-1.
Declaring an array that is too large results in an error of "Constant
required", which is being produced by c01.c in conexp().
https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/ccom/c01.c
I did quite a bit of searching through the source but I was not able to
determine where this limit is being set. This is where my usual tools fall
apart. Normally since I have the source I would compile the program I want
with debugging turned on, and then do a backtrace so that I could see how
we got to conexp(). But as far as I can tell I can't get a backtrace,
since there is no option for debugging information in pcc; adb can only
tell me where a process stopped.
I would appreciate any enlightenment or pointers to other documentation.
Thanks in advance!
-Henry
Lyndon Nerenberg (VE7TFX/VE6BBM):
Oh come on Rob, you should know that for anyone over the age of 50,
the moment you see 'dd' your brain automatically switches to JCL
mode.
===
Rob doubtless got IBM out of his system back in the
late 1970s, when I think he was one of the authors
of a shell that brought the TSO experience to Unix.
Norman Wilson
Toronto ON
On Monday, September 16th, 2024 at 6:28 PM, Henry Bent <henry.r.bent(a)gmail.com> wrote:
> ...
> I also have v9 on a Sun in TME
> ...
>
> -Henry
>
V9 you say...does your setup happen to have the on-line manpages by any chance? I don't think a surviving copy is in the TUHS archive. V9 is a tad bit fragmentary in the archive at present from what I can tell, it may be worth seeing if anything you have fills in blanks.
- Matt G.
Rob Pike:
I don't remember whether late Research Unix [dd] had -if, but Plan 9
certainly did.
===
I don't have a live 10/e system at the moment, but I have
the 10/e source tree handy. Classic parody-IBM syntax
only.
Aside: I'm curious: does anyone else have 8/e, 9/e, or
10/e running these days?
Norman Wilson
Toronto ON
The florid syntax of IBM's DD was rivaled by that of GE's file utility. I
always wondered whether it was named FUTIL unwarily or with tongue in cheek.
Doug

> On 15 Sep 2024, at 20:21, Rik Farrow <rik(a)rikfarrow.com> wrote:
> 
> Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'...
Hangover from assembly mnemonics, perhaps.
J
—
John Dow <jmd(a)nelefa.org>
Written by a human.
