The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-19 13:27 Noel Chiappa
  0 siblings, 0 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-19 13:27 UTC (permalink / raw)


So, speaking of system calls that are missing in earlier versions of Unix,
that tickled a memory:

    > From: Will Senn

    > ... 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.

When I got tar running on my V6, I didn't know about this, and I took
a V7 tar and got it running myself, see here:

  http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html#tar
  
One thing I found out while doing that is that tar uses the 'utime' system
call on V7 to set the file date, but i) V6 doesn't have utime() (although it
has smdate(), albeit commented out in the standard distro), and ii) on now
looking in src/cmd/tar and src/libc/v6 in the V7 distro, I don't see a
replacement version of utime().

As near as I can make out, 'v6tar' must be using the standard V7 version of
utime(), which I assume turns into a call to nosys() on V6 (returns an error);
tar doesn't check the return value, so the call fails (silently). So v6tar
won't correctly set the file date when moving a file _to_ V6.

	Noel



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-10  4:50 Noel Chiappa
  0 siblings, 0 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-10  4:50 UTC (permalink / raw)


    > From: Dave Horsfall

    > I love those PDP-11 instructions, such as "blos" and "sob" :-)

Yes, but alas, there is no 'jump [on] no carry' instruction! (Yes, yes, I
know about BCC! :-) Although I guess the x86 has one...

	Noel



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 22:16 Noel Chiappa
  2015-12-09 22:31 ` Clem Cole
  0 siblings, 1 reply; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 22:16 UTC (permalink / raw)


    > estabur (who thought these names up, I know 8 characters is limiting,
    > but c'mon)

'establish user mode registers'

    > the 411 header is read by a loader

Actually, it's read by the exec() system call (in sys1.c).

	Noel



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 22:01 Noel Chiappa
  0 siblings, 0 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 22:01 UTC (permalink / raw)


    > Yes the V6 kernel runs in split I and D mode, but it doesn't end up
    > supporting any more data.  I.e. the kernel is still a 407 (or 410) file.
    > _etext/_edata/_end are still referencing the same 64K space.

Err, actually, not really.

The thing is that to build the split-I/D kernel, one sets the linker to
produce an output file which still contains the relocation bits. That is then
post-processed by 'sysfix', which does wierd magic (moves the text up to
020000, in terms of address space; and puts the data _below_ the text, in the
actual output file). So while the files concerned may have a '407' in their
header, they definitely aren't what one normally finds in a linked 407 or 410
file.

In particular, data addresses start at 0, and can run up to 0140000 (i.e. up
to 56KB), while text addreses start at 020000 and can run up to 0160000. So,
_etext/_edata/_end are not, in fact, in the same 64K space. And the total of
data (initialized and un-initialized) together with the text can be much
larger than 64KB - up to 112KB (modor so.

	Noel



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 17:50 Noel Chiappa
  2015-12-09 18:06 ` Will Senn
  0 siblings, 1 reply; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 17:50 UTC (permalink / raw)


    > 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



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 14:56 Noel Chiappa
  2015-12-09 16:37 ` Will Senn
  0 siblings, 1 reply; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 14:56 UTC (permalink / raw)


    > 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



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 14:24 Noel Chiappa
  0 siblings, 0 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 14:24 UTC (permalink / raw)


    > 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



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09 13:30 Noel Chiappa
  2015-12-09 14:43 ` Ronald Natalie
  2015-12-09 20:41 ` Dave Horsfall
  0 siblings, 2 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09 13:30 UTC (permalink / raw)


    > From: Ronald Natalie

    > I'm pretty sure the V6 kernel didn't run in split I/D.

Nope. From 'SETTING UP UNIX - Sixth Edition':

  "Another difference is that in 11/45 and 11/70 systems the instruction and
  data spaces are separated inside UNIX itself."

And if you don't believe that, check out:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s

the source! ;-)


    > It wasn't too involved of a change to make a split I/D kernel.
    > Mike Muuss and his crew at JHU did it.

Maybe you're remembering the process on a pre-V6 system?

    > We spent more time getting the bootstrap to work than anything else I
    > recall.

It's possible you're remembering that, as distributed, V6 didn't support load
images where the text+initialized-data was larger than 24KW-delta; it would
have been pretty eaay to up that to 28KW-delta (change a parameter in the
bootstrap source, and re-assemble), but after that, the V6 bootstrap would
have had to have been extensively re-worked.

And there were _also_ a variety of issues with handling maximal large images
in the startup code. Once operating, the kernel has segments KI1-KI7 available
the hold the system's code; however, it's not clear that all of KI1-7 are
really usable, since the system can't 'see' enough code while in the code
relocation phase in the startup to fill them all. E.g. during code relocation,
KI7 is ripped off to hold a pointer to I/O space (since KD7 is set to point to
low memory just after the memory that KD6 points to).

These might have been issues in systems which were ARPANET-connected (i.e.
ran NCP), as that added a very large amount of code to the kernel.

	Noel



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09  5:17 Noel Chiappa
  2015-12-09  5:55 ` Mark Longridge
  2015-12-09 11:31 ` Ronald Natalie
  0 siblings, 2 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09  5:17 UTC (permalink / raw)


    > 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



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09  4:53 Noel Chiappa
  2015-12-09 14:38 ` Will Senn
  2015-12-09 17:55 ` Will Senn
  0 siblings, 2 replies; 33+ messages in thread
From: Noel Chiappa @ 2015-12-09  4:53 UTC (permalink / raw)


    > From: Will Senn <will.senn at 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



^ permalink raw reply	[flat|nested] 33+ messages in thread
* [TUHS] v6tar from v7 on v6, too large?
@ 2015-12-09  3:33 Will Senn
  0 siblings, 0 replies; 33+ messages in thread
From: Will Senn @ 2015-12-09  3:33 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 33+ messages in thread
end of thread, other threads:[~2015-12-19 13:27 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-19 13:27 [TUHS] v6tar from v7 on v6, too large? Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2015-12-10  4:50 Noel Chiappa
2015-12-09 22:16 Noel Chiappa
2015-12-09 22:31 ` Clem Cole
2015-12-09 22:47   ` John Cowan
2015-12-09 23:39     ` Steve Nickolas
2015-12-10  0:24       ` Clem Cole
2015-12-10  0:23     ` Clem Cole
2015-12-10  1:08       ` Greg 'groggy' Lehey
2015-12-10  9:42         ` Jacob Ritorto
2015-12-10  1:19       ` John Cowan
2015-12-10 10:06     ` Oliver Lehmann
2015-12-10 19:50       ` Will Senn
2015-12-09 22:01 Noel Chiappa
2015-12-09 17:50 Noel Chiappa
2015-12-09 18:06 ` Will Senn
2015-12-09 14:56 Noel Chiappa
2015-12-09 16:37 ` Will Senn
2015-12-09 14:24 Noel Chiappa
2015-12-09 13:30 Noel Chiappa
2015-12-09 14:43 ` Ronald Natalie
2015-12-09 20:41 ` Dave Horsfall
2015-12-09  5:17 Noel Chiappa
2015-12-09  5:55 ` Mark Longridge
2015-12-09 11:31 ` Ronald Natalie
2015-12-09  4:53 Noel Chiappa
2015-12-09 14:38 ` Will Senn
2015-12-09 14:56   ` Clem Cole
2015-12-09 15:07     ` Clem Cole
2015-12-09 16:29       ` Will Senn
2015-12-09 14:59   ` Hellwig Geisse
2015-12-09 17:55 ` Will Senn
2015-12-09  3:33 Will Senn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).