The MAINSAIL compiler, by default, outputs the executable form of a MAINSAIL MODULE into a file (an objmod file) of which the name is formed from the name of the MODULE compiled.

Intmods are not executable. They contain information used during compilation of other MODULEs or used by MAINSAIL system programs. See Chapter 13 for more details.

Both objmods and intmods may be stored into libraries, which are files containing several MODULEs. Objmods are stored into objmod libraries, and intmods into intmod libraries; either type of library may be referred to as a MODULE library. MODULEs may be compiled directly into MODULE libraries (see Section 4.27 of the MAINSAIL Compiler User's Guide) or added to MODULE libraries with the utilities MODLIB (see Chapter 24 of the MAINSAIL Utilities User's Guide) and INTLIB (see Chapter 18 of the MAINSAIL Utilities User's Guide).

MAINSAIL may execute MODULEs from objmod files or from objmod libraries. Objmod libraries have several advantages over individual objmod files:

• When a system consists of several MODULEs, putting them into a library eliminates the need for individual objmod files, thus reducing clutter in the file system.

• An objmod library opened for execution is opened just once. Each MODULE that resides in an individual file instead of in an objmod library is individually opened during execution when it is first accessed. Opening a file is a time-consuming operation on many systems.

• Sometimes it is necessary to discard MODULEs from memory in order to make more room. A MODULE that does not reside in memory must first be written to a swap file (see Section 11.14) before its space is used. A MODULE that resides in a MODULE library open for execution need not be written to the swap file.

More information on MODULE libraries may be found in Chapter 24 of the MAINSAIL Utilities User's Guide.

14.1. Objmod and Intmod File Names

targetOSSpecificAbbreviation-int:moduleName

where the target-OS-specific abbreviation is either $systemNameAbbreviation or the first 3 characters of $systemNameAbbreviation, depending on the operating system (consult the relevant part of the MAINSAIL System-Specific User's Guides to determine which is used on the operating system you are interested in). This abbreviation is known as the file abbreviation for the target operating system (it can be determined within a program by calling $targetSystemBaseFileNameSuffix).

For example, a MODULE FOO compiled for a RISC System/6000 UNIX system (where $systemNameAbbreviation is uirs and the file abbreviation is uir) is compiled into an intmod file named uir-int:foo. A searchpath is usually set up for intmod file names. Bootstraps distributed by XIDAK specify a searchpath (see Section 21.2.35 of the MAINSAIL Utilities User's Guide for a description of the MAINEX SEARCHPATH subcommand) of the form:

SEARCHPATH *-int:* *2-*1.int

unless otherwise noted in the relevant part of the MAINSAIL System-Specific User's Guides. This searchpath would map uir-int:foo into foo-uir.int, where the intmod for FOO would be stored.

The default objmod file name as output by the compiler has the form:

targetOSSpecificAbbreviation-obj:moduleName

where the target-OS-specific abbreviation is the file abbreviation for the target operating system. For example, a MODULE BAR compiled for a SPARC UNIX system (where $systemNameAbbreviation is uspa and the file abbreviation is usp) is compiled into an objmod file named usp-obj:bar. A searchpath is usually set up for objmod file names. Bootstraps distributed by XIDAK specify a searchpath of the form:

SEARCHPATH *-obj:* *2-*1.obj

unless otherwise noted in the relevant part of the MAINSAIL System-Specific User's Guides. This searchpath would map usp-obj:bar into bar-usp.obj, where the objmod for BAR would be stored.

These file names and searchpaths are subject to change; those shown are correct for the current release, unless otherwise documented in the relevant part of the MAINSAIL System-Specific User's Guides.

14.2. Objmod and Intmod Search Rules

• IntSearch: an intmod search.

• ObjSearch: a non-executable objmod search, or just objmod search, as when recompiling or disassembling.

• ExeSearch: an executable objmod search, or just executable search, as when executing or debugging a MODULE.

A search is always for a particular target system. For example, an executable search is always for the host system. A cross-compilation requires intmods and objmods for the system for which the compilation is done.

The distinction between objmod searches and executable searches allows one version of an objmod to be executing while another version (possibly for a different target system) is used for another purpose, such as incremental recompilation.

By default, all searches first look in all open libraries (intlibs for intmods, objlibs for objmods), more recently opened libraries first, and then try to open a file with the default name, as described in Section 14.1. This search order may be reversed with the MAINEX INTFILE, OBJFILE, or EXEFILE subcommand (see below and Section 21.2.2 of the MAINSAIL Utilities User's Guide). The MAINSAIL system objlib is initially open for exeSearches.

An unsuccessful library search is always immediately followed by a foreign MODULE search in the case of exeSearches. The foreign MODULE table is constructed with the aid of the Foreign Language Interface; see Chapter 7 of the MAINSAIL Compiler User's Guide.

Each type of search is governed by a separate list:

• The intList governs intmod searches.

• The objList governs non-executable objmod searches.

• The exeList governs executable objmod searches (in conjunction with the MODULE-to-MODULE association list; see below).

Each entry on one of these lists indicates that a particular intmod or objmod is to be found in a particular file or library (or that the objmod is really another objmod, in the case of the MODULE-to-MODULE association list). The lists are empty unless an entry is specifically created (normally by a MAINEX subcommand, or by a MAINEX subcommand passed to $getSubcommands). In the absence of any entries, a default search occurs, which is often sufficient; the lists are used only to indicate exceptions to the default search mechanism. If a list indicates that a MODULE is in a particular library, then when a search is made for that MODULE, the indicated library is automatically opened if necessary.

Each entry on the lists contains the following information:

• the MODULE name,

• the file name in which it is to be found,

• whether the file is a library or a file that contains just one MODULE,

• and the target system to which the entry applies.

An exeSearch first checks the MODULE-to-MODULE-association list, as made by calling the PROCEDURE setModName (see Section 47.20) from a MAINSAIL MODULE or by specifying the MAINEX SETMODULE subcommand (see Section 21.2.37 of the MAINSAIL Utilities User's Guide). After the MODULE-to-MODULE substitution is made, if any, an exeSearch behaves like the other two types of search (there is no equivalent of the MODULE-to-MODULE association list for intSearches and objSearches). Each type of search checks its list to see whether the target MODULE has an entry (for the target system), and if so, insists on finding the intmod or objmod in the file or library specified by the entry. A list can have at most one entry with a given MODULE name and target system.

For each type of search, MAINEX subcommands are provided to add an entry to the list, remove an entry from the list, print (part of) the list, and to alter the normal order of search (libraries before files or vice versa). These subcommands are described in detail in Chapter 21 of the MAINSAIL Utilities User's Guide; here is a summary:

The search rules are complicated by the possible use of setModName and subcommands that specify search rules for individual MODULEs, but such individualized searches are often not needed.