# 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
After e-mailing a reply about 6 times today and it going to the original
poster, instead of the mailing list where I wanted it to go, I have
decided to change the behaviour of the unix-jun72(a)tuhs.org list. Replies
will now go back to the list, not the poster.
It's an arbitrary decision; if you disklike it, let me know. If most
of you prefer it the other way, I'll switch it back!
Good night,
Warren
I reorganized the build process slightly. Hopefully this won't affect
anyone and everything will keep working as before. I basically
took the 'sed' hacks out of assemv7 and made the "rebuild" script do
the patching with proper patch files instead. There is now a patches
directory with all of the patches we are using and comments on what
they do and why.
Tim Newsham
http://www.thenewsh.com/~newsham/
All, my mkfs.c $Revision: 1.17 $, $Date: 2008/05/04 14:20:12 $ now produces
mountable filesystem images, and it's now checked into the svn repository.
The problem was that the size of a directory is not the size of the blocks
allocated to it, but is in fact the number of bytes of the in-use directory
entries. For example, / was being allocated 1 block == 512 bytes. But 512
is not its size (as it would be in later UNIXes); in fact if / has entries
41 sdrwr- 7 root 70 Jan 1 00:00:00 .
41 sdrwr- 7 root 70 Jan 1 00:00:00 ..
43 sdrwr- 2 root 570 Jan 1 00:00:00 bin
42 sdrwr- 2 root 250 Jan 1 00:00:00 dev
99 sdrwr- 2 root 100 Jan 1 00:00:00 etc
108 sdrwr- 2 root 70 Jan 1 00:00:00 tmp
114 sdrwr- 2 root 20 Jan 1 00:00:00 usr
then its size is 7 entries * 10 bytes each = 70 bytes.
Importantly, this also means that we can now make bootable root filesystems
without having to do a cold UNIX:
% tools/mkfs /usr/local/src/V1 rf0.dsk rf # Make the / disk
% tools/mkfs /usr/local/src/V1 rk0.dsk rk # Make the /usr disk, same stuff
% ./simh.cfg
PDP-11 simulator V3.7-3
./simh.cfg> #!tools/pdp11
Unknown command
Disabling CR
Disabling XQ
RF: buffering file in memory
TC0: 16b format, buffering file in memory
sim> g
:login: root
root
# /tmp/a.out
/dev/rk0# ls -l /usr/tmp
total 8
112 sxrwrw 1 root 156 Jan 1 00:00:00 a.out
110 sxrwrw 1 root 1664 Jan 1 00:00:00 etma
113 sxrwrw 1 root 6 Jan 1 00:00:00 hello
109 sxrwrw 1 root 26 Jan 1 00:00:00 ttmp
111 sxrwrw 1 root 142 Jan 1 00:00:00 utmp
# df
806+4602 # Number of free blocks on / and /usr
I added /usr/tmp/hello just to verify that I was getting files that
were not on the cold UNIX tape.
Cheers,
Warren
> > The controller is an RK11.
> > The disk drives are RK02, RK03, RK05.
> >
> > The RK02 is a 1.2MB drive (256B per sector).
> > The RK03 is a 2.4MB drive (512B per sector).
> > The RK05 is a 2.4MB drive (512B per sector).
>
> There was also a RK05F which used a fixed platter (in the same
> plastic enclosure as the removables if I remember correctly). That was
> double capacity, around 5MB.
Yes, the RK05J is the removable one, as described above. The RK05F is
the fixed version that doubles the density. However, to the system, it
appears as two separate drives, not as a single 5MB drive. I am not
sure how the data were interleaved between the two "logical drives"
which is important when scheduling seeks on the logical drives.
James Markevitch
