HP 3000 Manuals

Native Mode Program Development (new) [ Introduction to MPE XL for MPE V Programmers Migration Guide ] MPE/iX 5.0 Documentation

Introduction to MPE XL for MPE V Programmers Migration Guide

Native Mode Program Development (new)

In Native Mode, you typically follow these steps in developing a program:

* You enter source code statements in a text file, using an editor.

* You invoke one of the MPE XL NM optimizing compilers to translate the
file into machine-readable object code.

* The link editor joins this file with necessary library files, and
produces an executable program file. (MPE V/E and MPE CM are
somewhat different from MPE XL NM in the way they handle libraries.)

* You load and run the executable program file.

* If your program is interrupted, you can use the debugging facilities
to determine what went wrong, and whether to continue.

You can compile, link, and execute with one command in most languages.
There are also commands to do each of the steps separately.

Writing Source Code

Writing source code has not changed a great deal from MPE V/E. Before
planning program modularity, read the section on HP Link Editor/XL, to
understand how modules are linked.

Read the section on Mixed Mode Programs in this chapter if you are
planning to develop a program that will switch between NM and CM. On MPE
V/E and in CM the standard word is 16-bits long; in NM the standard word
is 32-bits. You must be aware of differences in data alignment and
floating-point real number formats.

Remember that MPE V/E supports Privilege Mode, but MPE XL NM does not.

Coding for Performance and Optimization. MPE XL NM has optimizing
compilers that can reschedule machine instructions to use the system's
resources more efficiently. It can not, however, alter the algorithm you
use in the source code. Designing and coding your program carefully can
enhance or reduce the performance of your program.

Programming Languages.
* New. The following programming language is available in NM only:
HP C/XL (NM)
* Changed. Programmers in the following languages will find compilers
in both CM and NM versions:
HP Business BASIC/V (CM) and HP Business BASIC/XL (NM)
COBOL II/V (CM) and COBOL II/XL (NM)
HP FORTRAN77/V (CM) and HP FORTRAN77/XL (NM)
Pascal/V (CM) and Pascal/XL (NM)
RPG/V (CM) and RPG/XL (NM)
* Not Used. The following MPE V/E languages are available in CM, but
not in NM:
FORTRAN 66/V (CM)
SPL/V (CM)

Table 2-2 summarizes the program development tools available in MPE V/E
and their availability in MPE XL.

Table 2-2. HP Products for Programmers on MPE XL

MPE XL provides run-time library support for user callable library
procedures. This support includes all MPE V/E and MPE XL libraries.
Also, any programs compiled on MPE V/E can be executed in MPE XL CM.

Please note that in NM Toolset/XL will debug COBOL II/XL, HP Pascal/XL or
HP FORTRAN 77/XL programs only. It cannot be used with HP C/XL programs.

Toolset XL cannot be used to debug CM programs. Therefore, COBOL or
Pascal programs that are migrated from MPE V systems can be edited with
Toolset/XL, but when they are compiled within Toolset/XL, they will be
compiled with the NM version of the compiler, and only the NM version of
the programs can be debugged in Toolset/XL.

If you want to develop applications on MPE XL for both MPE V and MPE XL
systems, you can develop, compile, and debug your programs in NM with
Toolset/XL and then recompile the source code in CM and test. Any
debugging of the CM code can be done with the (non-symbolic) system
debugger DEBUG.

Compiling

All HP-supported MPE V/E-based languages have run-time support, via CM
libraries, on MPE XL. Some NM languages have slightly different versions
than their MPE V/E counterpart compilers; all NM languages have
optimizing compilers.

MPE XL Compilers. Using an MPE V/E compiler on MPE XL produces CM object
code. The output of an MPE V/E compiler is a user segmented library file
(USL) of relocatable binary modules (RBMs). Each RBM contains one
procedure, either the main program or one of its subroutines. The
compiler puts each procedure from the source into a separate RBM.

Using an MPE XL compiler produces NM object code. An MPE XL compiler
produces object files composed of relocatable object modules containing
common code and data for all procedures in the source file. An object
module is the smallest unit that a compiler can produce and that HP Link
Editor/XL can manipulate.

The object module corresponds to an RBM on MPE V/E, with the following
distinctions:

* An RBM contains one, and only one, procedure. An object module can
contain one or more procedures.

* An RBM can exist only as part of a USL or part of an RL. An object
module is complete in itself and can stand alone as an independent
file.

An object file contains one relocatable object module. Each compilation
produces a single relocatable object module. A relocatable library, on
the other hand, can contain multiple relocatable object modules.

