In an operating system environment, a program must be processed by the linkage editor program before it can be executed. During the process it is usually relocated, that is, assigned a starting location in main storage other than the locations assigned during assembly. Most programs are run more than once. A standard subroutine may be stored in a part of the system library in relocatable form and be used very frequently. A different core location may be assigned each time. We know that the storage location indicated by the START assembler instruction is tentative. The locations calculated by the assembler merely establish the relative storage locations of data and instructions within a program.
Most programs are assembled relative to zero, but are never executed there because of restrictions on the use of lower core. System/360 was designed to run under a control pro-gram, and, under operating conditions, part of the control program is always resident in the low region of main storage for handling interruptions, error recovery routines, etc. In many systems this occupies several thousand bytes.
Problem programs must be executed beyond this area.
Relocation is necessary for a number of other reasons not of direct interest to the programmer. These are (1) the overall storage requirements of other programs that are to go into core at the same time and (2) various operating considerations dependent upon the type of installation, operating system environment, etc.
The Linkage Editor
When the capabilities of the linkage editor are added to program relocatability, great programming efficiency can be achieved by dividing a large program into separate sections for coding. Each section can be written by a different programmer and compiled and checked out separately. It is even possible to code some of the subroutines in a different programming language. Each part of the programming operation is greatly simplified. Time is saved by having several people work independently and simultaneously on the program. When all the routines have been compiled, they are in relocatable form and can be link edited in any sequence. The linkage editor will assign storage locations and match up all address references between the routines, so that the entire program can be executed correctly as one program. If it should be necessary to correct a routine, only that one routine would have to be reassembled or recom-piled and then link edited again with the other routines.
This facility also makes it relatively simple to maintain a large program that may have to be updated from time to time.
The output of the assembler (or any language translator) is called an object module. It may consist of a single program or many. We should perhaps use the more exact term control section. A control section is the smallest separately
reloca-the programmer by use of reloca-the START statement or anoreloca-ther assembler instruction called CSECT. A program may consist of one control section or many control sections.
In an operating system environment, an object module has two major characteristics:
(1) It is relocatable. This means that a11 address constants are in a form that can be modified to compensate for a change in the starting location.
(2) It is not executable.
The object module may call for other object modules assembled at other times and stored in the system Hbrary in relocatable form. Programmers frequently indicate standard I/O or other object modules to be included as subroutines in a new program. This is perfectly feasible. The linkage editor, which is a service program, will find all required modules, process one after the other, and combine them into a single, executable load module (or program phase, as it is called in some systems).
In Chapter 1 we described the output of the assembler program. The major items of input to the linkage editor program are the object code (or text), the external symbol dictionary (ESD) , and the relocation dictionary (RLD).
(Linkage editor control cards are also included, but wfl1 not be covered in this book.)
The text consists of the actual instructions and data fields of one or more control sections in the module. The diction-aries contain the information necessary for the linkage editor to resolve references between different modules.
F or each control section in an assembly, the ESD contains its length in bytes, assembled address, and any name given in the START or CSECT statement. Also included is infor-mation about any V-type address constants, external references (a linkage symbol used in this control section but defmed in another), and entry points (a linkage symbol defmed in this control section but used in another).
The relocation dictionary contains all address constants that appear in an assembly. RLD information includes (1) the control section in which the adcon is used as an operand, (2) the control section in which it is defmed, (3) whether it is a V-type or other type, (4) how long it is, and (5) the assem-bled address where it is stored.
The linkage editor, working under control of the job control program, builds up composite dictionaries of the ESD and RLD data found in the object modules. It resolves all linkages between different control sections as if they had been assembled as one object module. It relocates each con-trol section as necessary and assigns the entire load module (or program phase) to a contiguous area of main storage. It adds the relocation factor to the location given by the assembler's location counter at the start of each assembly.
I t modifies all relocatable address constants to contain the relocated value of their symbols. (Except for adcons, no
changed during link editing. These remain in base and dis-placement form, as we shall see shortly in the dumps of the next program.) The load module is constructed by building the text in the form in which it will actually be loaded into core; it is then executable and nomelocatable.
In the last program, Figure 8-5, statements 6 through 11 and 16 through 21 were necessary to link to the subroutine, communicate data both ways, and get back to the right point in the main program. We had to be very careful about boundary alignment and using the correct standard linkage registers for the right functions. In DOS all of this can be taken care of very simply by use of the CALL macro, which generates instructions similar to the six statements in the last program. In the program in Figure 8-7 CALL appears in statements 7 and 18.
The CALL macro instruction was designed primarily for use with separately assembled programs to pass control from one program to a specified entry point in another. It works equally well within a single assembly, however, because the assembler and linkage editor carry out their functions just
LOC OBJECT COCE ACDRl ACDR2 STMT SOURCE STATEMENT
Figure 8-7. A slightly different version of the program in Figure 8-5, modified by use of two macro instructions, CALL and PDUMP
the same. As our program example is organized, the macro requires (1) the symbolic address of the entry point (AVER) as operand, which generates a V-type address constant, and (2) the separate ENTRY AVER statement.
Since this is not a typical example of the ENTRY assembler instruction, it would be preferable to wait for the next program example before discussing it. The addresses of the parameter lists also appear in the operand field of the CALL macro, in parentheses, and will be in register 1 (the parameter list register) when the called subroutine is entered.
The first three literals that appear at the end of the assembly appeared in the instructions generated by the PDUMP and CALL macros. As it was written, the CALL generates a V-type address constant rather than the A-type.
We note that zeros and not the address of AVER are assem-bled in statement 80. This address will be supplied later by the linkage editor.
Our plan for the program shown assembled in Figure 8-7 is to have it link edited, and, using linkage editor control cards, have it loaded and executed first at storage location 300016 , and then at 400016 • Re-assembly is not necessary. The linkage editor can override these cards, but will accept the instruc-tions if they' do not create a problem.' Normally the programmer is not involved in the question of where a pro-gram is to be loaded. The storage area from which a propro-gram executes is pro~er1y an ope~ational, not a programming, decision.
The DOS PDUMP macro causes the system, during pro-gram execution, to print out a hexadecimal dump of all the registers and any particular area of storage we are interested in. Such a dump is often used for program checkout, and
The programmer must supply two address expressions in the operand field of the PDUMP to show the beginning arid end of the storage area wanted. One or both of the addresses may be given in registers, but, since we want a dump from two different core locations, we use symbolic
addresses. BEGIN will give us the beginning of the program, and BEGIN+200 is more than enough space to take us through to the end, as we know from the previous assembly of a similar program. Execution of the PDUMP macro will make no difference in execution of the program; processing will continue with the next sequential instruction. (Some other types of dumps result in termination of the program.) Reading a Dump
Figure 8-8 shows the entire dump that was printed out (this is done by a line printer) during the first execution of the program in Figure 8-7. After assembly the program was link edited, loaded at 3000, and executed almost to the end.
The point at which we see the dump is imffiediately after execution of the PDUMP macro. The EOJmacro instruc-tion has not yet been reached.
A hexadecimal format is used because it represents the binary contents exactly. The contents of all the registers are shown at the top of the printout. General registers 0-7 are in the first line,and 8-15 in the second,
a
fulIword each.The double word floating-point registers 0, 2, 4"and 6 are in the third line.
Next comes the hex dump of main storage. The Six-digit column at the left shows the storage location of the first byte in each line. There are 2016 (or 3210 ) bytes to a line, divided into fullwords. Locating an address is simplified by the wide space' in the center of each' line; the next byte zeros at the end is suppressed.
At the extreme right, any alphameric characters in a line are also represented in characters. In many cases this is very helpful in interpreting the hexadeciinal material and speeds up analysis of a dump. It is not particularly useful in our progra!n, however, so the characters will be omitted ,to let us get a closer look at ~he hex. The reader. may wish to arm
GR 0-7 00003120 00003118 OCOOFFFF 00002800 GR 8-F 00004142 OA0407F1 OCOC2810 40003002 FP REG 4431F800 8F5C28F5 4431F800 8F5C28F5
COOOFf84 FFfFFf7C 00000085 00002798 CC003698 OC003090 0000303C 00003008 4752F1E8 6828F5C1 02000000 BOOOOOOO 003000 05B041DO B08E58FO 812641EO B016051F
003020 5060804E 4100B08E 070C58FO B12641EO 003040 4100BI1E OA020AOE OCCCC038 00000040 003060 00C00013 OOOOOOOF 000C0006 OOCCOCOB 003080 F~FFFFFF OOOOOOOE 0000C003 00000000 0030AO 00003008 00003000 60003034 OOOOFFFF 0030CO 00002798 00004142 OA04C7f1 00002810 0030EO 00004160 00045845 00C01874 8B700C02 003100 901C1D24 58510004 50350000 98ECOCOC 003120 00003000 00003200 00003008 OOOOOCOI 003140 00000000 --SAME-~
003lEO 00000000 00000000 00000000 00000000
OC003054 00003084 58608046 5A60804A BC3A051f 00003068 000b3088 41108116 CC000085 00000004 O~COOOA OOOOOOOC OC000002 00000004 FFfFFFFO 00000005 OCOOOOOO 00000000 00000000 0000303C CC002800 OOOOFF84 FfFFFF7C 00000085 40C03002 00003698 90ECOOOC 05905851 lA755870 904E1822 18335A35 00048756 07FEOOOO 00000000 5858C207 C4E4D4D7 OCOOOOOO 00000000 00000000 00000000 OCOOOOOO 00000000 00000000 00000000
....•.. 0... • ...••••• -••• - ••
himself with the card IBM System/360 Reference Data (see Preface), which is helpful for reading a dump.
Figures 8-9 and 8-10 show the dumps with the program loaded first at 3000 and then at 4000. Key areas have been labelled to help the reader tie the dump listing to the assem-bly listing. In Figure 8-9 at location 3000 is OSBO, which is the object code for BALR 11,0. Next is 41DO B08E, which is for the instruction LA 13,SAVEAREA (see assem-bly listing). Next is the first CALL. Next is S860 B046 for the instruction L 6,A. In this way, the entire program was
entered into storage and the registers, instruction by instruction and DC by DC, just as it appears in the object code. This dump was printed after execution, however, and therefore the storage areas and registers affected by the instructions have been altered in accordance with the opera-tions they specified.
Let's see what happened when execution of this program began. The linkage editor supplied the starting address 3000, and the program was loaded starting there. BALR was executed; it put the current address from the PSW (by now
BASE
TlALI? 11. 0 AVERt
t
AVER2 AOOR~SS ATJT)RcSS OF I<ETURN SAVE AREA AlJfJRESSAOORESS OF
$ (JBRO(JTlNE GR 0-1 00003120100003118 OCOOFFFF
40~~~g~~y!
CCOOFF8'GR 8-F 00004142 OA0401F1 OCC02810 CC003698
FP REG 4431F800 8F5C28F5 4431F8CO 8F5C28F5 4752F1E8 ~~~~~~~=--/srC4LL
003000 41DO B08 F OC003054 0000 0 4
003020 5060B04E 4100B08E B03A051F 00003068
001040 4100BIIE OA020AOE CC000085 00C04
003060 00000013 OOOOOOOF 000COC08 CCC00002 00000004
0030AO 00003008 00003000 OOOOFFFF CCC02800 0000FF84 FFFFFF7C 003080 FFFFFFFF OOOOOOOE 00000000
(oeoocooo
00000000'5A60B04A 4110B116 OOOOOOOC 00000005 0000303C 00000085 05905851 00048156 C4E40407 00000000 0030CO 00002798 00004142 OA04C7F1 00002810 4CC03002 00003698 90ECoOOC
OOlOEO 00004160 00045845 00C01814 8B700002 lA755B70 904E1B22jlB335A35 003100 901C1024 58510004 50350000 98ECOOOC 01FEOOOO OOOOCOOO 5B5BC207 003120 00003000 00003200 0000300 OOOOOCOI
oeoecooo
OOOOCOOO 00000000003140 00000000 --SAME--
I
0031EO 00000000 00000000 00000000 00000000 \ OCOOOOOO 00000000 00000000 00000000 2 AllCOAlS A DCOIJ LlSTZ START OF LIST! START OF
SU8ROl/TINE-=
A (BEGIN) = V (AV€~) SAVE A~EA THIS IS lOCATION 30D8=
A {8EOIN + X '200V
Figure 8-9. Hex dump of the program (Figure 8-7) loaded at 3000
2NO CALl.
BASE
AOOR~SS
ADlJRcSS OF RETURN A OTJRES5 OF TlALI? 11. 0 AVeRI t AV£RZ SAVE AREA AlJllRES5 $ (JBRO(}T!NE GR 0-7
0000~120/00004118
GR 8-F 000041~2 OA0401F1 FP REG 3F28F5C2 8F5C28F5
OOOOFFFF 00002810 3F28F5C2
0000FF84 00003698
49018C88 ;;.;-=..;:;.;;.:::-..:::;.::..;;::.,::.;:;.;::;..;..:;-/ sr CALL
o 605 F 00004054 0000 08 5A60B04A
B EO B03A051F 4068 4110B116
00000040 00000085 00000 0 OOOOOOOC
~~~~~~~~~OOOOOOOB 00000002 00000004 00000005
00000000 00000000 00000000 0000403C
~~~~~~~~IOOOOFFFF 00002800 0000FF84 FFFFFF7C 00000085 004000
004020 004040 004060 004080 0040AO 0040CO 0040EO 004100 004120 004140 0041EO
~~~~...l:!.~~~~~~~::~~:~00000001 00000000 00000000 00000000 00000000 00002810 40004002 00003698
f
90ECDOOC 05905851 8B100002 1A155B70 904E1B22 1B335A35 00048156 98ECOOOC 01FEOOOO 00000000 5B58C201 C4E40401
2 AllCOAlS
=
A (BeGIN)00000000 00000000 00000000 00000000 00000000 I.IST2 START OF LIST 1 START OF
S(J8I?O(JTINE-SAVE A~EA THIS IS lOCATlON .,.008
= A (BEGIN+X'200:)
2ND CAll.
Figure 8-10. Hex dump of the program (Figure 8-7) loaded at 4000
updated to the next available byte, 3002) into register 11 for use as a base address. We see that 3002 is still in register 11. (Systemj360 uses the rightmost 24 bits of a register for its addressing scheme and ignores the leftmost byte. The 40 here has no effect.)
Next the LA (41DO B08E) puts the address of SA VEAREA into register 13. This address in the instruction is in the form of a base register and displacement. Will it be correct now that the program has been relocated? The address is arrived at by adding 003002 (the contents of base register 11) and 08E (the displacement)
=
003090. The assembly shows 000090 for SAVEAREA, and we shall see that this is where the SAVE macro stores the contents of the registers.Skipping the CALL, the next instruction (5860B046) loads the value of A into register 6. It looks for A in location 003002 + 046 = 003048. In the assembly, at 000048, we have a DC named A for a fullword of decimal value 56 (this is hex 38), and that is the value at location 003048 in the dump. Continuing in the same fashion with the next instruction (5A60B04A), we see that B (7710 or 4D16 ) is added to A in register 6. The total in register 6, which is not affected by any later instruction, is 85. This is the hex equivalent of decimal 133, and it is correct. The next instruction (5060B04E) does indeed store the total of 85 in C, location 003002
+
04E=
003050. where a fullword was reserved by aDS.In this way it is entirely possible to follow the workings of a program. Registers that are not used in a program may have values left over from previous runs-the floating-point registers here, for example. The contents of any register or
storage area that is used during a program will be the result of the last processing in it before execution of the PDUMP.
To check on the matter of maintaining linkages when a program is relocated, let's look at registers 11 (the base register), 14 (the standard return register), and 15 (the stan-dard entry point register) in both dumps. These are different by the amount 1000, the difference between a relocation factor of 3000 and one of 4000. We also note that, beginning at word 4 in the save area (this program does not use words 1, 2, and 3), we have the contents of registers 14, 15, and 0 through 12 as they were in each case when the SAVE was executed. The code and data produced by the CALL macro can be checked fairly closely by going back to the assembly of the program in Figure 8-5. In this program the CALL generated a V -type address constant for the address of the subroutine, and it was assembled as 000000.
The linkage editor supplied the values 30D8 and 40D8 from calculations on ESD and RLD data (although, as we know, a V-type adcon is not really necessary in a single assembly).
The PDUMP generated two A-type adcons, and the linkage editor supplied their new values simply by adding the relo-cation factor (3000 and 4000 in these examples) to the assembled values.
We may also see, from a comparison of the instructions and data constants in both dumps, that the linkage editor does not change any assembled object code except for relo-cat able address constants. To find a storage address, the CPU simply uses a base-plus-displacement calculation. No matter where in main storage a program is loaded, the relative locations of elements within the program always remain the same.
COMMUNICATION BETWEEN SEPARATE PROGRAMS