CORE LOAD BUILDER - Restricted Distribution Program Logic

OVERLAY SCHEME AND CORE LAYOUT

The overlays (phases) of the Core Load Builder have been organized to allow maximum core storage for the Load Table while minimizing the flip-flopping of phases. "Minimizing" here means that, during a one-pass building process (no LOCALs or SOCALs), the phases are executed serially from 1 through 6 (excluding 5). During a two-pass building process (LOCALs and/or SOCALs required), there is some flip-flopping of phases 3 and 5.

Phase 0 is never overlaid. It contains the sub-routines that must never be overlaid, as well as work areas and constants required by more than one subroutine.

Phase 1 is fetched along with phase

o.

The only difference is that phase 2 overlays phase 1 but not, of course, phase

o.

Phases 3, 4, 5, 6, and 12 over-lay the last part of phase 2.

Phases 7-10 contain messages. They all require that the principal print subroutine be in the data buffer; these phases themselves are executed from the LET/FLET search buffer.

Phase 11 prints the file map and phase 12 the core map. Both of these phases require that the principal print device subroutine be in the LE T /FLE T search buffer. Phase 11 is executed from the data buffer.

Figure 9, panel 1 shows the layout of the contents of core storage after phases 0 and 1 of the Core Load Builder have been fetched into core storage by phase 1 of the Core Image Loader or the STORE function of DUP.

Figure 9, panel 2 shows the layout of the contents of core storage after phase 1 has fetched phase 2, overlaying itself. Phase 2 has allocated the areas for the Load Table and the disk I/O buffers.

Figure 9, panel3 shows the layout of the contents of core storage after anyone of the overlay phases has been fetched by phase 2.

Phase 1 includes the subroutines called by the in-itialization subroutine. In this way, phase 2 can over-lay phase 1 completely. Phase 2 includes the sub-routines called by the relocation subroutine, RL. The order of the subroutines in this phase is important.

Those that are required only during the relocation of the mainline (MV, ML, CK, DC, D F, and FM) come

Section 8. Core Load Builder 33

CD

includes the subroutines required to choose a sub-routine (as opposed to a mainline) from the Load Table and relocate it. Phases 4 and 6 round out the one-pass core load building process. Phase 4 determines whether or not SOCALs are required, and, if so, whether or not they can be employed to make the core load fit into core storage. It also processes ILSs. Phase 6 performs the miscellaneous jobs, such as creating the transfer vector, that can be done only at the end of the proces s of building a core load. Phase 5 is executed only during pass 2 in a two-pass building process. It organizes the LOCALs and SOCALs for relocation, including their special linkages.

DISK BUFFERS

There are three buffers used by the Core Load Builder. Each is 320 words long, not counting the word count and sector address, and each has a primary use, although it may be used temporarily for something else. For example, the LE T search buffer is used primarily to hold a sector of LET/

FLET when searching that table. However" it con-tains one of the message phases (phases 7 -10) whenever a message is printed.

The data buffer is a buffer for the User Area.

The program currently being incorporated :lnto the core load is read into this buffer, one sector at a time. For example, after a sector of the mainline is read into this buffer from the User Area or Working Storage, the relocation of the mainline can begin. When this sector of the mainline has been Assignment Counter (LAC) reflects the ultimate core address of the data word currently being relocated.

In this example, the LAC would start at 1000, thus causing sector 1 of the CIB to be read into the CIB buffer. This first word of the core load would be placed in the first word of the CIB buffer and the LAC advanced by 1. Assuming no data breaks, the LAC will eventually be incremented to 1320. Then the contents of the CIB buffer will be written out single 640-word buffer for the purpose of fetching the LOCAL, NOCAL, and FILES information from

core load is executed) below location 4096. The first word of the mainline is stored in the first word of the CIB following the core image header, and subsequent words follow similarly. Thus, the mainline must be relocated first, and a subse-quent ORG that would set the Location Assignment Counter below its first value is not allowed.

LOAD TABLE LOCAL/NOCAL entry point specified for a given mainline and (2) for each subprogram entry point referenced in a core load, via CALL or LIBF. For example, even though subprogram A is called five times, there is only one entry in the Load Table for length. The first entry occupies locations 4086 -4089, the second 4082 - 4085, etc. The first two words of each entry contain the name (in name eode) of the subprogram that caused the entry to be made.

Bit zero of the first word is set if the entry is that of a LOCAL, bit one is set if the entry is that of a CALL. Mainlines and interrupt level subroutines never appear in the Load Table.

Words three and four of each entry are zero when the entry is first made. As the relocation of a given subprogram begins, word three is set with the entry point, i. e., the absolute, address. In this way, the Core Load Builder can tell by looking at its Load Table entry whether or not a subprogram has been relocated and where it has been relocated to.

Word four is put to several uses, most of which involve LOCAL processing. The use of this word at a given time is dependent upon the pass (1 or 2) and/

or whether the subprogram associated with the Load Table entry is a LOCAL that was specified in the LOCAL information in the SCRA. As an explana-tion, suppose that A and B are entry points to the same subprogram, and A (but not B) appears in the LOCAL information in the SCRA. Both A and B can be called in the core load; in such a case A is said to be specified and B unspecified. These terms are useful in the following context.

The values stored in word four at various times

LOCAL, NOCAL, AND FILES INFORMATION LOCAL, NOCAL, and FILES information is obtained from the Supervisor Control Record Area (SCRA).

This information is supplied by the Supervisor Con-trol Record Analyzer (see Section 6: Supervisor) or the STORECI function of DUP (see Section 9: Di~~

utility Program). For the format of LOCAL, NOCAL, and FILES information in the SCRA, see Section 6: Supervisor or Section 9. Disk utility Program.

ISS TABLE

The ISS Table is used by the Core Load Builder as it constructs Interrupt Branch Tables for ILSs. When the address to which an ISS is to be relocated be-comes available, that address is stored in the appropriate entry in the ISS Table. For example, if an ISS for the 1132 Printer (ISS number 6) is being relocated to location /1000, then /1000 is stored in word 6 of the ISS Table. This address will later

be used during the construction of the Interrupt Branch Table (IBT) for ILSOl.

INTERRUPT BRANCH TABLE (IBT)

Each ILS in the System Library that is filled in by the Core Load Builder (ILSOO, ILS01, and ILS03) begins with an Interrupt Branch Table (IBT). ILS02

and ILS04, which are a part of the Resident Monitor, require special treatment to construct their IBTs, unless the user supplies his own ILS02 and/or ILS04. A given IBT consists of the addresses of the interrupt service entry points for the devices on the corresponding interrupt level. Thus, if there are two devices on a level, there are two entries in the IBT, and each entry consists of one word, that word being the address of the interrupt service entry point to the ISS for the device represented by the IBT entry.

For user-written core loads (as opposed to monitor system programs), the IBT for ILS04 is

Section 8. Core Load Builder 35

construeted by the Core Load Builder and stored in the core image header record. When the Core Image Loader fetches a core load (including the core image header), the address of the IBT for level 4 is stored in location $IBT4, from which it is accessed by ILSO,:1. The IBT for ILS02 is a single word,

$IBT2, which contains the address of DZOOO+4, regardless of the disk I/O subroutine present in the Resident Monitor ⁰ This address is stored in $IBT2 by the Core Image Loader as it fetches the requested disk I/O subroutine. The IBTs for the remaining ILSs are constructed and stored in the ILSs them-selves by the Core Load Builder.

After all subprograms have been relocated, the Core Load Builder constructs the IBTs. The IBTs for all ILSs except ILS02 are constructed as des-cribed below. Bear in mind that these ILSs are written with special constants stored in each IBT entry. These constants, which will be overlaid by

the Core Load Builder, are as follows: The first eight bits of each constant represent the increment to be added to the loading address of the correspond-ing ISS to get the address of the interrupt service entry point; for IBM-supplied ISSs, this value is four, except for the "operation complete ¹¹entry point for the 1442 subroutines, for which the value is seven. The second eight bits are @ISTV plus the ISS number; thus, each IBM entry has an identifier to relate it to a specific ISS.

