HP 3000 Manuals HP 3000 Manuals
The Transact/iX Compiler
Compiling and executing a Transact program under MPE/iX requires three
sets of procedures. These sets can be accomplished one at a time by
using three separate commands, or they can be combined and accomplished
by using two separate commands, or even by using a single command. The
commands you choose to use depend primarily on how you want to invoke
subroutines or subprograms.
The three sets of procedures you can use for compiling and executing
Transact programs under MPE/iX are as follows:
1. The Transact/iX compiler translates either a source code or p-code
file into binary form and stores it as a Series 900 object module
in a relocatable file. Note that Transact/iX can accept as input
either an ASCII source file or a p-code file produced by
Transact/V's TRANCOMP program. If your input is an ASCII file,
the Transact/iX compiler first calls Transact/V's TRANCOMP to
create p-code, then produces the relocatable file. This
relocatable Series 900 object module file is called an RSOM file.
2. The MPE/iX Linker must prepare the RSOM file for execution by
binding procedures in the RSOM together. The linker also performs
other tasks such as defining the initial requirements of the user
data area. The MPE/iX LINKEDIT program may also be required at
this stage if procedures external to the RSOM are to be added to
the RSOM.
3. The MPE/iX operating system must allocate and initiate the
execution of the program. External procedures referenced and
stored in an executable library (XL) are bound to the program at
this time.
You can advance through each of these procedures independently,
controlling the specifics of each process along the way. In particular,
it is possible to use the command TRANXL for the first set of procedures,
the command LINK for the second set, and the MPE/iX command RUN progname
for the third set.
Alternatively, you can combine procedures with a single command. For
example, the command file TRANXLLK performs the first and second sets of
procedures; the command file TRANXLGO performs the first, second, and
third sets of procedures.
You can also use the MPE/iX RUN command to execute the Transact/iX
compiler, which is a program file called TRAN.PUB.SYS. This command
accomplishes only the first set of procedures. It requires preceding
file equations and specification of PARM values if you choose to change
any defaults.
Another MPE/iX program, LINKEDIT.PUB.SYS, is required for including
subprograms that are external to the RSOM file into the RSOM file.
Transact/iX Compiler Options
Like compatibility mode TRANCOMP, the Transact/iX compiler allows you to
control certain compilation features by supplying compiler options via
the INFO= parameter. These options can be included on any of the
commands that are used to invoke the Transact/iX compiler: TRANXL,
TRANXLLK, TRANXLGO, and RUN TRAN.PUB.SYS.
The Transact/iX compiler has the following options:
DYNAMIC_CALLS Generates dynamic calls for all CALL statements in
the program. This allows a program to be executed
even if some of the programs that it calls are not
available at load-time. Dynamic calls are described
in detail later in this chapter. The default is
NODYNAMIC_CALLS.
HP3000_16 Uses the HP floating point format for all the files
and databases used by this program. If the
NOHP3000_16 option is specified, then all the files
are expected to use the IEEE floating point format.
See the "Floating Point Formats" section in Appendix
B. The default is NOHP3000_16.
PROCALIGNED_16 Causes the compiler to assume that all 16-bit aligned
parameters are correctly aligned on 16-bit boundaries
and prevents it from double buffering them on 16-bit
boundaries. Using this option improves run-time
efficiency, since the compiler only generates a
run-time check to ensure that these parameters are
correctly aligned on a 16-bit boundary. Double
buffering still occurs if the following conditions
are all met: the procedure called is an intrinsic,
the PROCINTRINSIC option is specified, and a greater
than 16-bit alignment is required.
This is the recommended option for existing Transact
programs, since correct 16-bit alignment is already
assured.
The default is NOPROCALIGNED, if PROCALIGNED_16,
PROCALIGNED_32, or PROCALIGNED_64 is not specified.
PROCALIGNED_32 Causes the compiler to assume that all 16-bit and
32-bit aligned parameters are correctly aligned on
16-bit or 32-bit boundaries and prevents it from
double buffering them on 16-bit or 32-bit boundaries.
Using this option improves run-time efficiency, since
the compiler only generates a run-time check to
ensure that these parameters are correctly aligned on
a 16-bit or 32-bit boundary. Double buffering still
occurs if the following conditions are all met: the
procedure called is an intrinsic, the PROCINTRINSIC
option is specified, and a greater than 16-bit or
32-bit alignment is required.
This option is primarily recommended for use with new
Transact programs in which the correct alignment of
all 16-bit and 32-bit procedure parameters is
assured.
The default is NOPROCALIGNED, if PROCALIGNED_16,
PROCALIGNED_32, or PROCALIGNED_64 is not specified.
PROCALIGNED_64 Causes the compiler to assume that all 16-bit,
32-bit, and 64-bit aligned parameters are correctly
aligned on 16-bit, 32-bit, 64-bit boundaries and
inhibits double buffering. Using this option
improves run-time efficiency, since the compiler only
generates a run-time check to ensure that these
parameters are correctly aligned on a 16-bit, 32-bit,
or 64-bit boundary.
This option is primarily recommended for use with new
Transact programs in which the correct alignment of
all 16-bit, 32-bit, and 64-bit procedure parameters
is assured.
The default is NOPROCALIGNED, if PROCALIGNED_16,
PROCALIGNED_32, or PROCALIGNED_64 is not specified.
PROCINTRINSIC Aids the migration of Transact/V systems containing
intrinsic calls to MPE/iX. This option is identical
in effect to declaring intrinsics within a
DEFINE(INTRINSIC) statement. The Transact/iX
compiler checks all procedures referenced by the PROC
verb to determine whether or not they are defined in
SYSINTR.PUB.SYS. When it finds an intrinsic, the
compiler extracts from SYSINTR.PUB.SYS the intrinsic
name (corrected for case) and the number, type, and
alignment of the parameters used by the intrinsic.
This information is used at run time to set up the
procedure call. If this option is not used, the
Transact/iX compiler downshifts all procedure names
not in the SYSINTR.PUB.SYS file (in accordance with
the Series 900 procedure calling convention) and may
result in the procedure not being found in the
executable library (XL).
A warning message is generated each time the compiler
locates an intrinsic that has not been declared in a
DEFINE(INTRINSIC) statement or if it does not find an
intrinsic in SYSINTR.PUB.SYS that was declared in a
DEFINE(INTRINSIC) statement. PROCINTRINSIC must be
used if the program calls an intrinsic and the
intrinsic is not declared with DEFINE(INTRINSIC).
The default is NOPROCINTRINSIC.
TRANDEBUG Causes TRANDEBUG, the symbolic debugger, to be
enabled when the program is executed. See Chapter 11
for instructions using TRANDEBUG.
SUBPROGRAM This option is used when compiling a program that
will be called by another Transact/iX compiled
program. No outer block is generated when the
SUBPROGRAM option is specified. The processing that
is normally done by the outer block is done by the
calling program.
The Transact/iX compiler creates a single RSOM file
regardless of how many SYSTEM statements are in a
source file. When a source file contains more than
one system, the default is to compile the first
SYSTEM encountered with option NOSUBPROGRAM and those
remaining with the option SUBPROGRAM as they are
assumed to be subprograms called by the first system.
Using the SUBPROGRAM compiler option causes all the
systems in the file to be compiled with the
SUBPROGRAM option.
OPTIMIZE This option directs the compiler to generate level 1
optimized code. Using this option causes the compile
to be slower but produces object modules that are
more efficient at run time.
The default is NOOPTIMIZE.
TRANCOMP Options Available to the Transact/iX Compiler.
In addition to the compiler options described above, the Transact/iX
compiler also accepts many of the compiler options available for
TRANCOMP/V, described earlier in this chapter. These are:
LIST OPTE
ERRS OPTP
CHCK OPTI
DEFN OPTS
OPT@ XREF
OPTH
The following TRANCOMP/V options are ignored by the Transact/iX compiler.
Their default values are shown to the right.
Ignored Option Default Value
DICT DICT
CODE CODE
OBJT NOOBJT
STAT NOSTAT
XERR NOXERR
OBJO NOOBJO
OBJH NOOBJH
When one of these compiler options is specified, it is ignored if it
specifies the default value. If it does not specify the default value,
an informational message is generated by the compiler. For example, if
option NODICT were specified, the following informational message would
be reported by the compiler:
*INFO: OPTION 'NODICT' IGNORED
Compiling Programs for Static Calls.
The steps for compiling subprograms for use with static calls are as
follows:
1. Compile the subprogram with either the :TRANXL command or :RUN
TRAN.PUB.SYS. Specify the SUBPROGRAM compiler option in the INFO
string.
2. Use the LINKEDIT program to build the subprogram and add it to
either an RL, an XL, or the RSOM file of the calling program.
These steps are shown in the examples that follow.
The steps for compiling and executing main programs are slightly
different, depending on whether the subprogram is in an RL or an XL
(i.e., depending on whether it will be accessed at link time or run
time). Subprograms in an XL require slightly more load time than
comparable programs in an RL, but they provide the same fast run-time
performance.
When subprograms are in an RL, the compilation and linking are separate
steps, so that the main program can be linked to the RL at link time.
When subprograms are in an XL, the compilation and linking can be
combined and done with :TRANXLLK; then when the program is executed, the
RUN command must include the name of the XL file.
The steps are shown in the following examples.
Example of Static Calls with Link-Time Linking.
The first example shows how to compile and run programs using static
calls with link-time linking. Assume a main program called MAIN, which
calls another program called PROG using static calls. First, compile the
subprogram PROG into PROGOBJ using the SUBPROGRAM compiler option.
:TRANXL PROG, PROGOBJ; INFO="SUBPROGRAM"
Second, add the compiled program to an RL file using LINKEDIT/XL.
:RUN LINKEDIT.PUB.SYS
LinkEd> BUILDRL PROGRL
LinkEd> ADDRL PROGOBJ
LinkEd> EXIT
Third, compile the main program like any other Transact/iX program.
:TRANXL MAIN, MAINOBJ
Fourth, link the main program with the RL file containing the subprogram.
:LINK FROM=MAINOBJ; TO=MAINPROG; RL=PROGRL
Last, run the main program.
:RUN MAINPROG
Example of Static Calls with Load-Time Linking.
This example shows how to use load-time linking with the same two
programs used in the example above. The steps for the subprogram are the
same, except the responses to the LINKEDIT prompts specify XL instead of
RL.
First, compile the subprogram into PROGOBJ using the SUBPROGRAM compiler
option.
:TRANXL PROG, PROGOBJ; INFO="SUBPROGRAM"
Second, add the compiled subprogram to an XL file using LINKEDIT/XL.
:RUN LINKEDIT.PUB.SYS
LinkEd> BUILDXL PROGXL
LinkEd> ADDXL PROGOBJ
LinkEd> EXIT
Third, compile and link the main program like any other Transact/iX
program. You can combine these steps by using TRANXLLK, no special
options are needed in this step.
:TRANXLLK MAIN, MAINPROG
Last, run the main program with the XL= option to name the XL file
containing the subprogram.
:RUN MAINPROG; XL='PROGXL'
Dynamic Calls.
No special techniques or parameters are required to compile or link a
Transact compiled program which uses only dynamic calls. However, the
command RUN progname must include the XL = option, and an XL (the
preceding example shows how to create an XL) containing all the called
programs must be available at run time.