Regardless of the approach you take, it is recommended that you review at a minimum the chapters Before you start , Compiling with SPLash! , and Beyond SPL .

In most cases, very few changes are required to successfully compile your original SPL source with SPLash!. If you do need to implement source code changes, you have several resources to work with. First, SPLash! CONTROL options are provided that ease migration analysis and testing of SPL code. Second, a cross-reference utility program, XREF, is provided to help with the analysis of your SPL code. Third, several SPLash! debug macros are provided for use with the HP debugger (see Appendix E). Appendix A discusses native mode and privileged mode Assemble instructions. And finally, Appendix B covers intrinsic differences between MPE V and MPE/iX.

Introduction

This chapter guides you through the installation process, step by step. There are two methods for installing SPLash! so that you can choose the installation procedure that best suits your needs.

Updates can be installed over the existing SPLASH account. Or, SPLash! can be installed in a uniquely named account. The advantage of the later is that the update can be tested before being rolled into a production environment.

The Role of Privileged Mode in SPL Environments

Over the years, much SPL code has been written to run in privileged mode (PM). The rational for this was to eliminate the normal checks of HP3000 microcode or the MPE operating system, opening up the opportunity for data to be read or modified anywhere in the system. The dangers of using PM were, in these cases, outweighed by the ability to programmatically determine information about the runtime environment. Given the constraints of the environment, such information was simply not available through standard MPE interfaces. Introducing PM code solved the information gap problem.

PM operations in the SPL environment are extremely difficult, if not impossible, for SPLash! to support. Fortunately, the paucity of PM support SPLash! isn't a problem in most cases. Standard intrinsics, as well as AIF intrinsics, offer standard, replacement solutions to outdated PM code. The primary focus of this chapter, then, is pointed towards those rare occurrences where adequate solutions are either tricky to implement or simply not available. Background information is provided, however, that may assist you in developing an optimal solution.

Unsupported CM Instructions

This section documents those CM Instructions that SPLash! does not support.

These instructions all depend upon the fact that the HP3000's memory was partitioned into banks of 64K words each in an attempt to overcome the 16-bit address limitation. All are privileged, and most are typically used only by low level system code.

Code employing any of these instructions will have to be re-examined and may need re-coding per the recommendations in the previous discussion titled "The Role of Privileged Mode in SPL Environments". SPLash! supports LDEA, LSEA, SDEA, and SSEA. The file MDS.INC.SPLASH contains details on these instructions.

These instructions are also highly privileged. These however, depend upon architectural features of the MPE V-based HP3000's rather than the memory structure. Some, such as UNLK and LOCK, were implemented to support multiple CPU's. Others, such as PSDB, PSEB, DISP, and IXIT interact with the dispatcher and ICS in a way that is highly specific to the MPE V-based HP3000's. The dispatcher under MPE/iX is not launched by microcode (there is none), and therefore these instructions have no meaning. The others are typically used by low level code in the operating system kernel. These particular opcodes are not even simulated by the compatibility mode emulator in MPE/iX.

Code employing any of these instructions will have to re-examined and re-coded per the recommendations in the discussion (above) titled "The Role of Privileged Mode in SPL Environments".

Be sure to read the discussion titled "The Role of Privileged Mode in SPL Environments" in this document if you have any of the instructions listed above in your code. These instructions are all privileged and fall into the category of instructions that were implemented for specific HP3000 models. For example, the WIO, RIO, CIO and TIO instructions only existed on the HP3000 Series II/III.

If code employs these instructions, it is highly specific to a particular HP3000 series and is not transferable to a newer machine, much less to an HPPA based Series 900. It is suggested that migration assistance be employed with this type of code.

This includes the set of instructions which loads words of code onto the stack and all instructions which can do branches. The LDPP and LDPN instructions were created to allow constants to be loaded from code. This is done if a constant in a calculation is greater than 8 bits, in which case an immediate instruction could be used. Because code is not highly differentiated from data in HPPA, instructions which specifically load code literals do not exist. SPL code that uses these assemble instructions should be re-coded to employ a simple TOS := literal (or constant) statement.

The branching machine instructions absolutely depend upon the 16-bit orientation of MPE V-based HP3000 instruction words. For example, the statement BR P+20 branches from the current location to the location 20 machine instructions away. This could very well be outside of the assemble statement and in the SPL statements occurring after the assemble. There is no problem with the p-relative branch since in standard SPL, those subsequent statements are translated into 16-bit machine instructions.

