[TUHS] v6tar from v7 on v6, too large?

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

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

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On 12/10/15 4:06 AM, Oliver Lehmann wrote:
>
> John Cowan <cowan at mercury.ccil.org> wrote:
>
>> Clem Cole scripsit:
>>
>>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command 
>>> is the
>>> "link editor",
>>
>> I thought "ld" stood for Link eDitor.  :-)
>
> You are completely wrong! It is the load mnemonic for Z8/Z80/Z8000 
> Assembler
> to load the operand into the destination
>
>    ld r1,r2
>
> ;)
>
> Oliver

As a newb who doesn't know any better than what it seems they do, in 
keeping with the original minimalism:
"as" should have been "me" for mnemonic encoder
"ld" should have been "la" for link and assemble
and some obscure function in /usr/sys/ken/sys1.c or maybe even 
/usr/sys/dmr/sys1.c, because one guy's folder is as good as the next, 
should have been called pldr(), for program loader, which would have 
been the program 'loader'.

-Will

[TUHS] v6tar from v7 on v6, too large?

[Oliver Lehmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]


John Cowan <cowan at mercury.ccil.org> wrote:

> Clem Cole scripsit:
>
>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
>> "link editor",
>
> I thought "ld" stood for Link eDitor.  :-)

You are completely wrong! It is the load mnemonic for Z8/Z80/Z8000 Assembler
to load the operand into the destination

    ld r1,r2

;)

Oliver

[TUHS] v6tar from v7 on v6, too large?

[Jacob Ritorto]

This is easily the greatest thread on this list in years.  LOVE!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151210/3db34e9d/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Clem Cole scripsit:

> > I thought "ld" stood for Link eDitor.  :-)
> >
> ​I have never heard that justification.   

That's because I made it up this very day, hence the smiley.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"

[TUHS] v6tar from v7 on v6, too large?

[Greg 'groggy' Lehey]

On Wednesday,  9 December 2015 at 19:23:07 -0500, Clem Cole wrote:
> On Wed, Dec 9, 2015 at 5:47 PM, John Cowan <cowan at mercury.ccil.org> wrote:
>
>> I thought "ld" stood for Link eDitor.  :-)
>>
> ???I have never heard that justification.   It's always been talked about as
> the "loader" communications I had with different folks including Dennis.
> In the early/mid '70s the person that introduced me to Unix (tjk) always
> called it the loader.???   Ted was (like many of us in those days) coming
> from either IBM's TSS or MTS, and influenced by IBM's terminology as well
> as DECs.

My understanding, which predates my contact with Unix, is that the
original toochains for single-job machines consisted of the assembler
or compiler, the output of which was loaded directly into core with
the loader.  As things became more complicated (and slow), it made
sense to store the memory image somewhere on drum, and then load that
image directly when you wanted to run it.  And that in some systems
the name "loader" stuck, even though it no longer loaded.  Something
like the modern ISP use of the term "modem" to mean "router".  But I
don't have anything to back up this version; comments welcome.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151210/fbd67b21/attachment.sig>

[TUHS] v6tar from v7 on v6, too large?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Wed, Dec 9, 2015 at 6:39 PM, Steve Nickolas <usotsuki at buric.co> wrote:

> ...so yeah. CP/M got a lot of its terminology from DEC.


​More specifically, RT-11 which is what it was emulating.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/879c4307/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Wed, Dec 9, 2015 at 5:47 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> I thought "ld" stood for Link eDitor.  :-)
>
​I have never heard that justification.   It's always been talked about as
the "loader" communications I had with different folks including Dennis.
In the early/mid '70s the person that introduced me to Unix (tjk) always
called it the loader.​   Ted was (like many of us in those days) coming
from either IBM's TSS or MTS, and influenced by IBM's terminology as well
as DECs.



> On OS/8 there
> ​ ​
> were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
> and LINK.  LINK was for the macro assembler, the last one published.
>
​I used TSS/8 and I've forgotten what is was called there, never used
OS/8.  In TOPS and Tenex land it was called a linker, as it was on TSS and
MTS.