The Core Load Builder fetches one word at a time from the IBT, i. e., one of the special constants occupying the IBT locations in the ILS. The second eight bits of the word fetched are used to compute the address of the ISS Table entry for the ISS

number indicated. If the ISS Table entry is non-zero, it contains the loading address of the ISS itself, which is then incremented by the value stored in the first eight bits of the word fetched. The resulting address, which is the address of the interrupt service entry point, replaces the special constant that supplied the two eight-bit values. If the ISS Table entry is zero, the special constant is replaced with the address of $STOP, the PROGRAM STOP key trap in the Skeleton Supervisor ~ This process of replacing special constants continues until a zero is fetched from the IBT, indicating that the entire IBT has been processed. Except for ILS04, this zero is the entry point to the ILS itself.

INCORPORATING PROGRAMS INTO THE CORE LOAD

PASS 1

The mainline is relocated first. Any calls found during this relocation are put in the Load Table.

After the mainline has been converted, each sub-program represented in the Load Table is re-located, generally in the order found in the table itself. An entry is flagged as having been relocated by storing the address of the entry point in the third word of the entry. Before an entry is reloeated, the names of all the entry points to the entry being considered for relocation are compared with the name of each entry preceding it in the Load Table.

A match indicates that the current entry is simply another entry point to a previously relocated sub-program. Thus, the current entry is not relocated;

instead, the absolute address of the entry point is determined and stored in the third word of the entry to signify that it has already been relocated.

Furthermore, the names of all the entry points to the entry being considered for relocation are com-pared with the name in each entry in the Load Table following it. If a match occurs, the third words of both entries are filled in with the absolute address of the entry point. Thus, the Load Table is scanned forward and backward for other entry points to the subprogram currently being considered for re-location.

PASS 2

The Load Table is scanned during pass 2 in the same way as during pass 1. The only difference is that subprograms are relocated in a certain order during pass 2, thus necessitating multiple passes through the Load Table; in fact, one pass is required for each class of subprograms. Thus, all the in-cores (class 0) are relocated first, followed by LOCALs, sub-programs in SOCAL 1 (class 1), subroutines in SOCAL 2 (class 2), and subroutines in SOCAL 3 (class 3), in that order.

LOCALs AND SOCALs

If during the first pass the Core Load Builder (phase 4) determines that an Assembler core load will not fit into core storage even with any LOCALs that have been specified, the core load building process is terminated. However, for a FORTRAN core load special overlays (SOCALs) of parts of the core load will be created during a second pass if this will make the· core load fit. The decision of whether to proceed with a second pass is made after phase 4 accounts for the sizes of the LOCA L area, if any, the flipper and its table, and each of the SOCALs. If the check shows that SOCAL option 1 (SOCAL 1 and SOCAL 2) will be insufficient, then a further check is made for option 2 (all three SOCALs). If option 2 is still insufficient, process-ing is terminated; otherwise, a second pass is made.

During pass 2, the entire core load is built again, but, unlike during pass 1, subprograms are relocated in a special order. First, the mainline and the in-core (class 0) subprograms are relocated, followed by: the flipper; the LOCALs, if any; the arithmetic and function (class 1) subprograms; the non-disk FlO (class 2) subroutines; and, if necessary, the disk FlO (class 3) subroutines.

The same procedure described above is necessary if LOCALs are employed without SOCALs. In other words, LOCALs, as well as SOCALs, require two passes.

INTERRUPT LEVEL SUBROUTINES (ILSs) After all other subprograms have been relocated, the Interrupt Transfer Vector (lTV) in the core image header is scanned. Except for the entries for interrupt levels 2 and 4, a non-zero entry causes the corresponding ILS to be incorporated into the core load. (ILS02 and ILS04, unless supplied by the user, are a part of the Resident Monitor.) See Interrupt Branch Table, above, for a description .of the processing of that part of an ILS. storage location during execution. This is desirable because 1130 FORTRAN object code contains a very high percentage of calls to subprograms. Long branches to those subprograms would greatly in-crease core requirements for core loads over a method that employs short br.anches. By replacing the LIBF statement with a short BSI, tag 3, to a transfer vector entry, which could then supply the long branch to the desired subprogram, this problem is solved. The cost, of course, is that XR3 is taken away from the user and the transfer vector is limited to 255 words. This means the LIBF TV has a