The translation of this 16-bit machine instruction word format is very difficult in HPPA. For this reason, SPLash! does not attempt to interpret what would have been generated on a stack-based HP3000. SPL code that employs p-relative addressing must be changed to use a branch to a label. For example:

ASSEMBLE (BR P+20);
     .
     .
     .
I := 4 + J;   << P + 20 >>

ASSEMBLE (BR LAB1);
     .
     .
     .
LAB1: I := 4 + J;

These statements are used to manipulate the registers resident on the HP3000 processor boards. As with any architecture, the use and philosophy of the registers describes to a large extent the machine architecture itself. Since HP Precision Architecture is quite different than the traditional HP3000 architecture, some of the registers do not translate well to the new architecture.

In order to simulate the SPL environment, SPLash! maintains simulated copies of most of the HP3000 registers. Thus, Q, S, Z, and the DL registers are all available for use by the SPLash! programmer. In standard SPL, pushing the DB register is a privileged operation. In addition, it pushes the bank number and absolute offset in the bank onto the stack. As presented in Discussion 1, these concepts have no meaning on the 32-bit HP Precision Architecture. Pushing of the DB register now causes SPLash! to push the 32-bit HPPA register pointing to the simulated DB area in the SPLash! program's native mode (NM) stack.

Pushing and setting of the Status register is partially supported. Some of the fields within the status register, such as the "right bit" (which stackop is being executed) are meaningless in HPPA. The same is true of the code segment number. The following shows the status register format on MPE V-based HP3000's with the fields that are supported under SPLash! when executing the PUSH statement or PSHR instruction:

M | I | T | R | O | C | CC | CST #

M     Set to 0 if NM exec level = 3  
      Set to 1 if NM exec level < 3
I     Always set to 1
T     Always set to 0
R     Always set to 0
O     Set as it would be on an MPE V-based HP3000
C     Set as it would be on an MPE V-based HP3000
CC    Set as it would be on an MPE V-based HP3000
CST # Always set to 0

The CON construct is partially supported by SPLash!. Using CON in standard SPL, it is possible to drop any sort of data into the code stream which is subsequently interpreted by the microcode. The most common uses for CON are to build PB arrays and to form machine instructions whose assemble mnemonics are not recognized by SPL.

Most of these privileged instructions are supported by SPLash! to the same extent that they are supported by the compatibility mode emulator on MPE/iX. They are flagged here as warnings that the semantics of their operation may change under MPE/iX. Please refer to the discussion titled "The Role of Privileged Mode in SPL Environments". See also the file called MDS.INC.SPLASH .

Overview

SPLash! can be used to compile standalone programs or individual modules. The output of a standalone program compilation is a native mode program file (NMPRG). While the output of an individual module compilation is a native mode object file (NMOBJ). SPLash! NMOBJs can call or be called from any other native mode language (except for procedures that are compiled with the $SPLASH compiler option). The sections that follow review the various SPLash! UDCs and command files. Several sample compilations using SPLash! are also offered.

SPLash! is delivered with two different UDC files which are located in the SPLASH account: SPLASHU (default) and SPLASHV. Each UDC file contains several UDCs that can be used to compile, assemble, or link your SPLash! programs. The default UDCs are oriented towards program development on the /iX, while SPLASHV UDCs are similar in function to the SPL UDCS.

By default, the SPLASHU UDCs are cataloged when SPLash! is installed. Please refer to the HP MPE Command Reference manual for details on the SETCATALOG command if you wish to modify the SPLash! UDCs.

splash foo                ! compile
asmlk foo                 ! assemble & link

 A group called ASM exists which will be used to hold the assembler output from the SPLash! compiler.

 A group called O exists, which will be used to hold the assembled files created by the assembler.

 Linked programs reside in the PUB group. Linking is produced by using the LINK command.

 The file to be compiled is always in the current logon group.

The UDCs in SPLASHU.PUB.SPLASH provide quick access to the SPLash! compiler, but they require that you first define the specific group structure outlined above and then follow the conventions for maintaining your source and output files.

If you installed the software using the steps outlined in the Installation chapter, these groups will have been created for you.

Each of the UDCs are described next.

splash source, parm=0, list=$STDLIST, info=" ", arecs=40000

 

