The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] wump.c for v6
@ 2020-01-06  6:13 Will Senn
  2020-01-06 15:20 ` Clem Cole
  0 siblings, 1 reply; 21+ messages in thread
From: Will Senn @ 2020-01-06  6:13 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

Hi,

Does the wump.c source exist for v6? The game's in the distribution and 
so is the man page, but I can't find the source. I see it's in v7, but I 
don't know the provenance of the game source, hence the question.

I find the following interesting... in the v7 source it says:

/*
  *      wumpus
  *      stolen from PCC Vol 2 No 1
  */

But it's actually from PCC Vol 2 No 2 (Nov 1973):
https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-n2-acc.pdf

and the basic source is given in the games issue:
https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-games-acc.pdf

The correct volume is noted in the v6 manpage:

This program is based on one described  in  2  (No-
vember 1973).  It will never replace Space War.

and in the v7 manpage:

This program is based on one described in People's Computer
      Company, 2, 2 (November 1973).

BUGS
      It will never replace Space War.

I'm curious if it was ported to c for v6, or if it was basic?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06  6:13 [TUHS] wump.c for v6 Will Senn
@ 2020-01-06 15:20 ` Clem Cole
  2020-01-06 15:24   ` Clem Cole
  2020-01-06 16:25   ` Will Senn
  0 siblings, 2 replies; 21+ messages in thread
From: Clem Cole @ 2020-01-06 15:20 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Mon, Jan 6, 2020 at 1:14 AM Will Senn <will.senn@gmail.com> wrote:

> Does the wump.c source exist for v6? The game's in the distribution and so
> is the man page, but I can't find the source. I see it's in v7, but I don't
> know the provenance of the game source, hence the question.
>
Interesting question for someone like Doug, Steve or Ken.  I bet it is
pretty close, if not the same.   I notice the V7 version used printf and
getchar, but does not define stdio.h.  It also has a struct in it.  So by
the time of that version, printf existed as did structs both of which were
in the V6 C compiler (V6 did not have stdio, it had Mike Lesk's 'Portable
I/O Library' (iolib in the sources).

I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
if you did and compared it to an nm from V6 I bet they are darned close.


....
> I'm curious if it was ported to c for v6, or if it was basic?
>
I would guess B or C not basic.  The UNIX basic was primitive compared to
Darthmouth (or HP - which would become HP-2000 basic but that's a different
story).   Code from PCC (or later David Ahl's "101 Basic Computer Games"
<https://www.amazon.com/101-BASIC-Computer-Games-David/dp/B000CNZP5U/ref=smi_www_rco2_go_smi_3905707922>
)
would not work without extensive rewriting.  Something that small,
converting to B or C would have been similar effort so I would have
expected that to have been what happened.

Remember Edition X, particularly for the first few, was the status of the
disks in research at the time.  So there are a few cases of binaries in
some of the earlier editions being found in /usr/bin or the like and the
sources not there in the distribution.

[-- Attachment #2: Type: text/html, Size: 3544 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 15:20 ` Clem Cole
@ 2020-01-06 15:24   ` Clem Cole
  2020-01-06 16:25   ` Will Senn
  1 sibling, 0 replies; 21+ messages in thread
From: Clem Cole @ 2020-01-06 15:24 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 178 bytes --]

ah dyslexia....

>
>
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
> if you did and compared it to an nm from *V7* I bet they are darned close.
>
>

[-- Attachment #2: Type: text/html, Size: 864 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 15:20 ` Clem Cole
  2020-01-06 15:24   ` Clem Cole
@ 2020-01-06 16:25   ` Will Senn
  2020-01-06 16:35     ` Clem Cole
  1 sibling, 1 reply; 21+ messages in thread
From: Will Senn @ 2020-01-06 16:25 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]



Sent from my iPhone

> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc@ccc.com> wrote: 
> 
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet if you did and compared it to an nm from V6 I bet they are darned close.
> 
nm wump
no name list

Bummer.


[-- Attachment #2: Type: text/html, Size: 1005 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 16:25   ` Will Senn
@ 2020-01-06 16:35     ` Clem Cole
  2020-01-06 18:29       ` Warner Losh
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-01-06 16:35 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Ah - sadly not surprising thinking back.  Binaries got stripped to save a
few bytes in those days.

On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc@ccc.com> wrote:
>
>
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
> if you did and compared it to an nm from V6 I bet they are darned close.
>
> nm wump
> no name list
>
> Bummer.
>
>

[-- Attachment #2: Type: text/html, Size: 1478 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 16:35     ` Clem Cole
@ 2020-01-06 18:29       ` Warner Losh
  2020-01-06 18:38         ` Will Senn
  0 siblings, 1 reply; 21+ messages in thread
From: Warner Losh @ 2020-01-06 18:29 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Will Senn

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

The good news is that disassembly will tell you right away if it was
written in C or not.

On Mon, Jan 6, 2020 at 9:36 AM Clem Cole <clemc@ccc.com> wrote:

> Ah - sadly not surprising thinking back.  Binaries got stripped to save a
> few bytes in those days.
>
> On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc@ccc.com> wrote:
>>
>>
>> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
>> if you did and compared it to an nm from V6 I bet they are darned close.
>>
>> nm wump
>> no name list
>>
>> Bummer.
>>
>>

[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 18:29       ` Warner Losh
@ 2020-01-06 18:38         ` Will Senn
  2020-01-06 18:48           ` Warner Losh
  2020-01-06 19:10           ` Bakul Shah
  0 siblings, 2 replies; 21+ messages in thread
From: Will Senn @ 2020-01-06 18:38 UTC (permalink / raw)
  To: Warner Losh, Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On 1/6/20 12:29 PM, Warner Losh wrote:
> The good news is that disassembly will tell you right away if it was 
> written in C or not.
>
>
OK. I give up. How?

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 862 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 18:38         ` Will Senn
@ 2020-01-06 18:48           ` Warner Losh
  2020-01-06 21:08             ` Clem Cole
  2020-01-07 20:04             ` Sean Dwyer via TUHS
  2020-01-06 19:10           ` Bakul Shah
  1 sibling, 2 replies; 21+ messages in thread
From: Warner Losh @ 2020-01-06 18:48 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:

> On 1/6/20 12:29 PM, Warner Losh wrote:
>
> The good news is that disassembly will tell you right away if it was
> written in C or not.
>
>
> OK. I give up. How?
>

Generally, the C compiler generates code that's quite distinctive (at least
PCC does, not sure about Dennis' compiler). People writing free assembler
tend to do really weird things for function entry / return.

And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.

Warner

[-- Attachment #2: Type: text/html, Size: 1269 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 18:38         ` Will Senn
  2020-01-06 18:48           ` Warner Losh
@ 2020-01-06 19:10           ` Bakul Shah
  2020-01-06 20:29             ` Will Senn
  1 sibling, 1 reply; 21+ messages in thread
From: Bakul Shah @ 2020-01-06 19:10 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn@gmail.com> wrote:
>
> On 1/6/20 12:29 PM, Warner Losh wrote:
> > The good news is that disassembly will tell you right away if it was 
> > written in C or not.
> >
> >
> OK. I give up. How?

Running strings on the wump binary in Dennis_v6 and comparing
its output with actual strings in the wump.c source n
Henry_Spencerv7 reveals they are pretty much the same.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 19:10           ` Bakul Shah
@ 2020-01-06 20:29             ` Will Senn
  0 siblings, 0 replies; 21+ messages in thread
From: Will Senn @ 2020-01-06 20:29 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On 1/6/20 1:10 PM, Bakul Shah wrote:
> On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn@gmail.com> wrote:
>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>> The good news is that disassembly will tell you right away if it was
>>> written in C or not.
>>>
>>>
>> OK. I give up. How?
> Running strings on the wump binary in Dennis_v6 and comparing
> its output with actual strings in the wump.c source n
> Henry_Spencerv7 reveals they are pretty much the same.
Oh. That's funny. I tried strings in v6, it wasn't there. It didn't 
occur to me to do it in MacOS...

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 1449 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 18:48           ` Warner Losh
@ 2020-01-06 21:08             ` Clem Cole
  2020-01-06 21:38               ` Clem Cole
  2020-01-07 20:04             ` Sean Dwyer via TUHS
  1 sibling, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-01-06 21:08 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Will Senn

[-- Attachment #1: Type: text/plain, Size: 4897 bytes --]

You got my curiosity up and found the V5 and V6 source code (I did not have
V4 easy to get, where I am today) ;-)

A big clue of it being C will be having crt0.s (below) in the first few
bytes of the disassembled code.  We see the a.out header (i.e. start at
offset 20 for the code) and look what's there.  I'm going to guess that is
at 046 is the address of _main, from the call instruction at address 034.
The Trap 1 is a sys exit @ address 044.
But .. the V6 crt0.s source has a call to _exit, which is lacking in the
binary below.   So it means that the binary was not created with the C
runtime and probably not the v6 C compiler in the sources.  So I took a
peak at the V6 crt0.s and guess what -- it matches!

So, I'm going to guess the binary was compiled and linked with an earlier
compiler.  Ao ... if I had to guess, the programs are similar, but possibly
different.

% more wump.das
;
; pdp11dasm version 0.0.3
; disassembly of wump
;
000000: 000407                  br      20                      ; ..
;
000002: 005334                  dec     @(r4)+                  ; \.
000004: 004524                  jsr     r5,(r4)+                ; T.
000006: 002312                  bge     37777777634             ; J.
000010: 000000                  halt                            ; ..
000012: 000000                  halt                            ; ..
000014: 000000                  halt                            ; ..
;
000016: 000001                  wait                            ; ..
000020: 170011                  setd                            ; .p
000022: 010600                  mov     r6,r0                   ; ..
000024: 011046                  mov     (r0),-(r6)              ; &.
000026: 005720                  tst     (r0)+                   ; P.
000030: 010066 000002           mov     r0,2(r6)                ; 6...
000034: 004767 000006           call    46                      ; w...
000040: 022626                  cmp     (r6)+,(r6)+             ; .%
000042: 005000                  clr     r0                      ; ..
000044: 104401                  trap    1                       ; ..
000046: 004567 005174           jsr     r5,5246                 ; w.|.
000052: 005746                  tst     -(r6)                   ; f.
000054: 012716 011230           mov     #11230,(r6)             ; N...
000060: 004737 002776           call    @#2776                  ; _.~.
000064: 004767 002262           call    2352                    ; w.2.
000070: 022700 000171           cmp     #171,r0                 ; @%y.
000074: 001027                  bne     154                     ; ..
000076: 005004                  clr     r4                      ; ..
000100: 010400                  mov     r4,r0                   ; ..
000102: 006300                  asl     r0                      ; @.
000104: 005760 005334           tst     5334(r0)                ; p.\.
000110: 001421                  beq     154                     ; ..
000112: 032704 000001           bit     #1,r4                   ; D5..
000116: 001403                  beq     126                     ; ..
000120: 012716 000024           mov     #24,(r6)                ; N...
000124: 000402                  br      132                     ; ..
;
000126: 012716 000003           mov     #3,(r6)                 ; N...
000132: 010400                  mov     r4,r0                   ; ..
000134: 006300                  asl     r0                      ; @.
000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
000142: 004737 002776           call    @#2776                  ; _.~.





V6: s4/crt0.s:
/ C runtime startoff

.globl  savr5
.globl  _exit

.globl  _main

start:
        setd
        mov     sp,r0
        mov     (r0),-(sp)
        tst     (r0)+
        mov     r0,2(sp)
        jsr     pc,_main
        mov     r0,(sp)
        jsr     pc,*$_exit
        sys     exit

.bss
savr5:  .=.+2

V5: s4/crt0.s:
/ C runtime startoff

.globl  savr5

.globl  _main

start:
        setd
        mov     sp,r0
        mov     (r0),-(sp)
        tst     (r0)+
        mov     r0,2(sp)
        jsr     pc,_main
        cmp     (sp)+,(sp)+
        clr     r0
        sys     exit

.bss
savr5:  .=.+2

On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:
>
>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>
>> The good news is that disassembly will tell you right away if it was
>> written in C or not.
>>
>>
>> OK. I give up. How?
>>
>
> Generally, the C compiler generates code that's quite distinctive (at
> least PCC does, not sure about Dennis' compiler). People writing free
> assembler tend to do really weird things for function entry / return.
>
> And it will likely tell you if it's some weird wrapper around another
> binary, though that wasn't too common at bell labs.
>
> Warner
>

[-- Attachment #2: Type: text/html, Size: 8476 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 21:08             ` Clem Cole
@ 2020-01-06 21:38               ` Clem Cole
  2020-01-06 22:14                 ` Warner Losh
  2020-01-06 23:46                 ` Will Senn
  0 siblings, 2 replies; 21+ messages in thread
From: Clem Cole @ 2020-01-06 21:38 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Will Senn

[-- Attachment #1: Type: text/plain, Size: 5274 bytes --]

Some day ....   So I took a peak at the V5 crt0.s and guess what -- it
matches!

On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc@ccc.com> wrote:

> You got my curiosity up and found the V5 and V6 source code (I did not
> have V4 easy to get, where I am today) ;-)
>
> A big clue of it being C will be having crt0.s (below) in the first few
> bytes of the disassembled code.  We see the a.out header (i.e. start at
> offset 20 for the code) and look what's there.  I'm going to guess that is
> at 046 is the address of _main, from the call instruction at address 034.
> The Trap 1 is a sys exit @ address 044.
> But .. the V6 crt0.s source has a call to _exit, which is lacking in the
> binary below.   So it means that the binary was not created with the C
> runtime and probably not the v6 C compiler in the sources.  So I took a
> peak at the V6 crt0.s and guess what -- it matches!
>
> So, I'm going to guess the binary was compiled and linked with an earlier
> compiler.  Ao ... if I had to guess, the programs are similar, but possibly
> different.
>
> % more wump.das
> ;
> ; pdp11dasm version 0.0.3
> ; disassembly of wump
> ;
> 000000: 000407                  br      20                      ; ..
> ;
> 000002: 005334                  dec     @(r4)+                  ; \.
> 000004: 004524                  jsr     r5,(r4)+                ; T.
> 000006: 002312                  bge     37777777634             ; J.
> 000010: 000000                  halt                            ; ..
> 000012: 000000                  halt                            ; ..
> 000014: 000000                  halt                            ; ..
> ;
> 000016: 000001                  wait                            ; ..
> 000020: 170011                  setd                            ; .p
> 000022: 010600                  mov     r6,r0                   ; ..
> 000024: 011046                  mov     (r0),-(r6)              ; &.
> 000026: 005720                  tst     (r0)+                   ; P.
> 000030: 010066 000002           mov     r0,2(r6)                ; 6...
> 000034: 004767 000006           call    46                      ; w...
> 000040: 022626                  cmp     (r6)+,(r6)+             ; .%
> 000042: 005000                  clr     r0                      ; ..
> 000044: 104401                  trap    1                       ; ..
> 000046: 004567 005174           jsr     r5,5246                 ; w.|.
> 000052: 005746                  tst     -(r6)                   ; f.
> 000054: 012716 011230           mov     #11230,(r6)             ; N...
> 000060: 004737 002776           call    @#2776                  ; _.~.
> 000064: 004767 002262           call    2352                    ; w.2.
> 000070: 022700 000171           cmp     #171,r0                 ; @%y.
> 000074: 001027                  bne     154                     ; ..
> 000076: 005004                  clr     r4                      ; ..
> 000100: 010400                  mov     r4,r0                   ; ..
> 000102: 006300                  asl     r0                      ; @.
> 000104: 005760 005334           tst     5334(r0)                ; p.\.
> 000110: 001421                  beq     154                     ; ..
> 000112: 032704 000001           bit     #1,r4                   ; D5..
> 000116: 001403                  beq     126                     ; ..
> 000120: 012716 000024           mov     #24,(r6)                ; N...
> 000124: 000402                  br      132                     ; ..
> ;
> 000126: 012716 000003           mov     #3,(r6)                 ; N...
> 000132: 010400                  mov     r4,r0                   ; ..
> 000134: 006300                  asl     r0                      ; @.
> 000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
> 000142: 004737 002776           call    @#2776                  ; _.~.
>
>
>
>
>
> V6: s4/crt0.s:
> / C runtime startoff
>
> .globl  savr5
> .globl  _exit
>
> .globl  _main
>
> start:
>         setd
>         mov     sp,r0
>         mov     (r0),-(sp)
>         tst     (r0)+
>         mov     r0,2(sp)
>         jsr     pc,_main
>         mov     r0,(sp)
>         jsr     pc,*$_exit
>         sys     exit
>
> .bss
> savr5:  .=.+2
>
> V5: s4/crt0.s:
> / C runtime startoff
>
> .globl  savr5
>
> .globl  _main
>
> start:
>         setd
>         mov     sp,r0
>         mov     (r0),-(sp)
>         tst     (r0)+
>         mov     r0,2(sp)
>         jsr     pc,_main
>         cmp     (sp)+,(sp)+
>         clr     r0
>         sys     exit
>
> .bss
> savr5:  .=.+2
>
> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:
>>
>>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>>
>>> The good news is that disassembly will tell you right away if it was
>>> written in C or not.
>>>
>>>
>>> OK. I give up. How?
>>>
>>
>> Generally, the C compiler generates code that's quite distinctive (at
>> least PCC does, not sure about Dennis' compiler). People writing free
>> assembler tend to do really weird things for function entry / return.
>>
>> And it will likely tell you if it's some weird wrapper around another
>> binary, though that wasn't too common at bell labs.
>>
>> Warner
>>
>

[-- Attachment #2: Type: text/html, Size: 9032 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 21:38               ` Clem Cole
@ 2020-01-06 22:14                 ` Warner Losh
  2020-01-06 23:46                 ` Will Senn
  1 sibling, 0 replies; 21+ messages in thread
From: Warner Losh @ 2020-01-06 22:14 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Will Senn

[-- Attachment #1: Type: text/plain, Size: 5564 bytes --]

You have V4 sources? The TUHS archive doesn't have them that I've seen...

Warner

On Mon, Jan 6, 2020, 2:38 PM Clem Cole <clemc@ccc.com> wrote:

> Some day ....   So I took a peak at the V5 crt0.s and guess what -- it
> matches!
>
> On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc@ccc.com> wrote:
>
>> You got my curiosity up and found the V5 and V6 source code (I did not
>> have V4 easy to get, where I am today) ;-)
>>
>> A big clue of it being C will be having crt0.s (below) in the first few
>> bytes of the disassembled code.  We see the a.out header (i.e. start at
>> offset 20 for the code) and look what's there.  I'm going to guess that is
>> at 046 is the address of _main, from the call instruction at address 034.
>> The Trap 1 is a sys exit @ address 044.
>> But .. the V6 crt0.s source has a call to _exit, which is lacking in the
>> binary below.   So it means that the binary was not created with the C
>> runtime and probably not the v6 C compiler in the sources.  So I took a
>> peak at the V6 crt0.s and guess what -- it matches!
>>
>> So, I'm going to guess the binary was compiled and linked with an earlier
>> compiler.  Ao ... if I had to guess, the programs are similar, but possibly
>> different.
>>
>> % more wump.das
>> ;
>> ; pdp11dasm version 0.0.3
>> ; disassembly of wump
>> ;
>> 000000: 000407                  br      20                      ; ..
>> ;
>> 000002: 005334                  dec     @(r4)+                  ; \.
>> 000004: 004524                  jsr     r5,(r4)+                ; T.
>> 000006: 002312                  bge     37777777634             ; J.
>> 000010: 000000                  halt                            ; ..
>> 000012: 000000                  halt                            ; ..
>> 000014: 000000                  halt                            ; ..
>> ;
>> 000016: 000001                  wait                            ; ..
>> 000020: 170011                  setd                            ; .p
>> 000022: 010600                  mov     r6,r0                   ; ..
>> 000024: 011046                  mov     (r0),-(r6)              ; &.
>> 000026: 005720                  tst     (r0)+                   ; P.
>> 000030: 010066 000002           mov     r0,2(r6)                ; 6...
>> 000034: 004767 000006           call    46                      ; w...
>> 000040: 022626                  cmp     (r6)+,(r6)+             ; .%
>> 000042: 005000                  clr     r0                      ; ..
>> 000044: 104401                  trap    1                       ; ..
>> 000046: 004567 005174           jsr     r5,5246                 ; w.|.
>> 000052: 005746                  tst     -(r6)                   ; f.
>> 000054: 012716 011230           mov     #11230,(r6)             ; N...
>> 000060: 004737 002776           call    @#2776                  ; _.~.
>> 000064: 004767 002262           call    2352                    ; w.2.
>> 000070: 022700 000171           cmp     #171,r0                 ; @%y.
>> 000074: 001027                  bne     154                     ; ..
>> 000076: 005004                  clr     r4                      ; ..
>> 000100: 010400                  mov     r4,r0                   ; ..
>> 000102: 006300                  asl     r0                      ; @.
>> 000104: 005760 005334           tst     5334(r0)                ; p.\.
>> 000110: 001421                  beq     154                     ; ..
>> 000112: 032704 000001           bit     #1,r4                   ; D5..
>> 000116: 001403                  beq     126                     ; ..
>> 000120: 012716 000024           mov     #24,(r6)                ; N...
>> 000124: 000402                  br      132                     ; ..
>> ;
>> 000126: 012716 000003           mov     #3,(r6)                 ; N...
>> 000132: 010400                  mov     r4,r0                   ; ..
>> 000134: 006300                  asl     r0                      ; @.
>> 000136: 016046 005334           mov     5334(r0),-(r6)          ; &.\.
>> 000142: 004737 002776           call    @#2776                  ; _.~.
>>
>>
>>
>>
>>
>> V6: s4/crt0.s:
>> / C runtime startoff
>>
>> .globl  savr5
>> .globl  _exit
>>
>> .globl  _main
>>
>> start:
>>         setd
>>         mov     sp,r0
>>         mov     (r0),-(sp)
>>         tst     (r0)+
>>         mov     r0,2(sp)
>>         jsr     pc,_main
>>         mov     r0,(sp)
>>         jsr     pc,*$_exit
>>         sys     exit
>>
>> .bss
>> savr5:  .=.+2
>>
>> V5: s4/crt0.s:
>> / C runtime startoff
>>
>> .globl  savr5
>>
>> .globl  _main
>>
>> start:
>>         setd
>>         mov     sp,r0
>>         mov     (r0),-(sp)
>>         tst     (r0)+
>>         mov     r0,2(sp)
>>         jsr     pc,_main
>>         cmp     (sp)+,(sp)+
>>         clr     r0
>>         sys     exit
>>
>> .bss
>> savr5:  .=.+2
>>
>> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:
>>>
>>>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>>>
>>>> The good news is that disassembly will tell you right away if it was
>>>> written in C or not.
>>>>
>>>>
>>>> OK. I give up. How?
>>>>
>>>
>>> Generally, the C compiler generates code that's quite distinctive (at
>>> least PCC does, not sure about Dennis' compiler). People writing free
>>> assembler tend to do really weird things for function entry / return.
>>>
>>> And it will likely tell you if it's some weird wrapper around another
>>> binary, though that wasn't too common at bell labs.
>>>
>>> Warner
>>>
>>

[-- Attachment #2: Type: text/html, Size: 9554 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 21:38               ` Clem Cole
  2020-01-06 22:14                 ` Warner Losh
@ 2020-01-06 23:46                 ` Will Senn
  1 sibling, 0 replies; 21+ messages in thread
From: Will Senn @ 2020-01-06 23:46 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]



Sent from my iPhone

> On Jan 6, 2020, at 3:38 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> Some day ....   So I took a peak at the V5 crt0.s and guess what -- it matches! 

Awesome. Thanks for sharing your approach to the disasm. 

On another note,You said you looked in v5 and v6 source code? I looked at tuhs and didn’t see anything earlier than v7. Where did you find them?

Thanks,

Will

[-- Attachment #2: Type: text/html, Size: 973 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-06 18:48           ` Warner Losh
  2020-01-06 21:08             ` Clem Cole
@ 2020-01-07 20:04             ` Sean Dwyer via TUHS
  2020-01-07 21:08               ` Clem Cole
  1 sibling, 1 reply; 21+ messages in thread
From: Sean Dwyer via TUHS @ 2020-01-07 20:04 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote:
> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:
> 
> > On 1/6/20 12:29 PM, Warner Losh wrote:
> >
> > The good news is that disassembly will tell you right away if it was
> > written in C or not.
> >
> >
> > OK. I give up. How?
> >
> 
> Generally, the C compiler generates code that's quite distinctive (at least
> PCC does, not sure about Dennis' compiler). People writing free assembler
> tend to do really weird things for function entry / return.
> 
> And it will likely tell you if it's some weird wrapper around another
> binary, though that wasn't too common at bell labs.
> 
> Warner

A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
another source-less v6 binary, cno. Fortunately, it hadn't been stripped but I
still did some disasembly because of the interesting differences. v6 binaries
have a different crt0 preamble and simpler subroutine setup, and I narrowed
dowh the library code to an intermediate stage of iolib (which IIRC still
exists in the UNSW archive on TUHS). There's a few cribs in that essay to help
you figure out some basic things, pdp11 assembly isn't hard to decode.

-- 
I love deadlines. I love the whooshing noise as they fly by.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-07 20:04             ` Sean Dwyer via TUHS
@ 2020-01-07 21:08               ` Clem Cole
  2020-01-08  6:35                 ` Sean Dwyer via TUHS
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-01-07 21:08 UTC (permalink / raw)
  To: Sean Dwyer; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]

Nice job -- one comment:  You said at the end of your document:

"Both cno and phx were written at what appears to have been what I would
call v6b, version 6 as the standard library was moving from libS to libc,
as Dennis Ritchie formalised the library proper. This can be seen in crt0.s
where the form is not of standard V6 but of the libc V6 before it became
standard in V7 and changed yet again. I was able to track this using the
UNSW archives which have both libraries at the critical point."


I will place a bet it is not your v6b idea...  (which was basically V6 plus
Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
which was based on V6 too -- made it into the wild in a couple of places).
Anyway, I think you are seeing code output from what was called the
'Typesetter C" compiler release which came out before V7 and was needed to
compile troff *et al.*  which actually what conforms with the original
K&R.   Indeed, that compiler used libS as the library.

The other thing, many v6 implementations (like CMU's and I think MIT) had a
preprocessor (it was called /lib/cpp ) before we got Typesetter C.  i.e. a
version of cpp that predated the Riesner cpp rewrite that was in Typesetter
C and later V7.  Steve Johnson probably knows the history of the
preprocessor better than I.   I know when we went through the V5 to V6
upgrade we somehow had a preprocessor.   I remember being curious about it
and then being disappointed it was not as good as the BLISS macro facility.

But ... neither the binary nor the sources for that cpp are in Warner's
Archives for V6 when I just looked.

The Interdata 7/32 stuff Warren has is a V6 port, and has a version of cpp,
but a note in the source says it is based on what looks like the Typesetter
C compiler - which was sometimes called the Level 7 compiler because Dennis
had told us all it was the new compiler for the next releases (TS and V7).

PWB 1.0 has a copy of cpp in the sources, but a quick look its not clear
how close the V7 version it is.

So, unless anyone else can illuminate, I'm not sure where the first cpp
that some of us using v6 had originated.

On Tue, Jan 7, 2020 at 3:14 PM Sean Dwyer via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote:
> > On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn@gmail.com> wrote:
> >
> > > On 1/6/20 12:29 PM, Warner Losh wrote:
> > >
> > > The good news is that disassembly will tell you right away if it was
> > > written in C or not.
> > >
> > >
> > > OK. I give up. How?
> > >
> >
> > Generally, the C compiler generates code that's quite distinctive (at
> least
> > PCC does, not sure about Dennis' compiler). People writing free assembler
> > tend to do really weird things for function entry / return.
> >
> > And it will likely tell you if it's some weird wrapper around another
> > binary, though that wasn't too common at bell labs.
> >
> > Warner
>
> A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
> another source-less v6 binary, cno. Fortunately, it hadn't been stripped
> but I
> still did some disasembly because of the interesting differences. v6
> binaries
> have a different crt0 preamble and simpler subroutine setup, and I narrowed
> dowh the library code to an intermediate stage of iolib (which IIRC still
> exists in the UNSW archive on TUHS). There's a few cribs in that essay to
> help
> you figure out some basic things, pdp11 assembly isn't hard to decode.
>
> --
> I love deadlines. I love the whooshing noise as they fly by.
>

[-- Attachment #2: Type: text/html, Size: 7253 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-07 21:08               ` Clem Cole
@ 2020-01-08  6:35                 ` Sean Dwyer via TUHS
  0 siblings, 0 replies; 21+ messages in thread
From: Sean Dwyer via TUHS @ 2020-01-08  6:35 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

On Tue, Jan 07, 2020 at 04:08:08PM -0500, Clem Cole wrote:

> I will place a bet it is not your v6b idea...  (which was basically V6 plus
> Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
> which was based on V6 too -- made it into the wild in a couple of places).
> Anyway, I think you are seeing code output from what was called the
> 'Typesetter C" compiler release which came out before V7 and was needed to
> compile troff *et al.*  which actually what conforms with the original
> K&R.   Indeed, that compiler used libS as the library.
 
Ahh, that adds an extra wrinkle to the proceedings :) I wasn't aware of this
version, I was just going on what I disassembled and what I could dig up from
unix sources, but neither am I too surprised that there were intermediate
steps in between!

> So, unless anyone else can illuminate, I'm not sure where the first cpp
> that some of us using v6 had originated.
> 

It is as you note, a very confused picture where there was a lot of activity
from several different sources. It's pretty amazing to look at the UNSW and
Usenet archives and see the sheer volume of device and library hacks that were
going on during the v5 and v6 period alone.

On a related question, do we know that sources for code such as the ching
binaries was at least around at the time of the 32V port? I'm unsure when the
sources were lost, was that after V7? A reason I ask is that phx basically
remained untouched but the 32V version of cno was definitely changed in the
early BSDs, although it may have been a binary patch.

-- 
I love deadlines. I love the whooshing noise as they fly by.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
@ 2020-01-10 14:27 Noel Chiappa
  0 siblings, 0 replies; 21+ messages in thread
From: Noel Chiappa @ 2020-01-10 14:27 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Clem Cole <clemc@ccc.com>

    > So, unless anyone else can illuminate, I'm not sure where the first cpp
    > that some of us using v6 had originated.

I recall a prior extensive discussion about 'cpp'. I looked, and found it
(March 30, 2017) but it was a private discussion, not on TUHS (although you
were part of it :-). Here are clips of what I wrote (I don't want to re-post
what others wrote) from what I wrote, which tell most of the story:


There were a series of changes to C before V7 came out, resulting in the
so-called 'phototypsetter C compiler' (previously discussed on TUHS), and they
included the preprocessor. There's that series of short notes describing
changes to C (and the compiler), and they include mention of the preprocessor.

[Available here: http://gunkies.org/wiki/Typesetter_C for those who want to see
them.]

The MIT 'V6' Unix (which was, AFAICT, an augmented version of an early version
of PWB Unix) had that C compiler; and if you look at the PWB1 tree online, it
does have the C with 'cpp':

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c

I did a diff of that 'cpp' with the MIT one, and they are basically identical.

----

I went looking for the C manual in the V6 distro, to see if it mentioned the
pre-processor. And it does:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/c/c5

(Section 12, "Compiler control lines", about half way down.) So, I'm like,
'WTF? I just looked at cc.c and no mention of cpp!'

So I looked a little harder, and if you look at the cc.c in the distro (URL
above), you see this:

	insym(&defloc, "define");
	insym(&incloc, "include");
	insym(&eifloc, "endif");
	insym(&ifdloc, "ifdef");
	insym(&ifnloc, "ifndef");
	insym(&unxloc, "unix");

The pre-processor is integrated into 'cc' in the initial V6. So we do have a very
early version of it, after all...

----

So, 'cc' in V5 also included pre-processor support (just #define and #include,
though):

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c

Although we don't have the source to 'cc' to show it, V4 also appears to have
had it, per the man page:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/cc.1

"If the -p flag is used, only the macro prepass is run on all files whose name
ends in .c"; and the V4 system source:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys

also has .h files.

No sign of it in the man page for cc.1 in V3, though.


This all makes sense. .h files aren't any use with[out] #include, and without
#include, you have to have the structure definition, etc in multiple source
files. So #include would have gotten added very early on.

In V3, the system was apparently still in assembler, so no need.

-----


Also, there's an error in:

    https://ewe2.ninja/computers/cno/

when it says "V6 was a very different beast for programming to V7. No c
preprocessor. The practical upshot of this is no #includes." that's
clearly incorrect (see above). Also, if you look at Lions (which is pure
early V6), in the source section, all the .c files have #include's.

      Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
@ 2020-01-07  1:58 Noel Chiappa
  0 siblings, 0 replies; 21+ messages in thread
From: Noel Chiappa @ 2020-01-07  1:58 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Warner Losh <imp@bsdimp.com>

    > There's no wupus source before V7.

If you look at Clem's original message:

    >> From: Clem Cole <clemc@ccc.com>
    >> Date: Mon, 6 Jan 2020 16:08:50 -0500

    >> You got my curiosity up and found the V5 and V6 source code

(the one Will was replying to), Clem's talking about the source to crt0.s,
etc.

     Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
  2020-01-07  0:40 Noel Chiappa
@ 2020-01-07  0:44 ` Warner Losh
  0 siblings, 0 replies; 21+ messages in thread
From: Warner Losh @ 2020-01-07  0:44 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Mon, Jan 6, 2020 at 5:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Will Senn
>
>     > On another note,You said you looked in v5 and v6 source code? I
> looked
>     > at tuhs and didn't see anything earlier than v7. Where did you find
>     > them?
>
> Huh? https://www.tuhs.org/cgi-bin/utree.pl


There's no wupus source before V7.

Warner

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] wump.c for v6
@ 2020-01-07  0:40 Noel Chiappa
  2020-01-07  0:44 ` Warner Losh
  0 siblings, 1 reply; 21+ messages in thread
From: Noel Chiappa @ 2020-01-07  0:40 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Will Senn

    > On another note,You said you looked in v5 and v6 source code? I looked
    > at tuhs and didn't see anything earlier than v7. Where did you find
    > them?

Huh? https://www.tuhs.org/cgi-bin/utree.pl

	Noel


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2020-01-10 14:28 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-06  6:13 [TUHS] wump.c for v6 Will Senn
2020-01-06 15:20 ` Clem Cole
2020-01-06 15:24   ` Clem Cole
2020-01-06 16:25   ` Will Senn
2020-01-06 16:35     ` Clem Cole
2020-01-06 18:29       ` Warner Losh
2020-01-06 18:38         ` Will Senn
2020-01-06 18:48           ` Warner Losh
2020-01-06 21:08             ` Clem Cole
2020-01-06 21:38               ` Clem Cole
2020-01-06 22:14                 ` Warner Losh
2020-01-06 23:46                 ` Will Senn
2020-01-07 20:04             ` Sean Dwyer via TUHS
2020-01-07 21:08               ` Clem Cole
2020-01-08  6:35                 ` Sean Dwyer via TUHS
2020-01-06 19:10           ` Bakul Shah
2020-01-06 20:29             ` Will Senn
2020-01-07  0:40 Noel Chiappa
2020-01-07  0:44 ` Warner Losh
2020-01-07  1:58 Noel Chiappa
2020-01-10 14:27 Noel Chiappa

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