maximum of 85 3-word entries, two of which become the real-number pseudo-accumulator (F AC) and an indicator for certain arithmetic subroutines. Thus, the user is limited to LIBFs to not more than 83 separate subprogram entry points per core load.

There is no theoretical limit on the number of CA LL entry points per core load, for the CA LL statement is replaced by an indirect BSI to the desired subprograms. However, the number of CALL and LIBF references combined must not exceed the capacity of the Load Table, which is approximately 150 entries.

The CALL TV entry is one word only, the address of the subprogram entry point. This makes it pos-sible to replace a CALL statement with an indirect BSI to the corresponding CALL TV entry, even though the address of the subprogram itself may not be known at the time the CALL is processed.

When stored on disk in disk core image format (DCI), the LIBF TV follows the last word of the last subprogram in the core load. It may leave one word vacant between it and the CALL TV in order to make the pseudo-accumulator (F AC) begin on an odd boundary. The CALL TV immediately follows the indicator entry in the LIBF TV. During execu-tion the TV extends downward in core storage from the lowest-addressed word in COMMON.

Whereas the CALL TV entry consists of only one word (the address of the subprogram), the LIBF TV entry consists of three words. The first is a link word (initially zero), and the second and third are a long BSC to the subprogram entry point.

Figure 10 shows the layout of the transfer vector in core storage.

Linkage to WCALs

The LOCALjSOCAL flipper (FLIPR) is included in a core load if that core load requires LOCALs and/or SOCALs. The flipper transfers control to a LOCAL,

Section 8. Core Load Builder 37

Dummy one - word entry in CAll TV sub-program is called that is a part of the SOCAL current-ly in the SOCAL area (see Linkage to the System

Overla:~.

The Flipper T able immediately precedes the flipper. It consists of a 6-word entry for each entry point specified in the LOCAL information in the SCRA (for a given mainline) that is referenced by a CALL and a 5-word entry for each entry point referenced by a LIBF. If a subprogram has more than one entry point but only one is specified in the LOCAL informa-tion (a specified LOCAL), there is a Flipper Table entry for each entry point referenced in the core load.

Word count of the subprogram Sector address of the subprogram Entry point address in the

Word count of the subprogram Sector address of the subprogram Entry point address in the a given time, special transfer vector entries are made for SOCAL subprograms. They are different from the standard LIBF and CALL linkages, and they are different from the linkage to a LOCAL. The SOCAL transfer time is approximately 20 micro-seconds, compared to 150-180 microseconds to a

LOCAL. (Both timings assume a 3.6 microsecond storage cycle.)

Figure 11 shows an entry in the LIBF TV for an in-core subprogram (entry 2) and the special linkage in the LIBF TV for SOCAL subprograms (entries 3-8). Entry 1 is the LIBF TV entry for a SOCAL subprogram. The "disp" is a displacement to the second word of the linkage for the SOCAL in which the subprogram is found.

The example represented in Figure 11 :ls one that requires SOCAL option 2; TV entries 5 and 8 would not appear if option 1 were used. Entry 1 is the last entry in the LIBF TV, i. e., the

highest-addressed word of the transfer vector. Suppose that (1) a LIBF to FADD were made and (2) SOCAL 1 were not in core. The LIBF would be a BSI to the first word of entry 1, which would then BSI to tll1e second word of entry 3. Entry 3 would MDX to the first word of entry 6, which would transfer control to the

LOCAL/SOCAL flipper subroutine (FLIPR) at FL2301) the entry point in FLIPR for fetching the arithmetic subprograms. The flipper would fetch SOCAL 1, change the third word of entry::: to MDX

Dans le document Restricted Distribution Program Logic (Page 41-73)