> I don't remember the story on the various PDP-11 DEC OSes;
>
​RT-11, DOS-11 and RSX all called it a linker.​




> by VMS days
> ​ ​
> it was exclusively LINK.
>
​As the author of VMS's link and later versions, I'll try to ask Paul
tomorrow what he knows/remembers.  In my presence, he has b*tched about
Unix calling it a 'loader.​

​'

Clem

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/0fcdd1f3/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Wed, 9 Dec 2015, John Cowan wrote:

> Clem Cole scripsit:
>
>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
>> "link editor", 
>
> I thought "ld" stood for Link eDitor.  :-)

I thought it stood for "load", as that nomenclature is used on other OSes 
(I think CP/M maybe?)

>> I never asked Dennis or Ken why those names were not used.
>
> FWIW, DEC transitioned from "loader" to "link editor".  On OS/8 there
> were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
> and LINK.  LINK was for the macro assembler, the last one published.

...so yeah. CP/M got a lot of its terminology from DEC.

> I don't remember the story on the various PDP-11 DEC OSes; by VMS days
> it was exclusively LINK.  The ABSLDR actually did loading rather than
> linking (it was "absolute" in the sense that it did no relocation, so
> if parts of your program overwrote other parts, that was your problem).
> When it terminated, the executable program was in core (the ABSLDR's
> last act was to arrange for the executable to overwrite it) where you
> could save it or start it up as you were so minded.

-uso.

[TUHS] v6tar from v7 on v6, too large?

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Clem Cole scripsit:

> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
> "link editor", 

I thought "ld" stood for Link eDitor.  :-)

> I never asked Dennis or Ken why those names were not used.

FWIW, DEC transitioned from "loader" to "link editor".  On OS/8 there
were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
and LINK.  LINK was for the macro assembler, the last one published.
I don't remember the story on the various PDP-11 DEC OSes; by VMS days
it was exclusively LINK.  The ABSLDR actually did loading rather than
linking (it was "absolute" in the sense that it did no relocation, so
if parts of your program overwrote other parts, that was your problem).
When it terminated, the executable program was in core (the ABSLDR's
last act was to arrange for the executable to overwrite it) where you
could save it or start it up as you were so minded.

-- 
"Well, I'm back."  --Sam        John Cowan <cowan at ccil.org>

[TUHS] v6tar from v7 on v6, too large?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Wed, Dec 9, 2015 at 5:16 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
>
> Actually, it's read by the exec() system call (in sys1.c).
>
>
​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
"link editor", and exec(2) is the "program loader" in the pure OS/academic
naming sense.  I never asked Dennis or Ken why those names were not used.
I suspect like creat(2) it made sense at the time and then by the time the
functions leveled out, it was embedded too deep the change it.

​BTW:  the DEC (vms) link editor runs on Ultrix (PDP-11 and Vaxen).  The
binarie​s are part of the Fortran kit.  I'm not sure if it will run on V7
but it might work on BSD 2.x.  It's author sits a few feet from me these
days.   When DEC finally went to support DEC standard Fortran on UNIX it
was just easier to make the VMS link know how to output an a.out (and macho
files) and the end, then it was to try to add the features they needed for
Fortran to ld and a.out.

It's interesting hearing from Paul his issues over the years between, Unix,
NT, Apple etc., a.out, COFF, and other formats.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/559b62b8/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Dave Horsfall]

On Wed, 9 Dec 2015, Noel Chiappa wrote:

> 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

Blimey, but that takes my 60yo+ brain cells back a bit...  I love those
PDP-11 instructions, such as "blos" and "sob" :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

Noel,

Comments below:

On 12/9/15 11:50 AM, Noel Chiappa wrote:
>      > 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.
I have the pdf for the /70, but I just ordered a new paper copy on 
Amazon, call me old fashioned :).
>
>      > the 18 bits holding the word 000407
>
> You mean '16 bits', right? :-)
Yes you are correct, 5 octal digits, only 16 bits used for instructions.

