8192 protocol command list and disassembly

DAVE_HEMPSTEAD at HP-Andover-om3.om.hp.com DAVE_HEMPSTEAD at HP-Andover-om3.om.hp.com
Thu Feb 11 17:10:14 GMT 1999


Thanks for the proposed command which dumps out a memory location  (F4 58 03 HI 
LO CS).   I'll look in the code in the 16188051 sofware and see if it is the 
same.  I know that it supports the F4 command, I'll check for the 58 message.


As for disassemblers, there are some on the net, or you can buy one (don't ask 
me where).  As for me, I wrote my own.  I wrote one which works on the 16188051 
binaries (the .e and .t files).  Also, Tom Sharpe has one, and has run this code
thru it.  However, what I found most disassemblers do is to simply print out the
instruction mnemonic for the given hex byte for the addresses.  While this does 
meet the minimum requirement (print out the mnemonics), it is only a first step 
for reverse engineering the code.  I've found the need for more tools.  What I 
ended up adding included:
      1.  Finding all addresses that are branched to, jumped to, or called.  
Without this, you don't know how you got to a certain address, or how many 
places go to this address.  This is critical (for me at least) in order to 
understand the code.  So, I print a label on all of these addresses.  I also 
then print out a cross reference of each label and who branches/jumps/calls it.
      2.  Finding all references to other memory locations.  For example, you 
want to find who accesses the ALDL data port.  Well you can search forever, or 
your disassembler tool can find all references to all memory locations that are 
not in the executable/code space.  Then I print out all these memory locations 
and all their cross references.  Again, a useful tool.

      3.  My latest efforts have been to go the next step and attempt to put 
some structure to the code.  Just last night I was able to take my assembly 
code, and run it through a tool which puts IF/THEN/ELSE structures onto it.  
This problem has had me stumped for a couple of weeks because the code appears 
to have been generated by an optimizing compiler.  What this means is that 
common instructions were found by the compiler, and moved to one place, and then
the other code jumps to these common instructions.  Anyway, I think I've 
unraveled it, and now am able to display the code with a high-level-like 
indented IF/THEN/ELSE structure.  I plan to update my web page with this listing
in the near future  (www.geocities.com/MotorCity/Shop/1624).  Of course, upon 
seeing this output, I want to go another step.  So:

     4.   The mnemonics are readable, but it would be clearer to convert them 
into higher-level-like instructions.  For example, you might have a mnemonic 
called TAB.  I'd rather see an instruction which said "B = A".  I'm going to add
this next.  This is not a hard problem.


   Anyway, I've rambled on for too long.  Just thought I'd update everyone on 
where I'm at.

Dave Hempstead




More information about the Gmecm mailing list