HP OpenVMS Systems Documentation

HP Pascal for OpenVMS
Language Reference Manual

For example:

program example(output);
begin
writeln('Program running on ',%system_name,
      ' ',%arch_name,
      ' ',%system_version);
end.

This example uses the %IF directive to selectively provide declarations or code based on the architecture:

%if %arch_name = "Alpha"
%then
  var handle : integer := 0;
%elif %arch_name = "IA64"
%then
  var handle : integer64 := 0;
%endif

%COMPILER_VERSION returns a string containing the version string of the HP Pascal compiler performing the compilation.

11.9 %LINE, %FILE, %ROUTINE, %MODULE, and %IDENT

%IDENT returns a string that contains the ident string of the compilation that is set with the [IDENT()] attribute.

This chapter describes how the HP Pascal compiler allocates and represents program components. It discusses the following topics:

• Program sections ( Section A.1)
• Storage allocation and alignment for variables ( Section A.2)
• Internal representation of data types ( Section A.3)

This chapter describes how to establish program sections and program section properties. The HP Pascal compiler uses contiguous areas of memory, called program sections, to store information about a program.

The compiler writes these program sections to the object file. When constructing an executable image, the OpenVMS Linker divides the image into sections. Each image section contains program sections that have the same properties. The linker controls memory allocation by arranging image sections according to program section properties. You can use special linker options to change program section properties and to influence the memory allocation in the image. You include these options in a linker options file, which is input to the linker.

The OpenVMS Linker refers to the various characteristics of program sections as attributes. This chapter uses the term properties to avoid confusion with the HP Pascal attribute classes.

Table A-1 lists the possible program section properties on OpenVMS systems.

For More Information:

• On program sections and linker options (HP OpenVMS Linker Utility Manual)

Table A-2, Table A-3, and Table A-4 list the program sections that HP Pascal can establish, if necessary, on OpenVMS I64, OpenVMS Alpha, and OpenVMS VAX systems, respectively.

You can also establish user-defined program sections with the HP Pascal PSECT and COMMON attributes. The PSECT attribute directs the compiler to establish a separate program section for static variables or executable blocks. In this way, you can ensure particular program section properties for these objects. You can also choose to group them with related static variables and blocks to reduce the amount of paging overhead.

The COMMON attribute directs the compiler to establish a particular program section called a common block. A common block is an overlaid program section that contains one variable. By storing variables in common blocks, aHP Pascal program can share variables with programs written in other Hewlett-Packard languages.

The following example uses a common block to pass information between HP Pascal and HP Fortran:

HP Pascal Program:

PROGRAM Common_Example (OUTPUT);
VAR
   Myrec  : [COMMON(Example)] RECORD
      Intfld : INTEGER;
      Strfld : PACKED ARRAY [1..10] OF CHAR;
   END;
[EXTERNAL] PROCEDURE Call_Fort; EXTERNAL;

BEGIN
Myrec := ZERO;
Call_Fort;
WRITELN('Intfld = ',Myrec.Intfld);
WRITELN('Strfld = ',Myrec.Strfld);
END.

HPFortran Subroutine:

  SUBROUTINE CALL_FORT
C
  STRUCTURE /TEST/
      INTEGER*4 ITEM
      CHARACTER * 10 ITEM_NAME
  END STRUCTURE
C
  RECORD /TEST/ VAR
  COMMON /EXAMPLE/ VAR
C
  VAR.ITEM = 10
  VAR.ITEM_NAME = '0123456789'
  END

The HP Pascal program initializes the common record, Myrec, to zero, then calls the HP Fortran routine, Call_Fort, to assign the desired values to the elements within the common record. The HP Pascal program then writes the assigned values to your terminal.

Only one variable can be allocated in a particular HP Pascal common block. To share more than one data item in the same common block, the record variable containing all shareable items is declared and used.

For More Information:

• On the PSECT and COMMON attributes (Chapter 10)

Whether the compiler establishes a program section, or you create one, the program section is assigned one property from each class listed in Table A-1. These properties are assigned to satisfy the requirements of the types, variables, and executable blocks that have been allocated in the same program section. Table A-5 lists the minimal properties required by various objects.

The . ABS . and $ABS$ program section properties are ABS, NOEXE, NORD, NOWRT, and NOSHR. All other program sections except LIB$INITIALIZE are position independent and relocatable; all except those established by the COMMON attribute are concatenated and local. Program sections established by COMMON are overlaid and global. The remaining properties are assigned as follows:

• The first time the compiler encounters the name of a particular program section (including a common block), it initializes the program section to be readable, nonwritable, shareable, and nonexecutable. Thus, the program section's initial properties are LCL, NOEXE, NOWRT, CON, PIC, RD, REL, and SHR.
• If storage for any writable object (except common blocks on OpenVMS VAX) is allocated in the same program section, the program section instantly becomes writable and nonshareable. Thus, the program section's write property changes from NOWRT to WRT, and its share property changes from SHR to NOSHR.
• On OpenVMS VAX, if storage for a writable object in a common block is allocated in the same program section, the program section becomes writable and retains the shareable property. Thus, the program section's write property changes from NOWRT to WRT, and its share property remains SHR.

If you want to guarantee that read-only variables can never be modified, you can allocate storage exclusively for them in a separate program section that will always remain nonwritable.

