[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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.
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
> 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
[-- 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 --]
> 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
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 #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 --]
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.
> 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