> From: Will Senn
> my now handy-dandy PDP11/40 processor handbook
That's good for the instruction set, but for the memory management hardware,
etc you'll really want one of the {/44, /45, /70, /73, etc} group, since only
those models support split I+D.
> the 18 bits holding the word 000407
You mean '16 bits', right? :-)
> This means that branches are to 9th, 10th, 11th and 7th words,
> respectively. It'll be a while before I really understand what the
> ramifications are.
Only the '407' is functional. (IIRC, in early UNIX versions, the OS didn't
strip the header on loading a new program into memory, so the 407 was actually
executed.) The others are just magic numbers, inspired by the '407' - the
code always starts at byte 020 in the file.
> Oh and by the way, jumping between octal and decimal is weird, but
> convenient once you get the hang of it - 512 is 1000, which is nifty
> and makes finding buffer boundaries in an octal dump easy :).
The _real_ reason octal is optimal for PDP-11 is that when looking at core,
most instructions are more easily understood in octal, because the PDP-11 has
8 registers (3 bits), and 3 bits worth of mode modifier, and the fields are
aligned to show up in octal.
I.e. in the double-op instruction '0awxyz', the 'a' octit gives the opcode,
'w' is the mode for the first operand, 'x' is the register for the first
operand, and 'y' and 'z' similarly for the second operand. So '12700' is
'MOV (PC)+, R0' - AKA 'MOV #bbb, R0', where 'bbb' is the contents of the word
after the '12700'.
Noel
> From: Will Senn <will.senn(a)gmail.com>
> The problem is this, when I attempt to execute the v6tar binary on the
> v6 system (it works in v7) it errors out:
> v6tar
> v6tar: too large
That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's causing the
ENOMEM.
Noel
> From: Will Senn
> Thanks for supplying the logic trail you followed as well!
"Use the source, Luke!" This is particularly true on V6, where it's assumed
that recourse to the source (which is always at hand - long before RMS and
'Free Software', mind) will be an early step.
> when you say dump the a.out header, how do you do that?
On vanilla V6? Hmm. On a system with 'more' (hint, hint ;-), I'd just do 'od
{file} | more', and stop it after the first page. Without 'more', I'd probably
send the 'od' output to a file, and use 'ed' to look at the first couple of
lines.
Back in the day, of course, on a (slow) printing terminal, one could have just
said 'od', and aborted it after the first couple of lines. These days, with
video terminals, 'more' is kind of really necessary. Grab the one off my V6
Unix site, it's V6-ready (should be a compile-and-go).
Noel
> From: Mark Longridge
> I've never been able to transfer any file larger than 64K to Unix V5 or
> V6.
Huh?
# hrd /windows/desktop/TheMachineStops.htm Mach.htm
Xfer complete: 155+38
# l Mach.htm
154 -rw-rw-r-- 1 root 78251 Oct 25 12:13 Mach.htm
#
'more' shows that the contents are all there, and fine. ('hrd' is a command
in my V6 under Ersatz11 that reads an arbitrary file off the host file
system. Guess I need to set the date on the system!)
V6 definitely supports fairly large files; see the code in bmap() in subr.c,
which shows that the basic structure on disk can describe files of 7*256
(1792) + 256*256 (65536) blocks, or 67328 blocks total (34MB).
(In reality, of course, a file can't reach that limit; first, a disk
partition in V6 is limited to 64K blocks, but from that one has to deduct
blocks for the ilist, etc; further, the argument to bmap() is an int, which
limits the 'block number in file' to 16 bits, and in fact the code returns an
error if the high bit in the 'block number in file' is set.)
> I also don't recall seeing any file on V5 or V6 larger than 65536
> bytes
I don't think there is one; the largest are just less than 64KB. I don't
think this is deliberate, other than in the sense that they didn't put any
huge files in the distro so it would fit on a couple of RK packs.
> dd if=/dev/mt0 of=cont.a bs=1 count=90212
> ..
> 24676+0 records in
> 24676+0 records out
> Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there
> definitely seems to be some 64K limit here
Probably 'count' is an 'int' in dd, i.e. limited to 16 bits. No longs in V6 C
(as distributed, although later versions of the C compiler for V6 do support
longs - see my 'bringing up Unix' pages).
Noel
> From: Noel Chiappa
> the most likely is that 'v6tar' is linked to be split I+D, and your V6
> emulation is on a machine that doesn't have split I+D (e.g. an 11/40)
Now that I think about it, the linked systems that are part of the V6 distro
tape are all linked to run on an 11/40. They will boot and run OK on a more
powerful machine (/45 or /70), but they will act like they are on a /40 -
i.e. no split I+D support/use (user or kernel). So to get split I+D support,
you need to build a new Unix binary, with m45.s instead of m40.s. If you
haven't done that, that's probably what the problem is.
Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
the kernel and user. For some reason that I can't recall, we actually
produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D, but
supported split I-D for the users.
I wish I could remember why we did this - it couldn't have been to save
memory (the machine didn't have a great deal on it when this was done -
although I have this vague memory that that was why we did it), because
running split I+D in the kernel does not, I think, use any more physical
memory (provided you don't fiddle with the parameters like the number of
buffers) than running non-split. Or maybe it does?
One possible reason was that the odd layout of memory with split I+D in the
kernel made debugging kernel code harder (we were doing a lot of kernel
hacking to support early networking work); another was that we were just being
conservative, didn't need to extra space in the kernel that I+D allowed, and
so didn't want to run it.
Noel
All, in the next few days I'm migrating minnie.tuhs.org from one VM to
another, so as to upgrade the OS and clean out the system. I think I've
got the mail subsystem up and running, but as usual there may be bugs.
I'll send out another message when the system is cut over. If things
don't seem to be right, e-mail me at:
wkt at tuhs.org, or
warren.toomey at tafe.qld.edu.au if the tuhs.org one fails.
Cheers all, Warren
On Tue, 8 Dec 2015, Brantley Coile wrote:
> We were indeed lucky that admiral hooper was with us. I know people who
> still cherish their "nano" seconds.
Ah yes, the 1ft piece of wire... Got a photo of it?
> By the way, she wouldn't have said she coined the term "debugging". That
> is at least as old as Thomas Edison. She said she was the first to a
> actually find a real bug!
For those who may be new around here:
https://en.wikipedia.org/wiki/Grace_Hopper#/media/File:H96566k.jpg
Yes, that is a real bug, found inside a real computer.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
All,
According to "Setting Up Unix - Seventh Edition", by Haley and Ritchie:
The best way to convert file systems from 6th edition (V6) to 7th
edition (V7) format is to use tar(1). However, a special version of tar
must be prepared to run on V6.
The document goes on to describe a reasonable method to make v6tar on v7
and copy the binary over to the v6 system. I successfully built the
v6tar binary, which will execute in the v7 environment. I then moved it
over to the v6 system and did a byte compare on the file using od to
dump the octal bytes and then comparing them to the v7 version. The
match was perfect.
The problem is this, when I attempt to execute the v6tar binary on the
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large
on the v7 system, it works:
v6tar
tar: usage tar -{txru}[cvfblm] [tapefile] [blocksize] file1 file2...
I don't think the binary is too large, is is only 18148 bytes.
ls -l v6tar
-rwxrwxrwx 1 root 18148 Oct 10 14:09 v6tar
Help. First, what does too large mean? Second, does this sound familiar
to anyone? etc.
Thanks,
Will
OK, slightly OT...
Rear Admiral Grace ("Amazing") Hopper PhD was given unto us in 1906. She
was famous for coining the term "debugging", whereby a moth was removed
from a relay contact in a *real* computer[*].
However, she must be condemned for giving us COBOL; yes, I know that vile
language, but I carefully leave it off my CV, as it seemed to be designed
for suits (Business Studies of course, but nothing technical) to spy upon
their programmers.
[*]
Defined, of course, where you could open a door and step inside it; I
actually did that once.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> It might not be so much a set of macros as just using a
> subset of raw groff.
Yes, there were no macros back then. If you format the
document using raw groff, the odds are that you will be
speaking the same roff that Dennis did.
> Doug having been there, might know/remember the actually lineage.
Aside from some fuzziness about who wrote what and in what
language, here's what happened:
To port Jerry Saltzer's Runoff (presumably written in MAD)
to Multics, either Dennis or Bob Morris or both together
reimplemented it (presumably in PL/I). To coexist with
Saltzer's version on CTSS, the new program needed a
distinct name, hence roff.
The early Multics PL/I compiler was far from a production
tool. Justifiably, the Bell Labs comp center didn't
support it. To get roff into general use at the Labs,
I undertook yet another implementation in BCPL. I added
functionality (number registers, three-part headings, etc)
and kept the new name. Molly Wagner added hyphenation.
Eventually, I added macros that were usable either as
commands or (when parameterless) embedded in text.
Almost as soon as Unix was up on the PDP-11 one of Ken, Dennis
or Ossanna reimplemented a pre-macro version of roff (presumably
in assembler or B). I'm quite sure roff never ran on the PDP-7.
Ossana had a grander plan and undertook nroff. When he learned
of the availability of the Graphic Systems CAT phototypesetter,
he promptly generalized nroff to handle it. Joe replaced the
CAT's paper tape reader with a direct wire to the computer.
It all worked swimmingly--nothing like the travails when the
CAT was replaced by the more capable Merganthaler Linotron.
An interesting question of priority is whether nroff or
BCPL roff was first to have a macro capability. Though
I don't remember for sure, the fact that BCPL roff unified
registers, macros, strings and diversions suggests that
I abstracted from nroff facilities.
Doug
