From: Clem Cole <clemc@ccc.com>
To: Warner Losh <imp@bsdimp.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>, Will Senn <will.senn@gmail.com>
Subject: Re: [TUHS] wump.c for v6
Date: Mon, 6 Jan 2020 16:38:23 -0500 [thread overview]
Message-ID: <CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2M5bpr_SY2VNYpQXTMYbsTQH94WRzJndmm0EJcJdWohhg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2020-01-06 22:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-06 6:13 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC20D2PzZ+4qVE7Tnb0tYiqchzfjWnjkR_SenSrJRTL2E80XKA@mail.gmail.com \
--to=clemc@ccc.com \
--cc=imp@bsdimp.com \
--cc=tuhs@minnie.tuhs.org \
--cc=will.senn@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).