> From: John Cowan <cowan(a)mercury.ccil.org>
> Well, provided the compiler is honest, contra [Ken].
A thought on this:
The C compiler actually produces assembler, which can be (fairly easily)
visually audited; yes, yes, I know about disassembly, but trust me, having
done some recently (the RL bootstrap(s)), disassembled code is a lot harder
to grok!
So, really, to find the Thompson hack, we'd have to edit the binaries of the
assembler!
For real grins, we could write a program to convert .s format assembler to
.mac syntax, run the results through Macro-11, and link it with the other
linker... :-)
Also, I found on what's going on here:
> What was wierd was that in the new one, the routine csv is one word
> shorter (and so is csv.o). So now I don't understand what made them the
> same sizes!? The new ones should have been one word shorter!? Still
> poking into this...
The C compiler is linked with the -n flag, which produces pure code. What
the linker documentation doesn't say (and I never realized this 'back in the
day') is that when this option is used, it rounds up the size of the text
segment to the nearest click (0100).
So, in c2 (which is what I was looking at), the last instruction is at
015446, _etext is at 015450, but if you look at the executable header, it
lists a text size of 015500 - i.e. 030 more bytes. And indeed there are 014
words of '0' in the executable file before the data starts.
And if you link c2 _without_ the -n flag, it shows 015450 in the header as
the text size.
So that's why the two versions of all the C compiler phases were the same
size (as files); it rounded up to the same place in both, hiding the one-word
difference in text size.
Noel
Erg! Discussion of file name length brought back some chilling memories
of very early Unix, when file names were at most 6 characters long.
Longer names were accepted but truncated at 6 characters. So you could
edit ABCDE.c, store it, read it and edit it again, but the file system
knew it as "ABCDE." So when you compiled the program, the compiler
produced ABCDE.o, which overwrote the source code!
> To boot up the root pack (I don't think I did this at any point; I've
> always mounted it as a subsidiary drive)
> ...
> The disk has a working RL bootstrap in block 0, it should boot OK.
So I recently had to reboot my machine, and I took the opportunity to try
this; it worked right off, booted 'unix' OK. (I didn't try any of the other
Unixes in the root directory.) I had only that pack mounted on DL0, nothing
else.
> So, just for grins, because I was curious (after your question), I did
> try recompiling the C compiler, to see what I'd get.
> What I got were three files (c0, c1 and c2) which were _the exact same
> size_ (down to the byte) as the binaries on the V6 Research distro, but
> had a number of differences when compared with 'cmp -l'. Odd!
> ...
> I'll take a gander tomorrow and try and work it out.
So, this turned out to be because I had replaced the csv.o in libc.a with a
new one, because the standard V6 one doesn't work with long returns (which
use R1 as well as R0, and the V6 cret bashed R1). I put the old csv.o back,
and re-linked them, and this time c? all turned out identical.
So the source in the distro really is the source for the running compiler on
it.
What was wierd was that in the new one, the routine csv is one word shorter
(and so is csv.o). So now I don't understand what made them the same sizes!?
The new ones should have been one word shorter!? Still poking into this...
I understand most of the differences between the versions of c? with the old
and new csv.o; in all the jumps to cret, the indirect word in the instruction
was off by two (because cret was one word lower because csv was one word
shorter); that, along with different contents in csv.o, created most of the
differences.
Why one word shorter? Because in csv:
tst -(sp) / creates a temporary on top of the stack
jmp (r0)
had been replaced with:
jsr pc,(r0)
(saving one instruction, and making it one word smaller).
Noel
The web page mentions files-11 which is ODS-1.
Technically (it is all coming back to me now):
FILES-11 is a family of file systems that started in RSX-11
(or perhaps before but that's the oldest instance I know).
ODS-1 is really FILES-11 ODS-1; ODS is `on-disk [something].'
RSX-11 used ODS-1. VMS used ODS-2. I'm not sure of all
the differences offhand, but they were substantial enough
that we ended up writing two different programs to fetch
files to UNIX from RSX and VMS volumes (we had the latter
to deal with too). Certainly the directory entries were
different between the two: ODS-1 used RADIX-50-encoded
file names with at most six characters plus an at-most-three-
character `extension' (a term which newbies sometimes
improperly import into UNIX as well); I forget the exact
filename rules in VMS, but filenames certainly could be
longer than six characters.
I've found the early-1980s programs I remembered. There
were two, getrsx.c and getvms.c; two programs, one for
each file-system format. They are surely full of ancient
sloppiness that won't compile or won't work right under
a modern C compiler, and they make assumptions about byte
order. I'll spend some time in the next few days going over
them and see if I can quickly get something workable.
A footnote as to their origin: in the world where we wrote
these programs, we had not only multiple systems, but
shared disk drives. The disk drives themselves were
dual-ported; the controllers we used could connect to
multiple hosts as well. Each system had its own dedicated
disk drives, but the UNIX systems could also see the drives
belonging to the RSX and VMS systems; hence the file-fetching
programs, since this was well before the sort of networking
we take for granted these days.
On the other hand, we had several UNIX systems which spoke
uucp to one another, and that was occasionally used for
large file transfers. To speed that up, I taught uucico
a new protocol, whereby control information still went over
a serial line, but data blocks were transferred over a
chunk of raw shared disk (with appropriate locks, of course).
It was a simpler world back then, but that made it a lot more fun.
Norman Wilson
Toronto ON
This is also an RSX pack (I think), but when I tried to boot it, it said
"THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't
know how to mount disks under RSX-11 I left it at that.
There exists somewhere a UNIX program that reads an ODS-1 file-system
image and produces directory listings and extracts named files.
I know it exists because it was written by a friend (and probably hacked
around a little by me) almost 35 years ago, when we both worked in a
place that had some UNIX and some RSX-11. That means `somewhere'
probably includes some place in my old files. I'll see if I can
dig it out, upgrade it to work cleanly with modern C (it's just possible
I have an ODS-1 file system image lying around somewher too), and
post it either somewhere on the web or just to the list.
Norman Wilson
Toronto ON
> From: Larry McVoy <lm(a)bitmover.com>
> have you gotten to a point where you can rebuild the world and install
> your newly built stuff?
Well, I haven't tried to do that (it's not something that I'm that interested
in), but it _should_ be possible, since the 'vanilla' V6 distribution does
include the source for pretty much everything (including the C compiler,
assembler, loader, etc).
(This does not include the stuff from the Shoppa disk, like the new C
compiler, where I don't have the source. [The PWB distribution, which
includes a C compiler from 1977, is probably pretty close. Looking into
the PWB stuff is one of my next projects; we have 17 different versions
of that stuff, and I'd like to see what the differences among them are,
and maybe create a 'canonical' PWB.]
Also, per the 'Improvements' page, I have source for the Standard I/O
Library, but I'm using the binary library from the Shoppa disk, which may or
may not correspond to that source.)
Noel
Found in:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/man.c
this minor gem:
execl("/bin/ssp", "ssp", 0);
execl("/usr/bin/ssp", "ssp", 0);
printf("Can't find ssp!\n");
execl("/bin/cat", "cat", 0);
printf("or cat - gott in himmel!\n");
exit(1);
Not as good as "hodie natus" (Google it if you don't know of it - it's a
classic), but mildly amusing.
Noel
> From: Gregg Levine <gregg.drwho8(a)gmail.com>
> By Shoppa disk do you mean, Shoppe disk
The root pack (linked to from my page):
http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6/unix_v…
It contains lots of V6 goodies - but not, alas, source for most of them. (E.g.
I had to disassemble the RL bootstrap(s) from it.)
> I've been trying to figure out how to attach them to the E11 one to
> bring the whole thing up.
The others are junk (see below). To boot up the root pack (I don't think I
did this at any point; I've always mounted it as a subsidiary drive) you'd
need to say:
mount dl0: unix_v6.rl02 /RL02
and then:
boot dl0:
The disk has a working RL bootstrap in block 0, it should boot OK. Then you
get to take your pick of which unix to boot! There are 7 to chose from:
77 -rwxrwxr-x 1 root 38598 Aug 22 1984 oldunix
77 -rwxrwxr-x 1 root 38504 Jul 19 1984 oldunix.25.7
77 -rwxrwxr-x 1 root 38568 Feb 20 1985 unix
74 -rwxrwxr-x 1 4 36956 Mar 9 1983 unix.jones
69 -rwxrwxr-x 1 root 34408 Aug 16 1983 unix.mlab
76 -rwxrwxr-x 1 4 38316 Sep 3 1982 unix.rxrl
68 -rwxrwxr-x 1 root 33958 Jun 6 1983 unix.tmp
and I have no idea how they all differ - or what each one expects to use for
a root device and swap device.
Looking at 'unix', it gives both rootdev and swapdev as '01000' (which is
probably the RL, I'm too lazy to grovel around in bdevsw and make sure). The
super block reports 19000 as the size of the file system, and sure enough,
swplo is reported as 045070 (19000), and nswap as 02710 (1480). So it's
probably set up to run and swap on RL/0.
> and any of the set of disks that are in the distributions portion of
> the site with his name on them?
All of the other disks in the V6 folder with his name on it:
http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6
are junk; here's a brief rundown on each one:
copy_num1_user.rl02:
user0_backup.rl02:
user_backup2.rl02:
All very similar to the 'unlabeled' disk (below) - lots of random user files
for biology stuff, little if anything of any use/interest.
There is a file which isn't listed in the README:
unlabeled.rl02:
It looks like another /user disk, full of random biology stuff; nothing
interesting except a copy of a nice-looking Kermit written in C (by someone
at Columbia, IIRC).
junk:
An RL01 pack (the others are all RL02's); it has a boot block with PDP-11
code in it; I mounted it on a simulator and booted it, and it says it's an
RSX-11M V3.2 disk.
user01.rl02:
This is also an RSX pack (I think), but when I tried to boot it, it said
"THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't
know how to mount disks under RSX-11 I left it at that.
scratch_disk_1123.rl02:
This does indeed seem to be something that was used for disk diagnostics: the
boot block contains gubble, including (in the first RL11 block) lots of words
with all ones, and a lot of 52525's.
Noel
>> From: Larry McVoy <lm(a)bitmover.com>
>> have you gotten to a point where you can rebuild the world and install
>> your newly built stuff?
> Well, I haven't tried to do that (it's not something that I'm that
> interested in), but it _should_ be possible, since the 'vanilla' V6
> distribution does include the source for pretty much everything
> (including the C compiler, assembler, loader, etc).
So, just for grins, because I was curious (after your question), I did try
recompiling the C compiler, to see what I'd get.
What I got were three files (c0, c1 and c2) which were _the exact same size_
(down to the byte) as the binaries on the V6 Research distro, but had a
number of differences when compared with 'cmp -l'. Odd!
I don't know what the differences result from (and it's too late now to dig
into why, I'm fading). I'll take a gander tomorrow and try and work it out.
Too bad the binaries in the Research distro have had their symbol tables
stripped! That would have made it much easier...
My guess is something like 'libraries in different order, so two library
routines are swapped around in the linked binary', or something like that
(given that the size is an exact match). But I'll need to dig a bit...
Noel
> OK, I have whipped up some material on how to bring V6 up under
> Ersatz-11. See here:
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/V6Unix.html
New location (although the old one still works):
http://www.chiappa.net/~jnc/tech/V6Unix.html
So it turns out there was a bogon on the old version of this page: it claimed
the Windoze version of 'tar' needed Unix system mods (which is incorrect, it
was the version for V6 which needed the mods - cut and paste error). Fixed now
(it's useful to have a Windoze 'tar' because some of the old TAR files in the
archive can't be read by modern tools), and a certain amount of new material
added to the page overall.
> There is more content/pages coming: the start of an 'advanced things
> you can do to improve your V6 Unix' page
I've upgraded that somewhat to a complete page (although I'll probably add
more at some point in the future, e.g. I have a version of 'ps' which shows
sleep channels symbolically, text slots as ordinals, etc but I need to tweak
it a bit before I bring it out). The page is here:
http://www.chiappa.net/~jnc/tech/ImprovingV6.html
now, although the main page links to it too.
And I have another page coming, e.g. a 'what to look out for when you're
porting stuff to and from V6' guide. Etc, etc.
Noel