Assembler Virtual Storage Requirements
The m1nlIDum 51ze virtual machine required by the assembler is bytes. However, better performance is generally achieved if
assembler is run in 320K bytes of virtual storage. This size
recommended for medium and large assemblies.
256K
the
is
If more virtual storage is allocated to the assembler, the size of
buffers and work space can be increased. The amount of storage
allocated to buffers and work space determines assembler speed and
capacity. Generally, as more storage is allocated to work space, larger
and more complex macro definitions can be handled. You can control the buffer sizes for the assembler utility data sets (SYSUT1, SYSUT2, and SYSUT3), and the size of the work space used during
macro processing, by specifying the BUFSIZE assembler option. Of the
storage given, the assembler first allocates storage for the ASSE8BLE and CMSLIB buffers according to the specifications in the DD statements
supplied by the FILEDEF for the data sets. It then allocates storage
for the modules of the assembler. The remainder of the virtual machine
is allocated to utility data set buffers and macro generation
dictionaries according to the BUFSIZE option specified: BUFSIZE(STD): 37 percent is allocated to buffers, and 63
work space. This is the default if you do
any BUFSIZE option.
percent to
not specify BUFSIZE(MIN): Each utility data set is allocated a single 790-byte
buffer. The remaining storage is allocated to work
space. This allows relatively complex macro definitions
to be processed in a given virtual machine size, but the
speed of the assembly is substantially reduced. Overlay Structures
An overlay structure can be created in CMS in two different ways,
although CMS has no overlay supervision. For descriptions of all the CMS commands mentioned, see the PRESTRUCTURED OVERLAY A prestructured overlay program is created using the LOAD, INCLUDE, and GENMOD commands. Each overlay phase or segment is a nonrelocatable
core-image module created by GENMOD. The phases may be brought into
storage with the LOADMOD command. Part 3. Conversational Monitor System (CMS) 323
r-----------------------------------------------------------,
A (Root Phase) I I I I I rl--------------------,<-------------Location xxxxxxi I I I I I I I IC I IB I I I yyyyyyl I ID I I I I IE I I Figure 2. An Overlay Structure
The overlay structure shown in Figure 42 could be prestructured using
the following sequence of commands (programs A, E, C, D, and E are the
names of TEXT files; the overlay phases will be named Root, Second,
Third, etc .. ): LOAD A B GENMOD ROOT (FROM A TO B STR) GENMOD SECOND (FROM B) LOAD MOD ROOT INCLUDE C D GENMOD THIRD (FROM C TO D) GENMOD FOURTH (FROM D) LOADMOD THIRD INCLUDE E GENMOD FIFTH (FROM E)
The programmer need not know the storage address where each phase
begins.. A TEXT file can be made to load at the proper address by
reloading earlier phases. In the foregoing example, the command
sequences, "LOADMOD ROOT/INCLUDE C D" and "LOADMOD THIRD/INCLUDE E," cause TEXT files C, D, and E to load at the proper addresses.
If the root phase contains address constants to the other phases, one
copy of the root must be kept in storage while each of the other phases
is brought in by the LOAD or INCLUDE commands without an intervening GENMOD. The root phase is then processed by GENMOD after all address
constants have been satisfied. In this case, the programmer must know
the address where nonroot phases begin (in Figure 41, locations xxxxxx
and yyyyyy). The following sequence of commands could be used: LOAD A B GENMOD SECOND (FROM B) INCLUDE C D (ORIGIN xxxxxx) GENMOD THIRD (FROM C TO D) GENMOD FOURTH (FROM D) INCLUDE E (ORIGIN yyyyyy) GENMOD FIFTH (FROM E) LOAD A B INCLUDE C D (ORIGIN xxxxxx) INCLUDE E (ORIGIN yyyyyy) GENMOD ROOT (FROM A TO C STR) 324 IBM VM/370 System Programmer's Guide
Previous Page Next Page