asmlk source, opt=" ", priv=3, cap="ia,ba", list=$NULL, arecs=2000

 

asmobj source, opt=" ", list=$NULL, arecs=2000

 

The UDCs in SPLASHV closely parallel the MPE commands: SPL, SPLPREP, and PREP. They make no assumptions about naming conventions.

SPLASHV UDC Descriptions

SPLLK Compiles from <source>, assembles, links; the result is in $OLDPASS.

spllk source, parm=0, priv=3, cap = "ia, ba"

 

splash source, parm=0, list=$STDLIST, info=" "

 

asmlk source=SPLASSM, opt=" ", priv=3, cap="ia,ba", list=$NULL

 

asmobj source=SPLASSM, opt=" ", list=$NULL

This section discusses UDC parameters for all of the SPLash! UDCs.

Parameter	Default	Description
source		The name of the file to be compiled or assembled. You must specify this parameter; there is no default value.
parm	0	This parameter is reserved for use by SPLash! developers. Do not specify a value other than the default. Note that this parameter is different from SPL's parameter of the same name. Unlike SPL, the SPLash! compiler automatically opens the formal files SPLTEXT, SPLLIST, and SPLASSM; you need not specify a compilation parameter to accomplish this.
priv	3	Specifies the privilege level to be assigned to your program's outer block. When your program runs, it willautomatically execute at this privilege level. Two values are allowed: 3 = User Mode 2 = Privileged Mode Values 1 and 0, which represent more powerful privileged modes, are not allowed by Hewlett-Packard. The MPE/iX loader will not load a file linked with privilege level 1 or 0.
cap	"ia,ba"	Specifies the capabilities to be assigned to your program when it executes. When coding this parameter, you must specify one or more of the following capabilities, separated by commas and enclosed in quotes. ia Process can run interactively. ba Process can run in batch. mr Process can access multiple system resources concurrently. ds Process can create and use data segments. ph Process has the ability to perform process handling. It can control or create other processes and can obtain information about executing processes. pm Process can run in privileged mode (that is, at ring level 2) or can call procedures that run in privileged mode. Note that this is different from the priv parameter, described above, which specifies the default execution mode for a program's outer block. You can specify pm for modules as well as programs; they will not begin executing in privileged mode but will be able to switch to privileged mode execution or to call privileged procedures.
arecs	40000	Specifies the maximum size, in records, for the intermediate assembler file generated by the SPLash! compiler. If this file is not big enough, the compiler will complete its processing and then issue a message indicating how big the file should be.
orecs	2000	Specifies the maximum size, in records, for the native mode object (NMOBJ) file that the assembler produces after processing the SPLash! compiler output. In MPE/iX, the NMOBJ file is equivalent to SPL's USL file.
opt	" "	Specifies optional text that you wish to pass to the assembler.
info	" "	Specifies an optional text string that contains compiler directives. Code one or more compiler control options separated by commas; enclose the list in quotes. (See Chapter 6, Beyond SPL for a list of compiler control options.) Do not include a $ before the first option; the SPLash! compiler will automatically insert this symbol. The compiler will interpret this string as the first line of compiler input.
list	$STDLIST	The default for the SPLASH UDCs in both SPLASHU and SPLASHV is $STDLIST, for the other UDCs (e.g. ASMLK, ASMOBJ, etc.) the default is $NULL.

Compiling Standalone SPLash! Programs

This section shows, through examples, how to use the SPLash! UDCs to compile, assemble, and link a standalone program. These examples use the UDCs provided in SPLASHU which are described earlier in this Chapter. It may be helpful to review that section if you haven't already done so.

Compiling

Suppose you have created a SPLash! program by entering source code into a file named FOO in your logon group. To compile this program, just type:

splash FOO

The "splash" UDC compiles the source file and generates a file with the same name in your ASM group. This new file, FOO.ASM, contains assembly language code. The listing is routed to $STDLIST. Since no additional parameters are specified, the default values are used, as described earlier in this section. Note that, like SPL, SPLash! produces machine code even if syntax errors are found (although this means that the code generation process might fail).

If you wish to specify parameters, you can do so the same way that you would for any UDC: by coding positional values or by preceding values with parameter keywords. Note that if you use positional values, you must specify values in the proper order and separate them with commas. If you use keywords, you can specify the parameters in any order, but you must separate them with semicolons.

