HP 3000 Manuals

HP Pascal/iX Programmer's Guide

Compilation Unit Structure 

A compilation unit is a unit of source code that can be compiled
independently of other code (for example, a program is a compilation
unit; a block is not).

You can design your program in two ways:

   *   As a single compilation unit.  In this case you must compile the
       entire program at once.

   *   As two or more compilation units.  In this case you can compile
       one unit at a time, or you can compile in groups.  This is also
       known as separate compilation.

If your program is small, design it as a single compilation unit; it will
compile quickly because it is small.  (The example program in the section
"Program Block" is a single compilation unit.)  If your program is large,
design it as two or more compilation units.  This saves compilation time
over the course of program development because you can correct and
recompile one unit without recompiling the whole program.

The recommended design for a program with separate compilation units is
modular; in other words, it is composed of separate compilation units
called modules.  For compatibility with Pascal/V, HP Pascal also supports
global and external compilation units.  You can design your program using
these separate compilation units, if you prefer.  You can mix modules and
global and external compilation units.

Modules 

A module is a compilation unit that defines whatever constants, data
types, variables, functions, and procedures you want.  A program or
another module can import the module, thereby gaining access to the
definitions that the module exports.  The definitions that the module
does not export are accessible only to the module itself.

Figure 2-2  illustrates the syntactic structure of a module.  For the
exact syntax of a module and its components, refer to the HP Pascal/iX 
Reference Manual or the HP Pascal/HP-UX Reference Manual, depending on
your implementation.


          Figure 2-2.  Syntactic Structure of a Module 

A module's import declaration specifies the other modules that it
imports.  It can access items in the imported modules' export
declarations.  The import declaration can also be used to specify export
of entire modules a second time.

A module's export declaration specifies the constants, data types,
variables, functions, and procedures that it exports to the modules or
programs that import it.  A module defines its exportable routines in its
implement part.

A module's implement part defines constants, data types, variables, and
routines.  The routines are accessible only to the module itself, unless
they are exported in the export declaration.

Example 


            

Figure 2-3 .  shows what a module can access.


          Figure 2-3.  What a Module Can Access 

A module must be compiled before a program or another module imports it
(therefore, two modules cannot import each other).

For the compiler to compile a module with a program, the program must
define the module in its declaration part.  After defining this module,
the program can import it.

When compiling a module independently of a program, the compiler stores
the compiled module in the object file or in an alternate file named in
the MLIBRARY option (if the MLIBRARY option is specified).

When compiling modules separately or with a program, the placement of the
compiler output depends on whether the MLIBRARY option is used.  If
MLIBRARY is used, the module-text (in the IMPORT and EXPORT declaration)
is placed in the file specified with the MLIBRARY option.

If MLIBRARY is not used, the module-text is placed into the object file
along with the object code.  The module-text present in object files also
occurs in RLs (archive libraries), shared libraries, XLs, and program
files that were created from these object files unless stripped or the
Linkeditor's NODEBUG option is used.  Even though the module-text is an
unloadable space, it does take up room in the file.

The compiler can extract the module-text from Mlibraries or from any of
the binary files discussed above.


NOTE  The compiler may not be able to extract this information if the
      file is loaded.


The importing program uses the compiler option SEARCH to tell the
compiler where to find the module.  The compiler options MLIBRARY and
SEARCH cannot specify the same library.  For more information on MLIBRARY
and SEARCH, refer to the HP Pascal/iX Reference Manual or the HP 
Pascal/HP-UX Reference Manual, depending on your implementation.

A program can define a module with the same name as a module in the
library that SEARCH specifies.  In that case, the program imports the
module that it defines, rather than the library module with the same
name.  If a library contains two modules with the same name, the second
one overrides the first.  The compiler does not warn you when you are
about to override an existing module.

When a program imports a module, the module and its exported items
(including the module's exported modules) belong to the global scope of
the program.  The items that the module does not export (those in its
implement part) also exist for the same lifetime as the exported items
that were compiled at the simultaneously, even though the program cannot
access them.

These non-exported items will not be put in the global symbol table if
each module is separately compiled.


NOTE  An exception to this rule occurs if any INLINE routines are
      exported.  In this case all items in the implement part are placed
      in the module-text and the symbol table when imported.  This
      includes any references to intrinsics, even those not used by the
      INLINE routines.  This also means that any $SYSINTR$ option used by
      the imported module must also be present in the importing module or
      program, along with the intrinsic file itself.  Because of this,
      you may want to create multiple smaller modules, one of which will
      contain the inline routines, but without any intrinsics declared.


Example 

Independently compiled modules (to be compiled together in a single
compilation unit):

     MODULE Mod1;  {Mod1 is in Mod1.o}
     EXPORT
        .
        :
     IMPLEMENT
        .
        :
     END; {Mod1}
     MODULE Mod2;  {Mod2 is in Mod1.o}
     IMPORT
        Mod1;      {Mod2 imports Mod1}
     EXPORT
        .
        :
     IMPLEMENT
        .
        :
     END; {Mod2}
     MODULE Mod3;  {This Mod3 is in Mod1.o}
     EXPORT
        .
        :
     END. {Mod3}

Program (to be compiled as a compilation unit that does not contain the
above modules -- the program imports the modules from the above
compilation unit):

     PROGRAM prog;
        .
        :
     MODULE Mod3;  {The program defines this Mod3}
        .
        :
     END; {Mod3}
     $SEARCH 'Mod1.o'$
     IMPORT
        Mod2,      {Mod2 comes from the library Mod1.o}
        Mod3;      {Mod3 is the one that the program defined}
     BEGIN
        .
        :
     END.

Global, Subprogram, and External Compilation Units 

A global compilation unit defines global constants, data types, and
variables within a Pascal program.  It also contains the body of the main
program.  Syntactically, it is a program that begins with the GLOBAL
compiler option.  For more information on the GLOBAL compiler option,
refer to the HP Pascal/iX Reference Manual or the HP Pascal/HP-UX 
Reference Manual, depending on your implementation.

A subprogram compilation unit defines subprogram constants, data types,
and variables within a Pascal program.  Syntactically, it is a program
that begins with the SUBPROGRAM compiler option.  For more information on
the SUBPROGRAM compiler option, refer to the HP Pascal/iX Reference 
Manual or the HP Pascal/HP-UX Reference Manual, depending on your
implementation.

An external compilation unit declares the global variables that it needs
and defines routines that the global compilation unit and other
external compilation units can access using the EXTERNAL directive.
Syntactically, it is a program that begins with the EXTERNAL compiler
option and has an empty outer block.


NOTE  The EXTERNAL directive and the EXTERNAL compiler option are not the
      same.  For more information, see Chapter 9  in this manual and
      the HP Pascal/iX Reference Manual or the HP Pascal/HP-UX Reference 
      Manual, depending on your implementation.


You must compile global and external compilation units separately.  For
more information on program preparation see Appendix A  and Appendix B
.

For more information on the EXTERNAL compiler option, refer to the HP 
Pascal/iX Reference Manual or the HP Pascal/HP-UX Reference Manual,
depending on your implementation.

MPE/iX 5.0 Documentation