Loading and Running a Program

The loader performs the following tasks:

Loads the executable module into virtual memory locations.
Updates addresses contained in an executable object module with the actual memory addresses.
Resolves unsatisfied external references to executable libraries. If any unsatisfied external references remain, the loader aborts.

The loader loads executable libraries to resolve external references by linking the import requests of the unresolved reference to an export definition contained in the executable library. The actual link is made by pointer reference to shared code. No object module in an executable library can have access to the caller's data without passing parameters.

The first step in running a program is to load it. The MPE/iX Loader performs the final step in preparing a file for execution in Native Mode and Compatibility Mode. When operating in Compatibility Mode, the loader simulates the MPE V/E Loader, with only the changes necessary to make it run.

MPE/iX Loader input consists of an executable program file and an optional set of executable libraries.

The loader initializes code and data to create table entries needed to execute or access the code and data and creates links to connect program references to executable libraries.

A program load performs the following tasks:

Maps executable module into virtual memory by converting the code relative addresses to absolute addresses. (Code relative addresses are those which are relative to the beginning of the executable program file.)
Changes the access rights of pages that contain code. Code is executed without copying it; it is mapped to virtual memory. Write access to program code is not necessary on MPE/iX; only read and execute access is granted to code pages.
Creates global data areas for the program and each module in referenced executable libraries.
Copies global data initialization information into process data space and sets the appropriate register to point to it.
Generates external reference list and attempts to locate all entries in the list.

Program Auxiliary Header

The MPE/iX program auxiliary header resides in an executable program file,is generated by HP Link Editor/XL, and is used by the loader. It specifies the following information:

Primary entry point name
UNSAT procedure name
XL LIST (the list of XLs specified at link time)
Program capabilities
Maximum stack and heap sizes

MPE/iX allows you to change the specifications listed above at load time, except the primary entry point name and program capabilities. Any information you specify at run time overrides the specifications given by HP Link Editor/XL.

If the program auxiliary header is not specified, the loader uses the default values for the :RUN command. Libraries specified at run time take precedence over those specified at link time.

Using Executable Libraries

On MPE/iX, you can run a Native Mode program and specify the use of multiple libraries with different names, rather than just one executable library (XL) at a time.

The syntax for running a program that utilizes one or more executable libraries is as follows:

:RUN prog; XL =  "xlib1[,xlib2][,xlib3] ..."

In this syntax, xlib1, xlib2, xlib3, ... are replaced by the names of the libraries you want to execute and prog is a Native Mode program name. You can specify any number of XLs, up to a maximum limit of 288 characters for the complete command. You can use any valid file name for an XL. The system library is added to the end of the list by default. However, if you specify it, you must make it the last library listed. XLs that you specify at run time override those specified at link time.

Searching Executable Libraries

The following guidelines apply to searching executable libraries (XLs):

The library list can be specified at Link time, but is not actually used until run time.
Run-time libraries can appear only once in the :RUN command.
You must list libraries in order of increasing privilege level.
If the system library is not specified, the system automatically adds XL.PUB.SYS and NL.PUB.SYS as the last libraries to search.

UNSAT Procedure

You can load a program that has one or more referenced external procedures that cannot be located by specifying an UNSAT procedure. This is a dummy procedure specified in the UNSAT parameter of the :LINK command. This procedure is substituted for the missing library routine. You can set up the procedure to contain statements that facilitate program execution in the absence of the real routine. For example, the execution of the UNSAT procedure could print a statement informing you that it was called.




	NOTE: The content of an UNSAT procedure determines whether or not a program can continue to run after the UNSAT procedure is called.

When the loader encounters an UNSAT procedure, it uses it to resolve all remaining unresolved references. The UNSAT procedure iself may be written in any language; however, it must be compiled and put into one of the executable libraries that is specified at run time. Figure 3-4 “UNSAT Procedure Example” shows an example of using an UNSAT procedure in a program.

Figure 3-4 UNSAT Procedure Example

System Libraries

System library characteristics include the following:

They are loaded in system space.
Processes using the same object module share code, global data, and binding.
Object modules can reference only themselves or other system library object modules.
Cannot use UNSAT procedures.
System libraries are the only libraries that can contain both system and nonsystem object modules. (A nonsystem object module shares only the code with other processes. Its data and binding are unique to each process that references it. A nonsystem object module is loaded once for each process that uses it.) The Native Mode system library is named NL.PUB.SYS. The Compatibility Mode system library is named SL.PUB.SYS.

Mixing Execution Modes

While the operating system is executing for a process, the process may switch execution modes. It can alternate repeatedly between Native Mode (NM) and Compatibility Mode (CM). MPE/iX provides switch stubs to allow NM programs to access CM intrinsics. The operating system intrinsic call determines when to use the NM Executable Library (NL) or the CM Segmented Library (SL).

The NM intrinsic file is SYSINTR.PUB.SYS; the CM intrinsic file is SPLINTR.PUB.SYS.

You can set up a Native mode program to call procedures that are in a CM Segmented Library (SL) by using the switch intrinsics. This requires that the program specify the switch stub. The switch intrinsic uses the LOADPROC procedure to find the CM procedure. For detailed information on the switch subsystem and programmatic access through switch stubs, refer to Switch Programming Guide (32650-90014).

Virtual Memory and Demand Paging

When a program is running, only part of it is needed at any one time. To save space in main memory, MPE/iX brings pieces of a program in, as needed for current execution. It divides a program into fixed-length pieces called pages (for a description of pages, refer to Chapter 1). The remainder of the program can be stored on a high-speed device (for example, a disc) that can act as an extension of real memory. This extension is called virtual memory. The use of virtual memory reduces to a minimum the problem of application program size compared to available memory size, because it eliminates the requirement for loading all code and data into main memory at once.

LMAP: Load MAP

An LMAP facilitates code management by listing a loaded program. It describes the spaces loaded for a process and the linkages used to connect the external references of the process for the program and each library specified by the user. To produce a load map (map of a loaded program), specify the LMAP parameter of the :RUN command. To print an LMAP, use :FILE to define the file with the formal file designator LOADLIST as a line printer device file. For detailed information refer to the MPE/iX Commands Reference Manual Volumes 1 and 2 (32650-90003 and 32650-90364). A load map can also help to determine if you have achieved good localization. An LMAP shows:

File name and type of file (program or library)
Number of external references a program file makes
Type of library from which each call is resolved

Load-time Binding Sequence

The loader assigns virtual addresses and makes an executable program file into a runnable process.

Running a Program

When a program has been successfully linked, you can load it and execute the :RUN command. At this stage of operation, the program is called a process. A process is a unique execution of a particular program by a particular user at a particular time. If you change even one element of a program, it becomes a different process than it was before.

When you execute a program, a piece of software called the LOADER starts the process on the system. The loader must resolve any external references in the program by using executable libraries.

MPE/iX is a multiprogramming operating system, which has many processes competing for CPU time. Only one process can execute at a given instant in time. When a program has had external references resolved it is ready to execute. It can now compete with other processes for the resources of main memory and CPU time.

The :RUN command requires you to specify the filename of the program and allows you to specify many other options, such as obtaining a program load map. You can specify values for process stack and heap size to override values specified at the link stage. There are facilities for passing information to a program at run time and determining which libraries are searched to resolve external references.