Specifications





 Page 10 





Output files

By default,

DASMx

generates a disassembly listing file. This is similar to the full

listing file generated by most assemblers. Optionally,

DASMx

can be made to

produce an assembly file instead. This could then be used as a source file to an

assembler of your choice (with certain provisos concerning pseudo-ops and

number formats noted later).

As an aid to readability,

DASMx

inserts a comment line after all breaks in a

sequence of instructions (e.g. after an unconditional branch or jump, or a return

from subroutine). Comment lines are also inserted between code and data areas.

This use of comment lines breaks the output listing into identifiable sections and

aids manual inspection of the resultant disassembly listing.

Note that output files tend to be large. For example, a 32 Kbyte ROM image will

generate a listing file of around half a megabyte in length.

The output file is named based upon the name of the source image file, but with a

file extension of ".lst" for the list file or ".asm" for the assembly output file.

Listing file

The list file format is largely self-explanatory. Program counter and code/data

byte values are given in hex. Code/data is also shown as ASCII characters (where

printable) as an aid to identifying strings within the binary image. If the wide

listing format is selected then instruction cycle counts are also given for every

instruction.

Instruction cycles are shown within [square braces]. If an instruction takes a

variable number of cycles to execute (e.g. a conditional branch on many

processors) then two values are shown: the minimum and the maximum.

Code threading

Code threading is a very powerful feature that will automatically identify known

areas of code. It can prove particularly useful in the early stages of disassembly of

an image that contains large areas of data. Such data areas would otherwise be

disassembled incorrectly as code and would add many erroneous symbols to the

symbol table.

Code threading works by performing a partial emulation of the processor;

executing instructions starting from one or more known entry points. Code

threading follows calls to subroutines and conditional and unconditional branches.

In certain cases, the code threading may fail to follow certain code paths (i.e.

leaving valid code still defined as data). The following are examples of where the

code threader will fail to follow a correct execution path: