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