Since each invocation of an NM compiler produces one object module, in
order to separate object modules for two procedures into different object
files, you must put the procedures in separate source files and compile
them individually. You can gather them together at link time.

Compiler Libraries. On MPE V/E, the compiler run-time libraries needed
by every program are stored in the system segmented library (SL). A
programmer is never required to explicitly specify this library.

On MPE XL, compiler libraries are stored in a separate library,
XL.PUB.SYS, the system executable library. You can specify other library
files when linking the program. When you do an implicit link by using
one of the following types of commands, XL.PUB.SYS is automatically
included in your program's library search path:

* A command that compiles and links, such as COB85XLK.
* A command that compiles, links, and runs, such as COB85XLG.

If the compiler libraries are the only run-time libraries you need, you
do not need to use the XL parameter at link or run time. If you do
specify libraries, you do not have to mention XL.PUB.SYS; it will be
searched, by default, after the names in your list. But, if you do
specifically mention XL.PUB.SYS in your list, it must be the last library
in your search string.

MPE XL Optimizer. There is no counterpart on an MPE V/E system to the
MPE XL Optimizer, which is an integrated part of all MPE XL NM compilers.

The optimizer makes the scheduling of machine-level instructions and
allocation of registers efficient. To increase efficiency, machine-level
instructions may be re-ordered in your program to achieve optimal use of
resources.

The three levels of code optimization are:

Level 0 (default level) provides only very simple optimizations.
Use Level 0 when debugging a program that will not be
used many times.

Level 1 performs local optimizations. Use Level 1 to achieve
some optimization without spending too much time
compiling.

Level 2 performs global optimization. It provides the greatest
saving of space and time achievable with the optimizer
of all the levels. The programs it produces are the
most compact and run the quickest. Use Level 2 for
final compilations of programs that will be run often.

In MPE XL Native Mode, HP Business BASIC /XL, HP C/XL, HP COBOL II/XL, HP
FORTRAN 77/XL, and HP Pascal/XL provide optimizer options. Currently,
COBOL and BASIC provide levels 0 and 1, and the others provide all three
levels. Compilers set their own defaults for optimization levels.

Optimizer Assumptions. During compilation, the compiler gathers
information about the use of variables and passes it to the optimizer.
The optimizer uses the information to ensure that each code
transformation it performs maintains the correctness of the program, at
least to the extent that the original unoptimized program is correct.

The compiler assumes that inside a subroutine or function, only the
following variables can be accessed:

* Common variables declared in this routine.

* Local variables (static and nonstatic).

* Parameters for this routine.

If you have code that violates these assumptions, the optimizer may
change the behavior of the program in an undesirable way. The compiler
assumes that the program is the only process accessing its data. (HP
FORTRAN 77/XL does have some exceptions.)

For detailed information on using NM optimizing compilers, refer to HP
Business BASIC/XL Reference Manual (32715-90001), HP C Reference Manual
(92434-90001) and HP C/XL Reference Manual Supplement (31506-90001),
COBOL II Reference Manual (31500-90001) and COBOL II/XL Reference
Manual Supplement (31500-90005), HP FORTRAN 77/XL Reference Manual
(31501-90010), and HP Pascal Reference Manual (31502-90001).

Linking

In MPE XL CM, you use the MPE V Segmenter to link program modules. In
NM, you link a program with the link editor. The link editor's input is
an object module or a collection of object modules created by the NM
compilers. The link editor's output is one of the following files:

* Executable library.

* Executable program file.

* Relocatable library.

HP Link Editor/XL. Many HP Link Editor/XL commands have counterparts in
the MPE V/E Segmenter commands. However, there are some differences in
the way the link editor behaves. For example, it is case sensitive and
it does not implement version numbers. The counterpart of the MPE V/E
PREP command is the MPE XL LINK command. LINK takes one or more object
modules produced by Native Mode compilers and creates a program file. It
invokes the HP Link Editor/XL and passes it the parameters you specify.
The following are commands for the link editor, but not the segmenter:

* COPYRL, which copies an existing relocatable library.

* EXTRACTRL, which extracts a relocatable object module or a group of
object modules from a relocatable library.

* SHOWRL and SHOWXL, which display the name of the library in use.

* LINK, a command within the HP Link Editor/XL subsystem, which works
like the MPE XL system command LINK described below.

* LISTPROG, which prints the MAP of a program file to the display (by
default) or to wherever the LINKLIST file has been directed.

The LINK and PREP commands have the same basic function. However, LINK
has different options. LINK parameters can specify indirect files, which
are themselves lists of other files. An indirect file must be an
unnumbered file. In the LINK command, an indirect file can be a list of
one of the following:

* Files to link.

* Relocatable libraries (RLs) to merge.

* Executable libraries (XLs) to put in a program header.

Relocatable Libraries. MPE V/E and MPE XL both use relocatable libraries
(RLs). With PREP on an MPE V/E system, you can use only one relocatable
library (RL). With LINK on MPE XL NM, however, you can use one or more
relocatable libraries (RLs) to do the following:

* Resolve references at link time.

* Link RLs.

* Extract object modules from RLs.

The link editor can build new RLs several ways. It can use independent
relocatable object modules. It can copy relocatable object modules from
one RL to another. It can also extract copies of relocatable object
modules from an RL and place them in a relocatable object file.

On 900 Series systems, an RL automatically expands until it reaches the
maximum number of object modules it can contain. You can improve its
structure and increase its size, if necessary. The link editor command
CLEANRL can be used for garbage collection.

Unlike the MPE V/E Segmenter, when HP Link Editor/XL resolves an external
reference, it merges the entire object module in the program file, even
though only one procedure in that module may be required. To avoid
including unreferenced procedures in an executable program file, you can
compile each procedure from a separate source file to create separate
object modules.

Executable Libraries. The counterpart to MPE V/E segmented libraries
(SLs) are MPE XL executable libraries (XLs). SLs have the following
characteristics:

* They must be in files named SL.group.acct, where group is the name of
the group and acct is the name of the account in which the SL
resides.

* The ;LIB= parameter of the MPE V RUN command tells the order to
search the SLs. Default is LIB=S to search system SL. Specifying
LIB=P will search public, then system. Specifying LIB=G will search
group, then public, then system.

XLs have the following characteristics:

* They can have any valid MPE XL filename.

* You can access many XLs when you run your program.

Program Auxiliary Header. The MPE XL program auxiliary header resides in
the program files. It is generated by the link editor, and 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

If the program auxiliary header does not contain any of the above
information, the loader uses the default values for the RUN command. For
example, the program capabilities default to IA (interactive) and BA
(batch) and cannot be overridden at run time.

Unlike MPE V/E, MPE XL allows you to change any of the specifications
listed above at load time, except the primary entry point name.
Libraries specified at run time override those specified at link time.
For detailed information, refer to MPE Segmenter (30000-90011) or HP Link
Editor/XL Reference Manual (32650-90030).

Running a Program

Running a program includes creating a load module, loading the program,
and executing it.

Creating a Load Module. The term "load module" refers to either an
executable program file or an executable library module. It is the basic
unit of code sharing.

Load modules are created by the link editor with the LINK command.
Typical load modules are a program file, or a file containing one or more
library routines.

Loading a Program. The MPE XL Loader performs the final step in
preparing a program file for execution in either CM and NM. The loader
accepts a program file and (optionally) a set of executable libraries as
input. For CM programs, the loader accepts segmented libraries (SLs);
for NM programs, it accepts executable libraries (XLs).

The loader initializes code and data and creates table entries needed to
execute or access the code and data. It also creates linkages to connect
program calls to procedures in the executable libraries.

The loader performs the following tasks:

* Converts code to an executable format. The load 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 XL; only read and execute access is granted to
code pages. (On MPE V/E, read, write, and execute access is required
because the Segment Transfer Table is written to the program file).

* Creates global data area.

* Copies global data initialization information into process private
data space and sets appropriate register to point to it.

* Generates external reference list and attempts to locate all entries
in the list.

The CM Loader simulates the MPE V/E loader. The following CM loader
commands may be issued:

ALLOCATE Issued from a session or program, loads a CM program or
procedure into main memory.

DEALLOCATE Deallocates a program or procedure previously loaded
with the ALLOCATE command. A limited number of
procedures can be allocated.

These commands function in the same way on MPE V/E and MPE XL CM. Some
command syntax and parameter options are slightly changed. For more
information, refer to Chapter 5, Using the Command Interpreter.

Using Executable Libraries. On MPE V/E you must specify libraries by
choosing one of three search types: Group (G), Account (P), or System
(S). The search order is: SL.Group.Account, SL.Pub.Account, SL.Pub.Sys.
Specifying G, P, or S specifies where to begin the search. The default
is S (System).

On MPE XL, there are two parameters to specify libraries in the RUN
command: LIB= accepts the CM library search path (G, P, or S), and XL=
accepts the NM library search path. When running CM programs, the XL=
parameter is ignored. When running NM programs, an entry in the XL=
parameter overrides any entry in the LIB= parameter.

