🚀 go-pugleaf

Here at JPL one of the senior software engineers has developed a disassembler
for the 68000/68010, running on (and currently only tested on) Sun-2's.
Unlike the somewhat widely distributed `unc' disassembler, this one operates
in `interactive' mode, meaning that as opposed to `unc' (which I will call
a `compiled' mode) this program begins output immediately.  To be more 
specific:
	- `unc' acts more or less like a compiler might.  It disassembles the
whole file into a file that can be re-input to `as', with symbols added where
necessary.  It also handles the data segment gracefully, with `.asciz' and
`.ascii' directives where necessary, and `.word', `.long' etc.

The problem with this approach is that you don't get your output until the
complete disassembly is done.  For large executables, this is not only
untenable (run it overnight), but also there is no way to specify to just
disassemble a section (say, a subroutine beginning with LINK and ending
with RTS).  The resulting ASCII disassembly could eat up all your free disk
space if the executable is large (hint: try `unc emacs' :-)

Many applications require being able to disassemble from a specific address
or routine in an executable.  You want to be able to just go there, quick
and dirty, and start spilling out addresses, machine instructions (another
thing that `unc' does not do), and instruction mnemonics.

This is what our disassembler does.  It takes a filename, and begins the
disassembly from the beginning of the text segment (usually 0x8000) if no
additional parameter is specified; one can specify an address or a symbol
and the disassembler will begin there.

Another feature which is extremely useful is that if the file is compiled
with -g or -go, it understands the (at least Sun's) symbol table format,
and will tag instructions with the corresponding source file line.

Originally this dissassembler would just begin dumping to stdout.  I hacked in
a little built-in pager which determines screen size, and the program will
by default put up a screenful at a time; like `more(1)' a space will get the
next screenful (with 2 lines overlap for context), and a <return> will get
the next line (this code is easily rip-outable, if you just wish to always
pass the output to `more' or `less', or I suppose you could fork either of
those and pass the data down the pipe.).

Anyhow, as of right now, this program exists as a useful hack (i.e. not much
in the way of comments, a few kludges here and there, known bugs, etc.).
I would like to be able to get it presentable for beta-testing, with eventual
submission to mod.sources when it's cleaned up its act.

* What I need from someone out there is some sort of a Test Suite that is
a source file (preferably Unix `as' format; I'll take Motorola format if
all else fails) which contains as many instructions of the entire instruction
set as possible, and with as many (i.e., hopefully all) of the addressing
modes for each instruction as you can get.  The program doesn't have to *do*
anything, just meet these criterion.  Obviously, the intent is to be able
to `as' this file, run the disassembler on it, and compare the results against
the original to see how many instructions/modes it f*cks up on (i.e., bugs).

I would like to get as many of these bugs out as possible before asking for
beta-test sites.  Also, 68020 support is planned `someday' (since we have
a Sun-3 which it isn't much good on).

Obviously I could do this myself, given much *pain* and *time* - of which I
have neither.

I'm hoping someone out there may have already done so already, and can spare
me the effort.

Thanks very much.
-- 
	Greg Earle		UUCP: sdcrdcf!smeagol!earle; attmail!earle
	JPL			ARPA: elroy!smeagol!earle@csvax.caltech.edu
				      earle@JPL-MILVAX.ARPA
				AT&T: +1 818 354 0876

With YOU, I can be MYSELF..  We don't NEED Dan Rather..