Download A Sample Program on Assembly Language Programming 1 | CPSC 3121 and more Study notes Programming Languages in PDF only on Docsity!
A Sample Program
This lecture will focus on a sample program that was assigned for all students to execute on the mainframe. This program is run under the IBM operating system called OS (as opposed to DOS), which is tailored for large installations. Please note that the IBM mainframe operating system DOS is not related to that once used on small computers. The latter, often called “DOS” is really MSDOS, the Microsoft Disk Operating System. This lecture contains both code fragments and annotations on those code fragments. Code fragments will be presented in the font Courier New (bold), as follows. SAVE (14,12) All other material will be in the standard font Times New Roman, as is this sentence. The student will recall that the input to the assembler is not free–form; column placement is extremely important. Your instructor discovered this fact when an otherwise correct program would not assembly correctly.
Column Conventions in the Assembler Program
The column conventions are as follows: Columns 1 – 8 The name or label of the statement or declarative Column 9 This must be blank Columns 10 – 14 The operation: instruction, declarative, or macro Column 15 This must be blank Columns 16 – 71 The operands for the operation. Any continuation line must begin in column 16. Column 72 If nonblank, the next line is a continuation of this one. Consider the following example, taken from the sample program. PRINTER DCB DDNAME=PRINTER, X DSORG=PS, X DEVD=DA, X MACRF=(PM), X LRECL=133, X RECFM=FM The label PRINTER is placed in columns 1 – 7 The DCB macro is placed in columns 10 – 12 The arguments are placed in columns 16 – 71, the continuation mark is in column 72.
Column 1
Here are the rules for use of column 1 in the assembler. Note, that we are not speaking of the first non–blank entry in a column, but column 1. Consider the following, with the columns displayed above the operation and operands 0000000001111111111222222 1234567890123456789012345 AR R1,R2 ADD REGISTR R2 TO R Note that column 1 contains a blank. Column 10 is the first non–blank column. If column 1 contains an “*”, the entire line is treated as a comment. 0000000001111111111222222 1234567890123456789012345
- THIS ENTIRE LINE IS A COMMENT If column 1 contains an alphabetical character, it is the start of a label. The label continues from column 1 up to the first blank column or column 9. 0000000001111111111222222 1234567890123456789012345 ADD2 AR R1,R2 Label is ADD
Some Common Errors
Consider the following two examples. The first is correct; the second is not. 0000000001111111111222222 1234567890123456789012345 AR R1,R2 ADD REGISTR R2 TO R This one should work as advertised. Note that the first blank space after the expected operands marks the start of an in–line comment. Now consider the following. 0000000001111111111222222 1234567890123456789012345 AR R1,R2 ADD REGISTR R2 TO R Here the two characters “AR” are taken as the label, because the “A” is in column 1. The assembler attempts to interpret “R1” as an operation, and fails. How about this one, which is also incorrect. 0000000001111111111222222 1234567890123456789012345 AR R1, R2 ADD REGISTR R2 TO R Here the problem is the space after “R1,”. The string “R2” is taken as starting the comment field. Because of the space, it is not an operand.
Job Control Statements
In order to understand the structure of the sample program, one must imagine a “batch job”, which is a sequence of cards submitted to the computer. Your input file comprises a sequence of lines of text. Each line of text should be viewed as a “card image”, basically eighty characters with some of them blanks. Here is the job control language from my submission of the program. //CSU0003A JOB (ASSY),'ED BOZ',CLASS=A,MSGCLASS=A, // NOTIFY=&SYSUID,MSGLEVEL=(0,1) //ASM EXEC PROC=HLLASMCLG //SYSIN DD * Each student should employ a unique job name based on the user ID (mine is obviously CSU0003). The job name is the seven character User ID with a single letter appended. It appears that the letter can be arbitrary and need not be changed. The HLLASMCLG directive seems to direct the assembler to “compile, load, and go”; that is, to execute the code generated. The SYSIN DD* directive indicates that the input for the assembler will be found in the lines of text just following.
Assembly Language Source: Part 1
The first two lines of the code contain macros, which expand to pre–defined sequences of code that direct the execution of the assembler. TITLE 'ED B - FROM SKELETON ASSEMBLER PROGRAM' PRINT ON,NODATA,NOGEN The TITLE macro provides a title at the top of each page of the listing. Note the single quotes at the start and end of the text to be displayed. The PRINT macro specifies the format of the assembly listing. ON The program listing is printed. NODATA Restricts the display of the binary machine language equivalent of each assembler statement to 16 hexadecimal digits. NOGEN Suppresses the generation of the statements to which a macro will expand. In general, a macro will expand into about ten statements. With this option, only the macro itself is listed. We shall later want to use the GEN option when we study macro writing. This will allow us to examine the code expansions of our macros.
Assembly Language Source: Part 3
An Equate directive is used to equate one symbol with another. In the code that follows each occurrence of “R0” will be replaced by “0”, each “R1” by “1”, etc. Use of these symbols allows register references to become visible in the program listings.
R0 EQU 0 R1 EQU 1 R2 EQU 2 R3 EQU 3 R4 EQU 4 R5 EQU 5 R6 EQU 6 R7 EQU 7 R8 EQU 8 R9 EQU 9 R10 EQU 10 R11 EQU 11 R12 EQU 12 R13 EQU 13 R14 EQU 14 R15 EQU 15
Assembly Language Source: Part 4
This block of code is the standard “start up” code used at the beginning of any program to be run on the Mainframe. This code should be viewed as “boilerplate”. The form of this code block suggests that the code is that for a subprogram: either a subroutine or a function. Indeed, that is the way the Operating System handles the execution of any program: it is a subprogram of the Operating System.
LAB1 CSECT SAVE (14,12) SAVE THE CALLER'S REGISTERS BALR R12,0 ESTABLISH USING *,R12 ADDRESSABILITY LA R2,SAVEAREA ADDRESS OF MY SAVE AREA ST R2,8(,R13) FORWARD CHAIN MINE ST R13,SAVEAREA+4 BACKWARD CHAIN CALLER'S LR R13,R2 SET 13 FROM MY SUB CALLS
The first line LAB1 CSECT is a declaration of a Control Section , named “LAB1”. By definition, a control section is “a block of coding that can be relocated (independent of other coding) without altering the operating logic of the program”. Practically, a control section is just one block of assembly code.
The Print Loop
Here is the “main body” of the assembly code. GET FILEIN,RECORDIN GET THE FIRST RECORD
A10LOOP MVC DATAPR,RECORDIN MOVE INPUT RECORD PUT PRINTER,PRINT PRINT THE RECORD GET FILEIN,RECORDIN GET THE NEXT RECORD B A10LOOP GO BACK AND PROCESS
Note that the code at label A10LOOP is executed the first time only if the top line of code has actually returned a record (“card image” or 80 characters of text). On execution of this code at label A10LOOP, we are guaranteed that there is a record in the data storage area associated with the identifier RECORDIN. These eighty characters of text (trailing blanks are included) are copied into the data storage area associated with the identifier DATAPR, and then sent to the output. This code then tries to get another line (card image) of input. If there is more input, the code executes an unconditional branch to the statement A10LOOP, thus continuing the loop. Otherwise, it branches to A90END and closes the program.
The Print Loop (Java Style)
The best way to view this print loop is to add a construct that is used in both Java and C/C++. GET FILEIN,RECORDIN GET THE FIRST RECORD
A10LOOP MVC DATAPR,RECORDIN MOVE INPUT RECORD PUT PRINTER,PRINT PRINT THE RECORD GET FILEIN,RECORDIN GET THE NEXT RECORD If End_of_File Then Break B A10LOOP GO BACK AND PROCESS
The loop is never entered if the first GET statement does not return a record. The loop is exited when the contained GET statement encounters an End of File. Otherwise, the processing continues. Again, the Data Control Block for the input device, FILEIN, specifies the label of the statement to be executed when an EOF is found on the input.
The Standard Closing Code
Here is the standard “postfix code”. It must be the last section of code executed in any program to be run on our mainframe, which is running the IBM OS operating system. ******************* END LOGIC ************************** L R13,SAVEAREA+4 POINT AT OLD SAVE AREA LM R14,R12,12(R13) RESTORE THE REGISTERS LA R15,0 RETURN CODE = 0 BR R14 RETURN TO OPERATING SYSTEM
When your program terminates, it must execute a return to the Operating
System so that the latter can continue execution of another program.
This is the return code required by the operating system.
Defining the Output
The output file is defined using a standard DCB (Data Control Block) PRINTER DCB DSORG=PS, X MACRF=(PM), X DEVD=DA, X DDNAME=PRINTER, X RECFM=FM, X LRECL= The output is to a PS (Physical Sequential) device. The specific unit happens to be a disk file, which supports DA (Direct Access) The name associated with this is PRINTER. The label is obviously used here with two distinct meanings. I shall investigate this. The logical record length is 133 bytes, for 133 characters. Note the continuation indicators in column 72 of each line but the last. These six lines are assembled as one statement. This is the example of invocation of a macro by keywords; each line is of the form KEYWORD=VALUE.
The Input Data Record
RECORDIN reserves eighty bytes of memory storage for use in the input of an eighty–character card image. All input will be assumed to be eighty characters.
RECORDIN DS CL
Future programs will follow a convention familiar to COBOL programmers. We shall still assume 80–column input, but divide it into fields. RECORDIN DS 0CL80 THE CARD HAS 80 COLUMNS FIRSTNME DS CL8 FIRST 8 COLUMNS FOR THE FIRST NAME LASTNME DS CL10 NEXT 10 COLUMNS FOR THE LAST NAME ACCOUNT DS CL12 NEXT 12 COLUMNS FOR THE ACCOUNT NUM FILLER DS CL50 OTHER 50 COLUMNS ARE PROBABLY BLANK. Note the “ 0 ” in the “0CL80” that defines the entry RECORDIN. Each card image must correspond to 80 bytes for 80 characters. The “0CL80” does not actually allocate any space, but serves almost as a comment that the next 80 bytes are associated with input. The next 4 statements allocate the 80 bytes.
Sample Input Data Record: Reading Positive Integers
Suppose that we wanted to read a list of five–digit numbers, one number per “card”. Each digit is represented as a character, encoded in EBCDIC form. The appropriate declaration might be written as follows. RECORDIN DS 0CL80 THE CARD HAS 80 COLUMNS DIGITS DS CL5 FIVE BYTES FOR FIVE DIGITS FILLER DS CL75 THE NEXT 75 COLUMNS ARE IGNORED. In this, the first five columns of each input line hold a character to be interpreted as a digit. The other 75 are not used. This input is not free form. Based on the above declaration, one would characterize the first five columns as follows:
