Browse Prior Art Database

Analysis of Complex Assembler Programs

IP.com Disclosure Number: IPCOM000122147D
Original Publication Date: 1991-Nov-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 91K

Publishing Venue

IBM

Related People

Brandon, M: AUTHOR

Abstract

A utility computer program (tool) for analyzing assembler programs is disclosed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Analysis of Complex Assembler Programs

      A utility computer program (tool) for analyzing assembler
programs is disclosed.

      Assembler programs often contain many conditional branches, so
that there will be a very large number of different flows of control.
Such a program cannot be comprehensively tested within an acceptable
time.  For example, if there are only 20 independent conditional
branches, then over one million executions of the program are
required to ensure that every possible path through the program has
been tested.  In a practical situation many programs contain far more
than 20 conditional branches.

      Any tool that attempts to perform some kind of flow-of-control
analysis may suffer an unacceptable performance for this reason.
Thus, practically useful tools need to perform their analysis, or
limit their analysis, in some way that does not involve following
each and every possible flow of control through the program being
analyzed.

      An assembler program consists of one or (usually) more FLOW
UNITS, where a FLOW UNIT is one or more assembler statements ending
with a branch of some kind.

      To explain the operation of the analysis tool it is necessary
to make some simplifying assumptions.  One of these is that control
is only passed to a flow unit at determinable place, such as the
first statement or at a label.  The state changes for each flow unit
can then be analyzed.

      A flow unit ends with a branch to a flow unit.  If the state
changes are analyzed through all the flow units in the program being
analyzed it is found that the target of a branch may also be the
target of another branch. Alternatively, control may also be passed
by simple sequential flow of control.  In any case, it is possible
logically to combine the states as determined by the "from" flow
units to determine a worst-case state at a branch target.
Assumptions
i)   While this theory of logically combining states will work, there
can be exceptions.  Fortunately, these exceptions occur very rarely.
An example is when an address is computed from the sum of the
contents of two registers, X and Y.  Suppose that one path of control
sets X to a valid address and Y to zero while another path sets X
to zero and Y to a valid address.  The disclosed logic will then
falsely flag a possible program check.
ii)  The distinction between valid and invalid addresses is not
always clear, and simplifying assumptions may need to be made.  Thus,
in, for example, IBM System/370* architecture, absolute...