Context:

Our Modification record format is well suited for SIC/XE programs because all address fields in instructions and data words fall neatly into half-bytes. What sort of Modification record could we use if this were not the case (that is, if address fields could begin anywhere within a byte and could be of any length)? Pro The command for the loader, of course, must also be a part of the object gram, We can accomplish this with a Modification record having the following format modified, Modification record: Col. 1 M Col. 2-7 Starting location of the address field to be rel ative to the beginning of the program (hexadecimal) Length of the address field to be modified, in half- Col. 8-9 bytes (hexadecimal) The length is stored in half-bytes (rather than bytes) because the address field to be modified may not occupy an integral number of bytes. (For exam- ple, the address field in the JSUB instruction we considered above occupies 20 bits, which is 5 half-bytes.) The starting location is the location of the byte con- maining the leftmost bits of the address field to be modified. If this field occu- ies an odd number of half-bytes, it is assumed to begin in the middle of the -st byte at the starting location. These conventions are, of course, closely re- red to the architecture of SIC/XE. For other types of machines, the half-byte roach might not be appropriate (see Exercise 2.2.9). For the JSUB instruction we are using as an example, the Modification rd would be 00000705 ecord specifies that the beginning address of the program is to be added eld that begins at address 000007 (relative to the start of the nrogram) 5 half-bytes in length. Thus in the assembled i bits (4B1) will remain unchan the last 20 hito dire ecution of record memory addres program. Finally, the assembler must write put device. This object program will later be machin Header, Text, and End. The Header record contains the program name, star The simple object program format we use contains three types addresses where these are to be loaded. The End record marks the end of code) instructions and data of the program, together with an indication ing address, and length. Text records contain the translated i.e., operand is specified, the address of the first executable instruction is used.) begin. (This is taken from the operand of the program's END statement. If object program and specifies the address in the program where execution is The formats we use for these records are as follows. The details of the mats (column numbers, etc.) are arbitrary; however, the information contain in these records must be present (in some form) in the object program. Header record: Col. 1 H Col. 2-7 Col. 8-13 Program name Starting address of object program (hexadecimal) Length of object program in bytes (hexadecimal) Col. 1419 Text record: Col. 1 T Col. 2-7 Col. 8-9 Starting address for object code in this record(hexadecimal) Length of object code in this record in bytes (hexadecimal) Object code, represented in hexadecimal (2 columns per byte of object code) Col. 10-69 End record: Col. 1 E Col. 2-7 Address of first executable instruction in object program (hexadecimal) o avoid confusion, we have used the term column rather than byte to refer to ositions within object program records. This is not meant to imply the use of ny particular medium for the object program. Figure 2.3 shows the object program corresponding to Fig. 2.2, using this emat. In this figure, and in the other object programs we display, the symbol s used to separate fields visually. Of course, such symbols are not present in actual object program. Note that there is no object code corresponding to dresses 10332038. This storage is simply reserved by the loader for use by program during execution. (Chapter 3 contains a detailed discussion of the ration of the loader.) We can now give a general description of the functions of the two passes of simple assembler. Define record: Col. 1 Col. 2-7 Col. 8-13 D Name of external symbol defined in this control section Relative address of symbol within this control section (hexadecimal) Repeat information in Col. 2-13 for other external symbols Col. 1473 Refer record: Col. 1 Col. 2-7 R Name of external symbol referred to in this control section Names of other external reference symbols Col. 8-73 The other information needed for program linking is added to the Modification record type. The new format is as follows. Modification record (revised): Col. 1 M Col. 2-7 Starting address of the field to be modified, relative to the beginning of the control section (hexadecimal) Col. 8-9 Length of the field to be modified, in half-bytes (hexa- decimal) Col. 10 Modification flag (+ or -) 20 Col. 11-16 External symbol whose value is to be added to or sub- tracted from the indicated field The first three items in this record are the same as previously discussed. The vo new items specify the modification to be performed: adding or subtract- g the value of some external symbol. The symbol used for modification may defined either in this control section or in another one. Fimuro 2 17 Our Modification record format is well suited for SIC/XE programs because all address fields in instructions and data words fall neatly into half-bytes. What sort of Modification record could we use if this were not the case (that is, if address fields could begin anywhere within a byte and could be of any length)? Pro The command for the loader, of course, must also be a part of the object gram, We can accomplish this with a Modification record having the following format modified, Modification record: Col. 1 M Col. 2-7 Starting location of the address field to be rel ative to the beginning of the program (hexadecimal) Length of the address field to be modified, in half- Col. 8-9 bytes (hexadecimal) The length is stored in half-bytes (rather than bytes) because the address field to be modified may not occupy an integral number of bytes. (For exam- ple, the address field in the JSUB instruction we considered above occupies 20 bits, which is 5 half-bytes.) The starting location is the location of the byte con- maining the leftmost bits of the address field to be modified. If this field occu- ies an odd number of half-bytes, it is assumed to begin in the middle of the -st byte at the starting location. These conventions are, of course, closely re- red to the architecture of SIC/XE. For other types of machines, the half-byte roach might not be appropriate (see Exercise 2.2.9). For the JSUB instruction we are using as an example, the Modification rd would be 00000705 ecord specifies that the beginning address of the program is to be added eld that begins at address 000007 (relative to the start of the nrogram) 5 half-bytes in length. Thus in the assembled i bits (4B1) will remain unchan the last 20 hito dire ecution of record memory addres program. Finally, the assembler must write put device. This object program will later be machin Header, Text, and End. The Header record contains the program name, star The simple object program format we use contains three types addresses where these are to be loaded. The End record marks the end of code) instructions and data of the program, together with an indication ing address, and length. Text records contain the translated i.e., operand is specified, the address of the first executable instruction is used.) begin. (This is taken from the operand of the program's END statement. If object program and specifies the address in the program where execution is The formats we use for these records are as follows. The details of the mats (column numbers, etc.) are arbitrary; however, the information contain in these records must be present (in some form) in the object program. Header record: Col. 1 H Col. 2-7 Col. 8-13 Program name Starting address of object program (hexadecimal) Length of object program in bytes (hexadecimal) Col. 1419 Text record: Col. 1 T Col. 2-7 Col. 8-9 Starting address for object code in this record(hexadecimal) Length of object code in this record in bytes (hexadecimal) Object code, represented in hexadecimal (2 columns per byte of object code) Col. 10-69 End record: Col. 1 E Col. 2-7 Address of first executable instruction in object program (hexadecimal) o avoid confusion, we have used the term column rather than byte to refer to ositions within object program records. This is not meant to imply the use of ny particular medium for the object program. Figure 2.3 shows the object program corresponding to Fig. 2.2, using this emat. In this figure, and in the other object programs we display, the symbol s used to separate fields visually. Of course, such symbols are not present in actual object program. Note that there is no object code corresponding to dresses 10332038. This storage is simply reserved by the loader for use by program during execution. (Chapter 3 contains a detailed discussion of the ration of the loader.) We can now give a general description of the functions of the two passes of simple assembler. Define record: Col. 1 Col. 2-7 Col. 8-13 D Name of external symbol defined in this control section Relative address of symbol within this control section (hexadecimal) Repeat information in Col. 2-13 for other external symbols Col. 1473 Refer record: Col. 1 Col. 2-7 R Name of external symbol referred to in this control section Names of other external reference symbols Col. 8-73 The other information needed for program linking is added to the Modification record type. The new format is as follows. Modification record (revised): Col. 1 M Col. 2-7 Starting address of the field to be modified, relative to the beginning of the control section (hexadecimal) Col. 8-9 Length of the field to be modified, in half-bytes (hexa- decimal) Col. 10 Modification flag (+ or -) 20 Col. 11-16 External symbol whose value is to be added to or sub- tracted from the indicated field The first three items in this record are the same as previously discussed. The vo new items specify the modification to be performed: adding or subtract- g the value of some external symbol. The symbol used for modification may defined either in this control section or in another one. Fimuro 2 17