Re: 6811 Disassembler

[Donald Whisnant <dewhisna@ix.netcom.com>]

> Date: Sat, 15 Apr 2000 10:21:28 +1000
> From: Peter Gargano <peter@ntserver.techedge.com.au>
> Subject: Re: 6811 Disassembler
> 
> Your disassembler works well, as I'm sure others will attest
> to this too. My disassembler is currently functionally identical
> to yours, and is a stepping stone to a larger project I have in
> mind. I wrote it over a two week period, from scratch, because I
> couldn't find any source code I thought worthy of modifying (there's
> a lot of public domain code that is write-only-once!)
> 
> Just to explain a bit more about my own disassembler -
> It uses "alternative" mnemonics that I find easier to read - like
> PUSH and POP instead of PSH and PUL, and I've used mixed case in
> the mnemonics to aid readability. Like Don's, it also does code
> seeking, and warns of indexed jump instructions, as well as the
> fixes for extended but page-0 instructions that are generated by GM's
> xxx compiler. It usually takes me about 5 minutes of running my
> disassembler, searching for jump tables, etc. to get a source listing
> that can be re-assembled to an BIN that's identical to the original
> BIN.
> 
> I don't have any documentation (yet) whereas Don's is comprehensive.
> But, if you can run Don's, mine reads the same control files! I'll
> provide a download link when I clean up a couple of command line option
> issues, and add the symbol insertion facility (ie. label names).
> 
> PG

Peter,

Hey, there's a real idea -- keeping our control files compatible with
each other...  Perhaps we can combine some efforts...

Let me first explain where mine is heading...  I am working toward a
totally generic architecture where each "disassembler" is encapsulated
by a DLL...  These will have a specified export scheme where they can be
loaded at runtime by any software using the disassemblers WITHOUT having
to recompile the host software...  This requires a migration to a Win32
platform (whereas version 1.0 is a 16-bit application)...  Version 1.2
(which is in the works and nearing completion) is the first step in this
migration...  It is a DOS-32 application that has started to define the
C++ classes that will be eventually embedded into a DLL...  This allows
the application itself to be nothing but a wrapper that allows any
disassembler DLL to be used...

By using a SDK, other users can modify existing disassemblers (change
instruction syntax, formatting, etc) or can write their own disassembler
modules and run on the host software...

I've already implemented a DFC (Data File Converter) DLL structure that
allows any application to read/write any datafile format such as Intel
Hex, Motorola Hex, Binary, etc, again without having to be recompiled
when new ones are added and without having to change software...  The
new version 1.2 of my disassembler makes use of these DFC DLL's and so
has a greatly enhanced control file scheme (which is backward
compatible)...  I'm in the process of refining the DFC structure to add
in some property methods -- for example you might want to export an
intel hex file with 16 bytes per line instead of 32 (that would be a
"property" of the intel hex dfc) -- a reason for such a property is that
the PIC MPLAB software (at least the older PIC-Start programs) choke if
there is more than 16 bytes defined per line...  Each DFC might have
different properties (like a Motorola hex converter would have
S19/S28/S37 file switches for 8-bit, 16-bit, etc) -- the difficulty
comes in definiting a totally generic system where the wrapper software
knows absolutely nothing about the particulars of these properties but
yet can support them, setup a reasonable default, and allow the user to
set them within a defined operating range...

The disassemblers will be very similar, only more involved as there are
many more properties and factors -- such as differences between 8-bit
and 16-bit processors, or Von Neuman architecture verses Harvard or even
Super-Harvard as used by some DSP's...  The goal is total genericness...

It sounds like your alternate 6811 disassembler would be a good example
of an additional disassembler wrapper to mine...  In other words, it
could be written as a "derived class" that overrides 2 or 3 functions
and gives you the exact functionality you are wanting without having to
start from scratch...

My problem is that I have so many projects going on, it is hard to find
time to work on my disassemblers and file converters, which means I
cannot guarantee a certain date of completion...

I don't know what plans you have for your disassemblers, but I'm sure
everyone will benefit if there is at least some level of compatibility
between them...  Even if it is nothing more than control files...

My next SDK release related to this project will probably be the DFC's
by providing the DFC's along with examples of usage and libraries to
create extensions and new DFC's...  So you may want to consider adding
that to your disassemblers as well...

So stay in touch and keep me posted on development, and I'll do the same
for you and the group...

Donald
----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo@lists.diy-efi.org