The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jam@magic.com (James A. Markevitch)
Subject: [TUHS] Query on PDP-11 assembly
Date: Wed, 30 Apr 2008 09:20:08 -0700 (PDT)	[thread overview]
Message-ID: <200804301620.JAA10112@mist.magic.com> (raw)

> I can happily deal with the   jsr pc,do   type of jsr, but the ones
> involving r5 have me stumped, e.g.:
> 
>         jsr     r5,questf; < nonexistent\n\0>; .even

I have encountered this type of construct a lot when doing disassemblers
over the years.  My usual strategy for dealing with this is:

1. If it's quick and dirty and I am not running huge amounts of code,
then the disassembler allows the user to provide a list of "hints" to
it.  The hints for this would describe the arguments to each subroutine.
For illustrative purposes, you might have a side file that contains
the following:

	subr 002004 questf string

meaning that location 002004 is a subroutine names questf that expects
a null-terminated string as the argument.  As an additional benefit,
you get a nice name for the subroutine that the disassembler can put
into the output.

And if a subroutine takes two 16-bit arguments, you might have:

	subr 003436 mysub arg16 arg16

If the disassembler identifies each of the targets of the jsr
instructions, then you can usually do a quick look at the code to
see what it expects, then add to the side file, then re-run the
disassembler.

2. If you want to be less quick and dirty, you can have the disassembler
do a partial flow analysis of the code to figure out what is expected
for arguments.  This is usually much more involved and you still often
need to add hints for cases where the '60s or '70s programmer did some
kind of "neat trick" when coding.

My philosophy on these is to use tools to get to the 95%+ level of
automation and provide hints to pick up the rest.  Using strategy
number 1 above will probably get you a lot of success with a small
amount of coding in your disassembler.

James Markevitch



             reply	other threads:[~2008-04-30 16:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-30 16:20 James A. Markevitch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-04-30 11:56 Warren Toomey
2008-04-30 13:55 ` Brantley Coile
2008-04-30 14:41   ` Naoki Hamada
2008-05-01 23:47     ` Warren Toomey
2008-04-30 16:53   ` Milo Velimirovic
2008-04-30 17:00     ` Larry McVoy
2008-04-30 17:47       ` John Cowan
2008-04-30 17:59         ` Larry McVoy
2008-04-30 15:08 ` Carl Lowenstein

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=200804301620.JAA10112@mist.magic.com \
    --to=jam@magic.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).