CHAPTER 1 GENERAL DESCRIPTION DOB is an object module disassembler, which will create a MACRO-11 source file from any object module. It will operate on either standard object modules, or object module libraries. The output from DOB can be reassembled directly. The only errors that should be generated will be 'Z' type errors. The resultant object module should be identical to the original object module, if the original object module was generated by MACRO-11. CHAPTER 2 COMMAND SYNTAX The command syntax is as follows: DOB> output/sw,temp=input/sw There are currently four valid switches for the input filespec: "/LB", "/EI", "/FI", and "/FP". The "/LB" switch indicates that the input file is an object library. The switch value is from 1 to 6 RAD50 characters indicating the name of the module to disassemble. An example of this is "DOB TI:=[1,1]SYSLIB/LB:.GET". The default extension for the input file is either ".OBJ" or ".OLB", depending on whether or not there is a "/LB" switch. The remaining input filespec switches indicate which optional instruction sets to use. The default is to use them all. "/-EI" indicates that EIS instructions are not really instructions and should be disassembled as ".WORD xxxxx". "/-FI" indicates that FIS instructions are not really instructions. "/-FP" indicates that FPP instructions are not really instructions. There are two valid switches for the output filespec: "/AS" and "/RA". These switches indicate what additional formats to dump the code, other than instruction. "/AS" indicates that the code should be dumped in ASCII. "/RA" indicates that the code should be dumped in RAD50. If either of these options is selected, the values of the instruction is dumped in the specified format as comments. The default extension for the output filespec is ".MAC". The temp file is used for internal information, and usually doesn't need to be specified. The default filespec is "SY:BITMAP.TMP". This file is temporary, and is deleted when finished with. The only reason a filespec would ever be given for this, would be to cause this file to go to a different disk than the default, since this could be a rather large file. This file contains 16 blocks for each psect in the object module. CHAPTER 3 IMPLEMENTATION NOTES This disassembler consists of five phases: GETCMD, PASS1, PASS2, PASS3, and CLENUP. GETCMD gets the command line, and parses it. It opens all the files, and if the input is an object library points to the corrent object module. PASS1 is the first pass through the object module. This pass looks only at the global symbol directory records. During this pass the PSECT table is built, which consists of the psect name, length, and current address (which is initialized to zero). A count is kept of the number of global symbols so that the size of the global symbol table will be known. After passing through the object module, free memory is initialized. Free memory is used for three things. The first item is the psect table, which starts immediately after the end of used memory, and contains as many entries as there are PSECTs. The next item is the global symbol table, which is allocated immediately after the psect table, and contains all global symbol definitions. This table is allocated after pass 1, and filled in during pass 2. The remainder of free memory is a dynamic memory pool, which is used to hold the code during passes 2 and 3, in a linked list. PASS2 is the second pass through the object module. This pass generates the '.TITLE', '.IDENT', and '.GLOBL' records, and '.PSECT' definition records. The global symbol table, which was allocated in pass 1, is filled in now. This pass examines the instructions and builds a bitmap of all referenced locations in all psects. These bitmaps are kept in the temporary file. PASS3 is the third and last pass through the object module. This pass disassembles the intructions, and writes them to the output file. After disassembling an instruction, the bitmap for the current PSECT is examined to see if any byte of the instruction was referenced elsewhere in the object module. If so, a label is IMPLEMENTATION NOTES Page 3-2 placed at the beginning of the line. If any byte of the instruction was referenced other than the first byte, then after the line has been written to the output file, equates are generated to define the necessary labels. Labels take on one of three forms. If the location is defined as a global symbol, the global symbol name is used. When defining such a symbol, a check is made to see if more than one symbol is defined for the same location. If there is, each global symbol is written to the output file on a seperate line, followed by a colon. Only the last symbol is actually used on the line with the disassembled code. If the location is not defined as a global symbol, the symbol name takes on one of two forms. If there are less than 14 psects in the object module, the symbol name consists of an alphabetic character, followed by five octal digits. The octal digits consist of the low 5 octal digits of the address. The character is generated by using 'A' and 'B' for the first psect, 'C' and 'D' for the second, and so forth. The lower letter is used for addresses in the range 0-77777, and the higher for addresses in the range '100000-177777'. If there are more than 13 psects, the symbol name is generated by using a two character psect identifier, followed by four hex digits indicating the address. The psect identifier is generated by taking the psect number (0-255) and breaking it into two parts by dividing by ten. The result of the division is used to generate the first character (0=A,1=B,...) and the remainder is used for the second (0=0,1=1,...). This may sound confusing and unnecessarily complex, but it was the best scheme I could come up with. The best thing to do is to see it in operation, and that may clear up a lot of questions. CLENUP is the final phase. During this phase, any symbols that have not yet been defined, are. Also, all psects are extended, if they need to be. The reason symbols might not have been defined is due to '.BLKB' or '.BLKW' pseudo-instructions, or disassembling code which isn't actually code. The last thing done is to write the '.END' record. CHAPTER 4 KNOWN PROBLEMS This program still has a few bugs, problems, limitations, and other undesirable features, most of which will be cleared up in later versions. These are as follows. 1) It requires EIS. This shouldn't be too hard to fix, and will be in the next version. 2) It should work fine for almost all MACRO-11 object modules, but might still have problems with object modules created by various compilers, since they sometimes take short-cuts, when generated object code, that weren't taken into consideration when designing this. These problems will be fixed as they show up. 3) The output file, when reassembled can generate 'Z' errors. In the next version there will be a '/NOZ' switch that will cause these instructions to be disassembled as '.WORD xxx'. 4) The error handling is horrendous and should be totally revamped in the next version. 5) If the input file is a concatenated object module, only the first module is disassembled. The program could easily be modified to disassemble all modules, but since MACRO-11 doesn't do stacked assembles, the resultant source file would have to be broken up. If you have any comments, suggested enhancements, fixes, bugs that need fixes, or just have questions about the program, please don't hesitate to contact me. The more input I have output this program, the better I can make later versions of it.