HP 3000 Manuals

Loading and Running a Program [ Getting Started as an MPE/iX Programmer Programmer's Guide ] MPE/iX 5.0 Documentation


Getting Started as an MPE/iX Programmer Programmer's Guide

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 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.


MPE/iX 5.0 Documentation