A.2 Storage Allocation

The following sections discuss storage allocation of variables, symbolic constants, and executable blocks. Static types require no allocation. Nonstatic data types require allocation to store possible run-time values. Section A.2.3 gives an example.

For More Information:

• On allocation for nonstatic data types ( Section A.2.1)

When allocating storage for a variable, the compiler first determines an allocation attribute for the variable. If the allocation attribute is STATIC or COMMON, the compiler then chooses a program section in which to allocate storage. The compiler applies the following rules sequentially to determine the allocation attribute:

• If the variable is declared with an allocation attribute, the attribute specifies the variable's allocation.
• If the variable is declared with a visibility attribute other than LOCAL, its allocation is static.
• If the variable is declared in a routine, its allocation is automatic.
• If the variable is declared at the outermost level of a module, its allocation is static.
• If the variable is declared at the outermost level of a program, the compiler must choose between static and automatic allocation. Whenever possible, the compiler uses automatic allocation for variables that are referred to only in the body of the main program because automatic allocation is more efficient. The compiler uses static allocation if the variable is declared with the VOLATILE attribute, initialized at its declaration, referred to in a nested block, or if the program has an ENVIRONMENT attribute. Because program-level variables can be statically allocated, HP Pascal does not support recursive calls on the main program block.

The compiler applies the following rules sequentially to choose the program section in which to allocate storage for nonexternal common and static variables:

• If the variable has the COMMON attribute, storage is allocated in a common block that has either the same name as the variable, or the name specified by the identifier that accompanies the attribute.
• If the variable has the PSECT attribute, the identifier that accompanies the attribute supplies the name of the program section in which storage is to be allocated.
• If the variable does not have the COMMON, PSECT, or STATIC attribute, but is declared at the outermost level of an overlaid compilation unit, storage is allocated in the program section PAS$GLOBAL.
• If the variable has the READONLY attribute but does not have the PSECT, COMMON, or VOLATILE attributes:
  • On OpenVMS VAX systems, its storage is allocated in the program section in which storage for executable code is currently being allocated, by default, $CODE.
  • On all other systems, its storage is allocated in the program section $LITERAL.
• All other static variables are allocated in the program section $LOCAL.

For More Information:

• On attributes (Chapter 10)

When allocating storage for symbolic constants and executable blocks, the compiler determines the appropriate program section by applying the same rules of scope to program section names that it applies to identifiers. The compiler always allocates storage in the program section whose name appeared in the most recent heading of a routine or compilation unit.

Table A-3 and Table A-4 describe the program sections established for each kind of data in a program unless a PSECT attribute appears in the heading of routine or compilation unit and directs that storage to be allocated in a different program section.

For More Information:

• On the scope of HP Pascal identifiers ( Section 7.2)
• On the PSECT attribute ( Section 10.2.32)
• On the INITIALIZE attribute ( Section 10.2.22)
• On LIB$INITIALIZE (HP OpenVMS Programming Concepts Manual)

Example A-1 shows how the compiler establishes program sections to allocate storage for symbolic constants, variables, and executable blocks. The comments in the programs indicate the names of the program sections used.

PROGRAM Allocate_Variables (INPUT,OUTPUT);

CONST
   Message_String = 'Random String Literal';   { $LITERAL on OpenVMS I64 }
                                               { $LITERAL on OpenVMS Alpha }
                                               { $CODE on OpenVMS VAX }

VAR
   Magic_Number : [READONLY,PSECT(Magic)] INTEGER VALUE 42;          { Magic }
   Local_Variable : INTEGER;                   { $SDATA$ on OpenVMS I64 }
                                               { $DATA$ on OpenVMS Alpha }
                                               { $LOCAL on OpenVMS VAX }

[PSECT(Error_Routines)] PROCEDURE User_Error;

   CONST
      User_Error_Message = 'Internal Error';   { Error_Routines }

   VAR
      Error_Count : [STATIC] INTEGER VALUE 0;  { $SDATA$ on OpenVMS I64 }
                                               { $DATA$ on OpenVMS Alpha }
                                               { $LOCAL on OpenVMS VAX }
      Message_Buffer : VARYING [132] OF CHAR;  { Automatic Storage }
   BEGIN { Error_Routines }
   Error_Count := Error_Count + 1;
   Local_Variable := Error_Count;
   END;
BEGIN                                          { $CODE or $CODE$ }
   .
   .
   .
END.

Storage for all variables with static allocation is allocated in $SDATA$, $DATA$, or $LOCAL. Storage for the executable block of the main program is allocated in $CODE or $CODE$. Storage for the symbolic constant Message_String is allocated in $LITERAL on OpenVMS I64 and OpenVMS Alpha systems and in $CODE on OpenVMS VAX systems. Storage is allocated in the user-created program section, Error_Routines, for the symbolic constant User_Error_Message and the executable block of User_Error. Storage for Local_Variable is in $SDATA$ on OpenVMS I64 systems, $DATA$ on OpenVMS Alpha systems, and $LOCAL on OpenVMS VAX systems because it was referred to in a nested block. Storage for Magic_Number is in the user-created program section, Magic. Since Magic_Number was declared with the READONLY attribute, the program section has the NOEXE, NOWRT, RD, and SHR properties.