>      > 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.
OK. This is up as my next investigation and it will be guided by 
Lions'... figuring out exactly how programs get loaded in v6 and 
secondarily v7.

Thanks,

Will

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

On 12/8/15 10:53 PM, Noel Chiappa wrote:
>      > 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
Noel,

I followed the thread you provided and I appreciate the direction. 
estabur(who thought these names up, I know 8 characters is limiting, but 
c'mon) is indeed the culprit:
         if(sep) {
                 if(cputype == 40)
                         goto err;

I'm gathering (read still investigating) that the 411 header is read by 
a loader and the call to estabur is made with a value for sep indicating 
that it is a split I+D binary, then the cputype is checked and sure 
enough, it's a PDP-11/40 and the error is generated.

Thanks,

Will

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

On 12/9/15 8:56 AM, Noel Chiappa wrote:
>      > 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
Noel,

This is great help. I'll get more or less going and see where I wind up.

Thanks,

Will

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3578 bytes --]

On 12/9/15 9:07 AM, Clem Cole wrote:
>
> On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc at ccc.com 
> <mailto:clemc at ccc.com>> wrote:
>
>     check the man page on the a.out format.
>
>
> ​Note to folks on the list - please don't give away the answer...
>
> Will
>
> A small piece of homework for the student -- look at 407 the magic 
> number for the a.out file ​and see if you can explain why Ken picked 
> that value.  Hint it is particular to the PDP-11 architecture and is 
> not portable to other systems, although most other systems that UNIX 
> was "ported" too continued to used the a.out format kept the magic 
> numbers as 407/411 etc., although I know of some ports (like mine own 
> for Magix - the Tek Magnolia system of the late 1970s) that changed 
> the magic number to be correct for that architecture.
>
> Clem
>
Clem,

Nice!

In full disclosure, I read about magic numbers being PDP architecture 
related somewhere in the recent past, but I didn't really understand the 
connection. So, when you mentioned it, rather than google it and spoil 
the fun, I took the hint and thought a bit about it in the context of 
our discussion. As it turns out, according to my now handy-dandy 
PDP11/40 processor handbook, the 18 bits holding the word 000407 which 
appears as the first word of most of my v6 binaries, 000 000 100 000 
111b, the magic number represents the BR instruction base where the last 
8 bits is an offset added to the PC after it has read the word. So, the 
PDP loads the object, reads the first word, determines it is a branch 
instruction:

BR PC+7

and jumps forward to start reading the 9th word of the program. Why the 
9th word? According to man 5 a.out, the a.out header always contains 8 
words.

So, given a binary, like write:
dd if=write bs=128 count=1|od
1+0 records in
1+0 records out
0000000 000407 001176 000032 000150 000000 000000 000000 000001
0000020 022627 000002 001412 003006 012700 000001 104404 000657
...

The analysis that follows in light of the information discovered so far 
would be:
word 1 at 0000000 000407 Magic Number (BR PC+7)
word 2 at 0000002 001176 Size of the program text segment (638 bytes)
word 3 at 0000004 000032 Size of the initialized data segment (26 bytes)
word 4 at 0000006 000150 Size of the uninitialized data segment (104 bytes)
word 5 at 0000010 000000 Size of the symbol table (stripped in this case)
word 6 at 0000012 000000 The entry location 0 at present
word 7 at 0000014 000000 Unused
word 8 at 0000016 000001 Relocation bit suppression flag (I think this 
means the file contains absolute memory references)
word 9 at 0000020 022627 The target of the first branch, contains 
instructions to MOV (R6)+,(R7)+ (I think)...

According to man 5 a.out on v7, the different magic numbers represent 
normal, read-only text, separate I&D, and overlay:
     #define A_MAGIC1 0407       /* normal */
     #define A_MAGIC2 0410       /* read-only text */
     #define A_MAGIC3 0411       /* separated I&D */
     #define A_MAGIC4 0405       /* overlay */

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.

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

Thanks,

Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/10392878/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc at ccc.com> wrote:

> check the man page on the a.out format.


​Note to folks on the list - please don't give away the answer...

Will

A small piece of homework for the student -- look at 407 the magic number
for the a.out file ​and see if you can explain why Ken picked that value.
Hint it is particular to the PDP-11 architecture and is not portable to
other systems, although most other systems that UNIX was "ported" too
continued to used the a.out format kept the magic numbers as 407/411 etc.,
although I know of some ports (like mine own for Magix - the Tek Magnolia
system of the late 1970s) that changed the magic number to be correct for
that architecture.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/f98239b5/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Hellwig Geisse]

