In the V1 filesystem, there are a few files are owned by users which are
not in the /etc/passwd or /etc/uids files:
xrwr- 6 2860 169 Mar 7 12:23 /bin/cal
xrwr- 4 7154 61 Jul 21 12:42 /bin/roff
-rwr- 28 304 448 Jun 30 20:31 /usr/lib/fr0.o
-rwr- 28 12222 449 Jun 30 20:37 /usr/lib/filib.a
-rwr- 28 9158 419 Jun 30 20:46 /usr/lib/libf.a
xrwr- 28 3462 491 Jul 1 16:35 /usr/fort/fc1
xrwr- 28 3238 498 Jul 1 16:35 /usr/fort/fc2
xrwr- 28 6840 505 Jul 1 16:35 /usr/fort/fc3
xrwr- 28 4918 519 Jul 1 16:35 /usr/fort/fc4
Now, I know that ken worked on the Fortran compiler, Joe Ossanna (jfo)
wrote roff, and in V6 & V7, ken had uid 6 and dmr had uid 7. So I
propose the following:
- add ken == 6, dmr == 7, jfo == 4 to /etc/passwd and /etc/uids, as
new files in fs/new. Thus jfo will own /bin/roff and ken will own
/bin/cal
- modify the permissions file so that the Fortran files which are
uid 28 become uid 6 == ken.
Sound reasonable?
Cheers,
Warren
Now that we have the V1 and V2 binaries in the svn tree, I thought I would
try to use the V2 assembler to build the kernel, instead of the V7 one.
After a bit of experimentation, I got it to work. It means we can remove
our dependency on the V7 assembler.
I've committed tools/assemv2, the script to build with V2 as, and a patch
to redefine $mount and $gtty.
It probably means that we could rebuild the kernel while running V1; I
haven't tried this as yet.
Cheers,
Warren
I think it would be a good idea to import the V1 / and /usr filesystem from
the s2 tape into the subversion repository, so that we can write a tools/
script to build "known good" rf0.dsk and rk1.dsk disk images.
In my private tree I have 1root/ and 1usr/, but perhaps we should have
something like fs/root/ and fs/usr. They need to be split so that my
mkfs tool can build separate disk images.
Comments?
Warren
# bas
i=25
print i
2.50000000e1
for i = 1 10 print i next
1.00000000e0
2.00000000e0
3.00000000e0
4.00000000e0
5.00000000e0
6.00000000e0
7.00000000e0
8.00000000e0
9.00000000e0
1.00000000e1
So, that's asm, C, fortran, basic, and shell: 5 languages.
I'm sure we could get ed and roff to perform as turing machines, but
I will leave that as an exercise for the reader :-)
Warren
This is cool stuff. Just a few weeks after thinking "this would be
cool if we could rebuild a working early Unix from the printed source
code" you've done just that. While it seems pretty primitive, it's
certainly recognizable as a Unix already and LIGHTYEARS ahead of
anything else I've played with from that era (DOS-11 and RT-11)
Still no great progress. I can confirm that "cc" and "cvopt" both work, but
the two compiler passes "c1" and "c2" don't work. Sometimes I can get them
to core, but with different arguments the system locks up.
On http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html, Dennis notes this:
A second, less noticeable, but astonishing peculiarity is
the space allocation: temporary storage is allocated that
deliberately overwrites the beginning of the program,
smashing its initialization code to save space. The two
compilers differ in the details in how they cope with this.
In the earlier one, the start is found by naming a function;
in the later, the start is simply taken to be 0. This
indicates that the first compiler was written before we had
a machine with memory mapping, so the origin of the program
was not at location 0, whereas by the time of the second,
we had a PDP-11 that did provide mapping. (See the Unix
History paper). In one of the files (prestruct-c/c10.c) the
kludgery is especially evident.
It could be that this sort of memory operation is what is causing the
problem. Is there a way for simh to give an instruction trace beginning
at a certain address e.g. 040000, so I can watch c0's behaviour and see
where it goes off the rails?
Thanks,
Warren
I entered init.s and played around with it a little. I *think* it might
be working (I stepped through some of it) but it doesn't use the normal
tty in multi-user mode, so it's hard to tell without dc-11 support.
I guess it was lucky that we used the s2 init instead of the jun72
init, because it seems the s2 init does run getty on the main terminal
in multiuser mode.
The process for building it is:
$ tools/rebuild
$ tools/as sys1.s build/init.s
and you'll have a "b.out" in the current dir.
Is anyone planning on working on dc-11 support?
Tim Newsham
http://www.thenewsh.com/~newsham/
Now that we have 0407 kernel support, I'll have a go at getting one of the
early C compilers to work. Could I suggest that we make a src/ directory
in svn, which will hold any source code that produces V1/V2 executables?
I'll make a directory for the C compiler. We can also add in working fragments
from the s2 tape into a cmd/ directory. The layout echoes the V7 tree:
/usr/src
/usr/src/cmd/ # Single file sourcefiles
/usr/src/cmd/as/ # Assembler
/usr/src/cmd/c/ # C compiler
/usr/src/libc/ # C library
/usr/sys/sys/ # Kernel source
Which of course implies that we might need to rename rebuilt/ to sys/ :-)
Thanks,
Warren