For example, using positional parameter values, you can compile the program FOO using a larger intermediate assembler file and send the listing to a deferred printer by typing:

file defer;dev=lp,1;cctl
splash BIGFILE, , *DEFER, , 80000

Or, you can compile the program and suppress the listing, using keyword parameters, by specifying:

splash source=FOO; list=$NULL

If you want to compile a larger assembler file (80000 records), and send the listing to a deferred line printer, you would issue the following commands:

file defer;dev=lp,1;cctl
splash source=BIGFILE; list=*DEFER; arecs=80000

After successfully compiling the program FOO, you must assemble and link it before executing it. You can use the "asmlk" UDC to assemble from FOO.ASM to FOO.O, then link FOO.O to FOO.PUB, by typing:

asmlk FOO

To assemble FOO.ASM to FOO.O and then link FOO.O to FOO.PUB with privlevel 2 (privlev 2 corresponds to MPE V's PM) you would issue the following statement:

asmlk FOO, , 2

This is the privlevel needed to be able to perform "privileged" operations, like opening a file with a negative file code. Note that the MPE XL loader will refuse to load a file linked with privlev 0 or 1.

Alternatively, you can perform the same steps using the "asmobj" UDC with MPE/iX LINK command using the following statements:

asmobj FOO
link from=FOO.O; to=FOO.PUB

spllk FOO

SPLash! Command Files

These command files are functionally similar to the compiler command files that HP provides with their compiler products. These command files are located in the PUB group. In order to use these files, you should either move them to PUB.SYS or to a group that is in the path (HPPATH) for SPLash! users.

Like HP's compiler command files, SPLash! command files do not rely on the presence of special groups nor are they limited to compiling files in the current group. There are 4 command files for the SPLash! compiler.

Compilation Command Files

SPLXL	Compiles SPL source to assembler output file.
SPLOBJXL	Compiles SPL source to native mode object file.
SPLLKXL	Compiles & Links SPL source to native mode program file.
SPLXLGO	Compiles & Links SPL source to $OLDPASS, and then runs $OLDPASS.

Unlike the HP compiler command files, the SPLash! command files have several parameters used during the assemble stage. These parameters, along with the standard parameters, are explained next.

Command File Usage

The contents of command file are listed next.

splxl    [text][,[asm]][,[list]][,[info]]
         [,[parm]][,arecs]

splobjxl [text][,[obj]][,[list]][,[info]]
         [,[parm]][,[arecs]][,orecs]

spllkxl  [text][,[prog]][,[list]][,[info]]
         [,[parm]][,[arecs]][,[orecs]][,[cap]][,priv]

splxlgo  [text][,[list]][,[info]]
         [,[parm]][,[arecs]][,[orecs]][,[cap]][,priv]

The following list describes each of the parameters used in the command files.

text  = Source SPL file
asm   = Output assembler file, defaults to $oldpass
obj   = Output native mode object file, defaults to $oldpass
list  = List file, defaults to $stdlist
info  = Pass options to SPLash!, default is null
parm  = Pass parms to SPLash!, default is 0
arecs = Max size of assembler output file, default = 40000 records
orecs = Max size of native mode object file, default = 2000 records
cap   = Capabilities for program file, default=IA,BA
priv  = Priv level for program file, default = 3 (user)

Note —Detailed information on these parameters is explained in the section called UDC Parameter.

You can code a SPLash! module and then call it from a SPLash! program, another native mode language program, or both. This section describes which options to specify and how to compile your module.

Examples in this section assume we have a source module called UPSHIFT.MODULE which contains the following code:

$control subprogram begin procedure upshift (text', bytes); value bytes; byte array text'; integer bytes; begin integer left := 0, ! counts from bytes to 0. len := 0; ! # bytes upshifted at one time byte array text'copy' (0 : bytes); ! 1 longer then text' byte pointer ptr; ! points along text'copy' move text'copy' := text', (bytes); text'copy'(bytes) := 0; ! append a stopper byte @ptr := @text'copy'; if (left := bytes) <= 0 then return; ! nothing to do while left > 0 do begin len := move ptr := ptr while ans; @ptr := @ptr(len); if (left := left - len) > 0 then begin ! more text left... @ptr := @ptr(1); ! skip the non-alphanumeric left := left - 1; ! and adjust left by -1. end; end; ! put upshifted text back into text'... move text' := text'copy', (bytes); end <<upshift proc>>; end.

Also, we have a program called UPPER.SOURCE which is:

begin ! upshifts INFO text and prints it integer info'len = q - 6; byte pointer info'text' = q - 5; intrinsic print; procedure upshift (text', bytes); value bytes; byte array text'; integer bytes; option external, splash; upshift (info'text', info'len); print (info'text', - info'len, 0); ! gets a warning end.

The next examples illustrate this process using the UPSHIFT module and the program UPPER.SOURCE for both the UDC and the command file approaches to compilation.

Compiling & Assembling with the SPLash! UDCs

chgroup MODULE
splobj UPSHIFT, , , "CONTROL SPLASH"

This compiles UPSHIFT.MODULE into UPSHIFT.ASM and then assembles it into UPSHIFT.O. See Chapter 5, Parameters, Procedures & Conventions for details on "CONTROL SPLASH".

chgroup SOURCE
splobj UPPER

This compiles UPPER.SOURCE into UPPER.ASM, then assembles it into UPPER.O.

Linking

link from=UPPER.O, UPSHIFT.O; to=UPPER.PUB

UPPER.PUB is now compiled, linked, and ready to run.

Running

run upper.pub;info="hi there"

This section discusses using SPLash! to compile a module which will be used by another native mode language program.

Note —SPLash! prefers to pass its parameters on the stack via SPL, while most other native mode languages prefer to pass their parameters in a combination of registers and the stack.

Unlike other NM languages, SPLash! generates procedures with either type of parameter passing. The OPTION SPLASH and OPTION NATIVE syntax is used to state whether a particular procedure uses stack-based (splash) or register-based (Native) conventions.

The following example uses the same upshift procedure, but this time it is called from a Pascal/iX program called UPPAS.

The UPPAS Source File

$os 'mpexl'$ $type_coercion 'representation'$ program uppas (output, info); type pac400 = packed array [1..400] of char; var info : string [400]; text : pac400; procedure upshift (var text : pac400; len : shortint); external spl; begin strmove (strlen(info), info, 1, text, 1); upshift (text, strlen(info)); strmove (strlen(info), text, 1, info, 1); writeln (info); end.

Compiling & Assembling with the SPLash! UDCs

chgroup MODULE
splobj UPSHIFT, , , "CONTROL NATIVE"



Compiles UPSHIFT.MODULE into UPSHIFT.ASM and finally into UPSHIFT.O,
marking all unspecified procedures as native mode callable.

chgroup SOURCE
pasxl UPPAS, UPPAS.O

Compiling & Assembling with the SPLash! Command Files

splobjxl  upshift.module,upshift.o,,"control native"

chgroup SOURCE
pasxl UPPAS, UPPAS.O

Linking

link from=UPPAS.O, UPSHIFT.O; to=UPPAS.PUB

Running

run UPPAS.PUB;info="hi there"

This section discusses compiling separate modules with SPLash! and then calling them from both SPLash! programs and from other native mode language programs.

In the previous example, if the UPSHIFT routine is compiled as:

chgroup MODULE
splobj UPSHIFT, , , "CONTROL NATIVE"



Compile UPSHIFT.MODULE into UPSHIFT.O, marking all unspecified
procedures as native mode callable.

Then, it can be easily used by other native mode language programs as shown earlier. But, it can also be called by SPLash! programs if the procedure is referenced by specifying "OPTION NATIVE" in its external declaration:

procedure upshift (text', bytes);
         value   bytes;
         byte array text';
         integer bytes;
      option external, native, nocc;

Native Mode Concepts

This section discusses concepts used throughout this manual. The information in this chapter will effect how you declare variables, procedures, and intrinsics. A table on SPLash! register usage is included at the end of this chapter.

Unfortunately, a small number of intrinsics have parameters that must be 32-bit aligned. One example is the GETHEAP intrinsic. The by-reference pointer parameter (a 32-bit address) must be 32-bit aligned.

If a particular procedure declaration does not specify "splash" or "native", a default is chosen depending on several considerations. The following table shows the various combinations. Defaults were selected based on how separate compilations would most likely be used.

In the following table, combinations that produce the same results for a given type of compilation are grouped together:

compile
 unit       Int=    Ext=     external forward actual  Note#
-------     ----    ----     -------- ------- ------  -----
program     (none)  (none)   native   splash  splash  #1
program     splash  native   native   splash  splash
program     splash  (none)   native   splash  splash
program     (none)  native   native   splash  splash

 

program     native  native   native   native  native
program     native  (none)   native   native  native

 

program     splash  splash   splash   splash  splash
program     (none)  splash   splash   splash  splash

 

program     native  splash   splash   native  native  #2

 

subprogram  (none)  (none)   native   native  native  #3
subprogram  native  native   native   native  native
subprogram  native  (none)   native   native  native
subprogram  (none)  native   native   native  native

 

subprogram  splash  native   native   splash  splash
subprogram  splash  (none)   native   splash  splash

 

subprogram  splash  splash   splash   splash  splash

 

subprogram  (none)  splash   splash   native  native  #2
subprogram  native  splash   splash   native  native  #2

Note 2: This combination is not meaningful, as native-mode procedures cannot call splash-mode procedures.

Note 3: This is the default for subprograms.

$control native implies $control internal=native, external=native

$control splash implies $control internal=splash, external=splash

SPLash! HPPA Register Usage

Variable Declaration: VIRTUAL & FULLVIRTUAL

SPLash! has two additional keywords that can be used to declare variables: VIRTUAL and FULLVIRTUAL. Variables can be declared as normal, or have an optional "virtual" or "fullvirtual" preceding them.

A "virtual" variable is one whose address is somewhere in the short pointer space, and therefore requires 32 bits. Virtual arrays in the outer block may have up to 32767 bytes of initial values. All bytes past the initialization part will be zeroed.

A "fullvirtual" variable is one whose address requires a full 64 bits.

An example of using FULLVIRTUAL is shown below, comparing it to a similar Pascal/iX procedure:

The following options are all available in the "option" statement of a procedure declaration.

NATIVE

SPLash! Compiler Dollar Options

SPLash! recognizes all of the compiler control statements of SPL as well as a number of new options.

SPLash! allows multiple dollar options on a single line. The word "CONTROL" is optional and all types of compiler options may be intermixed on a single line. For example, the following code segments are equivalent:

$control segment = foo, errors = 9
$set x9 = on
$if x4=on
$   control list
$if

$segment=foo, errors = 9, x9=on, if x4=on, $list, $if

With the exception of quoted string parameters, options must be complete on a single line of input. Options using quoted strings (e.g., COPYRIGHT or TITLE) can be continued on subsequent lines terminating all lines but the last with an ampersand (&).

If SPLash! is run with an INFO parameter, that text is used as the initial dollar options. Currently, SPLash! limits the INFO string to 72 bytes. If SPLash! detects more than this amount, a warning is generated. Examples of running SPLash! with an INFO parameter are:

:run splash.pub.splash;info="control dl=0"

Or,

:run splash.pub.splash;info="dl=0, list, set x9=on"

If SPLASHG.PUB.SYS does not exist, no error message is given and no extra output appears on the compilation listing. However, if SPLASHG.PUB.SYS exists, then the records will be listed just as any other $INCLUDE file records would be listed (assuming $LIST is in effect). SPLASHG.PUB.SYS may be file equated to a different file.

During SPLash!'s first pass it looks at the INFO string for the option "NOSPLASHG". If the option isn't found, SPLash! opens and parses the option list in SPLASHG.PUB.SYS . Next, the INFO= string is parsed. After SPLASHG and INFO= are parsed SPLash! proceeds with processing the remaining code in the source file. Knowing the order in which SPLash! processes allows you to keep your "standard" options in SPLASHG, and then override them with INFO= when necessary.

Dollar Options: Reference Listing

This section lists each option. Descriptions, syntax, and examples are included as needed.

 


At the end of this chapter you'll find a table summarizing the default value and functionality for each dollar control option.

In showing the syntax of the options, brackets ([ ]) enclose optional parameters. Braces ({ }) enclose a list of parameters from which exactly one choice must be made. Most options may be preceded with "[NO]" at the start of the option name. For example:

$NOASMCOMMENTS      ! No comments in .ASM output file.

In some of the options the phrase "at the end of compilation" is used. This means: "as of the time when the final END. is read.".

Comments in the form of "<<....>>" are allowed in compiler option lines. Comments of the form "!" throw away the rest of the option line.

Because SPLash! accepts multiple options on a single line, all options are listed below in a single alphabetic list, even though the SPL manual would have grouped "CONTROL" options separately from options like "IF" and "PAGE".