On Mi, 2015-12-09 at 08:38 -0600, Will Senn wrote:
> Now, when you say dump the a.out header, how do you do that?

Apply OD(1) to the executable. You can then inspect the
exec header, especially the magic number, in order to
investigate the startup of the program.

Hellwig

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Clem Cole]

dd if=v6tar bs=128 count=1 | od

check the man page on the a.out format.

BTW:  I would relink v6tar to be a "407" header so it will run anywhere.
That said, there are a number of copies of v6tar "in the wild" - my memory
is that it's on a late 1970's, very early 1980s USENIX tape.



On Wed, Dec 9, 2015 at 9:38 AM, Will Senn <will.senn at gmail.com> wrote:

> On 12/8/15 10:53 PM, Noel Chiappa wrote:
>
>>      > 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
>>
> That was it. Thanks for supplying the logic trail you followed as well! I
> "upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate SimH
> commands and then I folllowed the instructions in Setting up Unix Sixth
> Edition to use the m45.s assist and voila, v6tar works. Thank you.
>
> Now, when you say dump the a.out header, how do you do that?
>
> Thanks,
>
> Will
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/3ea32ab9/attachment.html>

[TUHS] v6tar from v7 on v6, too large?

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

I now see our disconnect Noel.   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.   What we did (among others) was to allow the system to boot up from a split I/D image that could be a full 65K of text and a substantial additional amount of initialized data (and bss).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/c6c9f5bf/attachment.bin>

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

On 12/8/15 10:53 PM, Noel Chiappa wrote:
>      > 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
That was it. Thanks for supplying the logic trail you followed as well! 
I "upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate 
SimH commands and then I folllowed the instructions in Setting up Unix 
Sixth Edition to use the m45.s assist and voila, v6tar works. Thank you.

Now, when you say dump the a.out header, how do you do that?

Thanks,

Will

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

> 
> 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’m pretty sure the V6 kernel didn’t run in split I/D.   It supported three user a.out formats:   407 (mixed I&D in one instructions space),
410 (mixed I&D but with the instructions in write protected segments), and 411 (split I&D).

It wasn’t too involved of a change to make a split I/D kernel.    Mike Muuss and his crew at JHU did it.   We spent more time getting the bootstrap to work than anything else I recall.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/e4f44d30/attachment.bin>

[TUHS] v6tar from v7 on v6, too large?

[Mark Longridge]

Ok, I can make a few remarks about v6tar and ar and dd.

I've never been able to transfer any file larger than 64K to Unix V5 or V6.
Smaller than 64K seems to work fine. I'm using the same command on V5 and V6:

dd if=/dev/mt0 of=cont.a bs=1 count=90212

And I'll get:

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 and I don't think it's just
a v6tar limitation.

I compiled the kernel with m45.s on V6 and mch.s on V5. I also don't
recall seeing any file on V5 or V6 larger than 65536 bytes, but it's
possible I've overlooked one.

My workaround solution was to simply keep tar files and archive files
under 64K but I would be interested to hear of a better solution.

Mark


On 12/9/15, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > 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
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Noel Chiappa]

    > 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

[TUHS] v6tar from v7 on v6, too large?

[Will Senn]

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