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.

Sent from my iPhone On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc(a)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.

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 11:38 AM Will Senn <will.senn(a)gmail.com> wrote: 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

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(a)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(a)bsdimp.com> wrote: > >> >> >> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)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 >> >

On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)gmail.com> wrote: 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

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.

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

On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn(a)gmail.com> wrote: 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.