Browse Prior Art Database

Process to Convert Assembler Language Programs to Decision Tables

IP.com Disclosure Number: IPCOM000089706D
Original Publication Date: 1977-Dec-01
Included in the Prior Art Database: 2005-Mar-05
Document File: 5 page(s) / 126K

Publishing Venue

IBM

Related People

Cenfetelli, AR: AUTHOR

Abstract

Code development can be accomplished faster and with greater accuracy if the technique of decision tables is applied to the process. A computer-aided method to convert existing Assembler language coding into a decision table format is presented.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 5

Process to Convert Assembler Language Programs to Decision Tables

Code development can be accomplished faster and with greater accuracy if the technique of decision tables is applied to the process. A computer-aided method to convert existing Assembler language coding into a decision table format is presented.

In this procedure Assembler language statements provide an input in the form of a matrix, where the number of rows in the matrix correspond to the number of Assembler language statements. To create a decision table, the procedure is used, specifying the name of the matrix containing the Assembler language instructions. The procedure is composed of a number of steps, described below, which analyze the Assembler language instructions and create the decision table.

The first step is to begin creation of an internal table from the matrix of Assembler instructions. The initial internal table will contain the labels, the op codes, the first operand, and the remaining operands of the Assembler input (Fig.
1).

The second step converts "BC Mask, Branch-Label" statements to their extended-mnemonic counterparts, e.g., "BC 8, label" to "BE label". This not only allows easier internal table processing, but also provides easier reading of the code output in the decision table (Fig. 2).

The third step locates all condition setting op codes which are immediately followed by a branch condition instruction and converts them to an internal format for easier processing (Fig. 3).

The fourth step extends the internal table with control fields to control the internal flow of the process in creating the decision table. It does this by sequentially identifying the condition code setting statements and their corresponding branch condition statements for eventual entry into the decision table as conditions. It identifies which statements in the Assembler language program, the "yes" and "no" paths, are to be followed for their respective conditions. It sequentially identifies all noncondition setting statements (except unconditional branches) as Actions for eventual entry into the decision table. It sequentially identifies all branch register (BR) instructions, all branch (B) instructions to an unidentified label, and all branch instructions to a statement previously encountered in the path currently being processed as Exits, which will eventually be entered into the decision table. It also creates additional fields to be used as forward and backward pointers for tracking the paths associated with the branch condition statements and to indicate whether "yes" or "no" path processing is being performed for a given branch condition statement (Fig. 4).

A fifth step, which is optional, converts "negative" branch condition flow in the internal table to "positive" branch condition flow; i.e., "BN" type branch conditionals are converted to "B" type branch conditionals, while still maintaining the validity of the Assembler program logic. This option eliminates...