I went through all the errors on the code checked in so far and made
edits consistent (I hope :-) with the pdf.
I also added the missing KE11A addresses (memory mapped EAE).
The remaining errors seem to be only due to missing pages.
-brad
> Can you show me how you are running it? (and feel free to cc the list)
(I think its mentioned in an earlier post already). I copy the
files to my 7ed system (make a tar, put it on a tape image, and
attach it in simh, then tar x to get contents). Probably easier
if you're using apout and local filesystem... I'm using the following
script (in my tools but not checked in because I'm using nonstandard
conv2):
tools/rebuild
(cd rebuilt; gtar -O -cf ../u.tar u?.s)
./conv2 -o tape.tm u.tar
cp tape.tm ~/work/simh/unix-v7-4/run/
Anyway to assemble I run:
as - sys.s u0.s u1.s ux.s
btw, I noticed some unicode characters in the files you committed.
I havent' had a chance to spend time editing it yet.. The ocr
often uses unicode for things like "-".
> I think there is a binary format. I think I figured it out once and
> wrote something to turn an a.out into it. hmmm. I'll go digging.
a.out is so simple, it wouldnt be hard to reproduce if we had to.
> I checked in the missing pages from e3, e4 and e8. I have not tried
> to assemble them yet, however.
I noticed that. Thank you.
> -brad
Tim Newsham
http://www.thenewsh.com/~newsham/
> I can happily deal with the jsr pc,do type of jsr, but the ones
> involving r5 have me stumped, e.g.:
>
> jsr r5,questf; < nonexistent\n\0>; .even
I have encountered this type of construct a lot when doing disassemblers
over the years. My usual strategy for dealing with this is:
1. If it's quick and dirty and I am not running huge amounts of code,
then the disassembler allows the user to provide a list of "hints" to
it. The hints for this would describe the arguments to each subroutine.
For illustrative purposes, you might have a side file that contains
the following:
subr 002004 questf string
meaning that location 002004 is a subroutine names questf that expects
a null-terminated string as the argument. As an additional benefit,
you get a nice name for the subroutine that the disassembler can put
into the output.
And if a subroutine takes two 16-bit arguments, you might have:
subr 003436 mysub arg16 arg16
If the disassembler identifies each of the targets of the jsr
instructions, then you can usually do a quick look at the code to
see what it expects, then add to the side file, then re-run the
disassembler.
2. If you want to be less quick and dirty, you can have the disassembler
do a partial flow analysis of the code to figure out what is expected
for arguments. This is usually much more involved and you still often
need to add hints for cases where the '60s or '70s programmer did some
kind of "neat trick" when coding.
My philosophy on these is to use tools to get to the 95%+ level of
automation and provide hints to pick up the rest. Using strategy
number 1 above will probably get you a lot of success with a small
amount of coding in your disassembler.
James Markevitch
All, I've just created a mailing list for the people involved in the effort
to reconstruct the Unix kernel from the 1972 assembly listing. I thought
it would be good to keep the mundane details of the work separate from the
TUHS mailing list.
The new list is unix-jun72(a)tuhs.org
I've manually subscribed the e-mail addresses that seem to be interested
in the work. If you want to be removed from the new list, e-mail me. If
you want to subscribe to the list, you can go here to do that:
https://minnie.tuhs.org/mailman/listinfo/unix-jun72
Cheers,
Warren
Hi,
here is my 2p :
http://cyrillelefevre.free.fr/jun72/jun72.zip
which is an archive of automatically extracted tif images from the
original pdf file.
so, no need to print/scan any more...
Regards,
Cyrille Lefevre
--
mailto:Cyrille.Lefevre-lists@laposte.net
I am trying out apout using the "1972_stuff" binaries. When using
"as" to assemble "ux" (e10-01 through e10-02) it gives an error
"m 0024" (multiply-defined label) for the line:
mount: .=.+1024.
I assume this is because the assembler has predefined the "mount"
system call (I ran across this earlier when using my system call
table sys.s with ux with the v7 assembler).
We can work around this (ie. use the v7 assembler without the definition
for "mount"), but it worries me a little -- why does the listing
have such an obvious and large flaw? The symbol "mount" is used
in several places, so this isn't likely to be a small typo. I can't
think of a good explanation as to why this error would exist in the
listing other than possibly pointing to another assembler being used.
Tim Newsham
http://www.thenewsh.com/~newsham/
On Thu, Apr 24, 2008 at 10:53:30AM -0700, James A. Markevitch wrote:
> I have been referring to this as version "1.5" since the date is later
> than the first edition manual, but before the second edition manual.
> Does anyone know if it's truly V1 of the kernel, or something between
> V1 and V2?
The date on the first page of the memo (PDF) is September 1972. That puts
the memo after 2nd Edition (June 1972) and 3rd Edition (Feb 1973).
The s2 tape in the Unix Archive has binaries which are dated mainly in
1972, spread from January thru to December, so they should be
contemporaneous with the kernel in the PDF.
The 1st Edition manuals are on-line on Dennis Ritchie's web page at:
http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html
I have a photocopy of the 2nd Edition manuals from Norman Wilson; I will
scan them in as a bunch of tiffs. The 3rd Edition manuals are at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.t…
but they refer to the C version, so they may not be as useful here.
> Does anyone have utilities earlier than the "1972" stuff from TUHS?
No, the s1 and s2 tapes are the earliest machine readable files that
we have.
I'm assuming that some of you are keen to see it running. It's going to
take a lot of work, especially on the debugging side. The existing 1972
binaries are already executable using my Apout emulator, so that will
help in two ways: we can run the old assembler, and we can tell if a bug
was in a userland binary and not in the kernel.
If I get a chance, I should try to compare the 1e and 2e manuals, to
outline the kernel API differences, as this might help us to determine
which binaries we have that will run on the PDF kernel.
Cheers,
Warren