You can specify any number of executable libraries in NM. All commands
are restricted to a maximum of 280 characters, which means you may need
to use an indirect file. To do this, make a list of all the library file
names and save it as a text file (unnumbered). You can use this file of
filenames (preceded by ^, a caret) as your parameter entry.

MPE V/E restricts file names. MPE XL allows you to use any valid file
name you choose for an executable library.

In MPE XL, you do not have to list the system library; it is added to the
end of the list by default. However, if it is specified, it must be the
last library listed. XLs that you specify at run time override those
specified at link time.

The following guidelines apply to searching executable libraries:

* The library list can be specified at link time, but is not actually
used until run time.

* A run-time library name can appear only once in the RUN command.

* Libraries should be listed in order of increasing privilege level.

* If the system libraries are not specified, the system automatically
adds XL.PUB.SYS and NL.PUB.SYS as the last libraries to search.
XL.PUB.SYS, the system executable library, contains routines
pertaining to purchased products, including compiler routines.
NL.PUB.SYS, the native library, contains operating system routines.

UNSAT Procedure. If a program references external procedures that cannot
be located, it can still be run without problems if you specify an UNSAT
procedure. To do this, include the name of a dummy procedure in the
UNSAT parameter of the LINK command. This procedure will be substituted
for the missing library routine when the routine is called.

Set up the procedure with statements that facilitate program execution in
the absence of the real routine. For example, the UNSAT procedure
execution could print a statement informing you that it was called.

When the loader encounters the UNSAT procedure, it uses it to resolve all
remaining unresolved references. A recommended programming practice is
to compile the UNSAT procedure, place it in a separate library, and
specify the library at the end of the XL parameter list. (Your UNSAT
dummy must be before the compiler and system libraries. However, these
libraries are not typically specified; they are added to the end of your
list by default.)

Figure 2-1 shows an example of using an UNSAT procedure in a program.

Figure 2-1. UNSAT Procedure

System Libraries. System libraries are loaded in system space. The CM
system library is named SL.PUB.SYS. The NM system library is named
NL.PUB.SYS. System library object modules can reference only themselves
or other system library object modules. They cannot use UNSAT
procedures.

Mixing Execution Modes. While the operating system is executing a
process, it may switch between modes. It can alternate repeatedly
between NM and CM.

MPE XL provides switch stubs to allow NM programs to access CM
intrinsics. The operating system intrinsic call determines when to use
the CM Segmented Library (SL) or the NM executable libraries (NL and XL).
The CM intrinsic file is SPLINTR.PUB.SYS. The NM intrinsic file is
SYSINTR.PUB.SYS.

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

Errors, Aborts, and Debugging

The MPE XL System Debugger is very different from the MPE V/E debugger.
It has powerful features and commands that are not available with the MPE
V/E debugger.

The MPE XL debugger can be used interactively. It can be invoked with
commands or intrinsics.

Your compiler lets you choose options for trap, error, and abort control.
It is best to compile a program without optimization until it is
debugged. Optimization can change the order of instructions, making the
offsets misleading.

Common Errors. The following lists some common programming errors and
offers some suggestions for correcting them.

* Bad syntax during compilation: Check manual.

* Linking problems: Check parameters.

* Missing externals at run time: Check XL list.

* Run time errors: Look for program logic error, bad data.

Not all errors produce aborts, but all reported errors should be checked.

Aborts. The decision to abort can be made by a user program, a library
routine, an MPE intrinsic, or the hardware. Use the QUIT intrinsic to
kill the current process, and take you back to the process that called
it. Use QUITPROG to kill all the way back to the level of the command
interpreter (CI).

The following lists some common abort situations and offers some
suggestions for overcoming them.

* Integer overflow: Arithmetic operation needs larger target variable.
May appear as value not within subrange.

* Bounds violation: Bad stack/code address. Look for bad parameters.

* Library file problems: Check FILE parameter to see if it was
overlooked or entered incorrectly, review options/access.

When a process aborts, the MPE routines print a message or messages. Any
time there is an abnormal termination, the CI prints the final line,
resetting the cierror number. To find out more, see HPCIERRMSG in
Accessing Files Programmer's Guide (32650-90017).

Run time aborts also produce a process abort trace to $STDLST. The trace
starts with the procedure that terminated the program, and tracks callers
back to the main program.

Offsets are given from the beginning of the procedure. Remember, the
optimizer may have reordered some instructions. If you suspect this is
producing confusing offset numbers, try recompiling with the optimizer
off (or set to minimum). Run the program and check the offsets again.

MPE/iX 5.0 Documentation