HP OpenVMS Systems Documentation

HP Pascal for OpenVMS
User Manual

Data items that are smaller than 32 bits might impose a performance penalty, due to the additional instructions required to access them. The compiler will attempt to reorder loads and stores that manipulate adjacent items smaller than 32 bits to minimize the number of memory references required.

For performance reasons, HP Pascal on OpenVMS I64 and OpenVMS Alpha systems will allocate Boolean and enumerated types as longwords in unpacked records or arrays. On OpenVMS VAX systems, you have to explicitly request this with a DCL qualifier or the corresponding attribute.

You should avoid any explicit size attributes on subrange types. While it is true that [BYTE] 0..255 is smaller than 0..255 (which would allocate 4 bytes, since it is a subrange of INTEGER), the additional overhead of accessing the byte-sized subrange might be than the extra 3 bytes of storage. Using the BIT attribute on subranges is even less effective in terms of the extra instructions required to manipulate a 13-bit integer subrange inside a record. Use these attributes only where needed.

9.7.5 Converting Existing Records

When moving code from an OpenVMS VAX system to an OpenVMS I64 or OpenVMS Alpha system, you probably want to make sure that you are getting the best performance on the new system. To do that, you must use natural alignment on your record types.

9.7.6 Applications with No External Data Dependencies

If your application has no external data dependencies (such as no stored binary data files, no binary data transmitted to some external device), then the conversion is as simple as:

• Using the default natural alignment.
• Using the default enumeration size.
• Removing any uses of PACKED that are not needed.
• Removing any explicit positioning or size attributes that are not needed.
• Optionally reordering fields to place larger fields before smaller fields. This does not make the record faster, but does make it smaller.

Depending on your data types, the removal of any PACKED keywords or attributes may make little improvement in performance. For example, a PACKED ARRAY OF REAL is identical in size and performance to an unpacked ARRAY OF REAL.

HP Pascal has two features to help you identify poorly aligned records and how often they are used:

• The /USAGE=PERFORMANCE command-line option
  This option causes the compiler to generate messages for declarations and uses of record fields that are poorly aligned or poorly sized. For example:

  program a; type r = packed record f1 : boolean; f2 : integer; end; begin end.

  
  In this program the compiler can highlight the following:

  $ pascal/usage=performance test.pas f1 : boolean; .........^ %PASCAL-I-COMNOTSIZ, Component is not optimally sized at line number 4 in file DISK$:[DIR]TEST.PAS;32 f2 : integer; .........^ %PASCAL-I-COMNOTALN, Component is not optimally aligned at line number 5 in file DISK$:[DIR]TEST.PAS;32 %PASCAL-S-ENDDIAGS, PASCAL completed with 2 diagnostics

  
  In this example, the size of the Boolean field in the PACKED ARRAY is only 1 bit. Single bit fields require additional instructions to process. The integer field is not aligned on a well-aligned boundary for the target system. The /USAGE=PERFORMANCE qualifier gives performance information customized to the target system. For example, on an OpenVMS I64 or OpenVMS Alpha system, INTEGERs should be on a longword boundary; on an OpenVMS VAX system, INTEGERs need only be aligned on a byte boundary for "good" performance.
• The /SHOW=STRUCTURE_LAYOUT command-line option.
  This option causes the compiler to generate a structure layout summary in the listing file.
  This summary gives size and offset information about variables, types, and fields. It also flags the same information as the /USAGE=PERFORMANCE command-line option.
  For example, compiling the above program with the following command produces the following in the listing file:

  $ pascal/list/show=structure_layout test.pas

  Comments Offset Size ----------- ----------- ----------- 5 Bytes R {In PROGRAM A} = PACKED RECORD Size 0 Bytes 1 Bit F1 : BOOLEAN Align 1 Bit 4 Bytes F2 : INTEGER END

  
  This output shows the size of the record R as well as the sizes and offsets of the records fields. It also highlights any components that were poorly sized or poorly aligned.

If your application has external data dependencies, the process is more involved, since you have to isolate and understand the dependencies.

Possible steps when porting the code include:

• Using the /ALIGN=VAX qualifier
• Using the /ENUMERATION_SIZE=BYTE qualifier
• Using the /FLOAT=D_FLOAT qualifier (if you have any DOUBLE binary data)
• Leaving the code exactly as is

This should produce the same behavior on the OpenVMS I64 or OpenVMS Alpha system as you had on your OpenVMS VAX system with the following exception: Using D_Floating data on Alpha systems only provides 53 bits of mantissa instead of 56 bits as on VAX systems; using D_floating data on OpenVMS I64 systems causes the compiler to convert to/from D_Floating data and IEEE T_Floating data to actually perform any needed operations.

You then have to identify which records in your program have external data dependencies. These include binary files (for example, FILE OF xxx), shared memory sections with other programs, and binary information passed to a library routine (such as an OpenVMS item list).

You can immediately begin to convert records without external data dependencies into optimal format (for example, remove any unneeded PACKED keywords and attributes as described earlier).

You need to classify records with external dependencies further into:

• Records that cannot be naturally aligned due to a hard dependency that cannot be changed (like a record that maps onto an external piece of hardware, or a record that is passed to some software you cannot change).
• Records that can be changed after conversion of binary data or cooperating software.

Isolate records that you cannot change into their own environment file by using /ALIGN=VAX, /ENUM=BYTE, and /FLOAT=D_FLOAT. You can also attach the ALIGN and ENUMERATION_SIZE attributes to the TYPE or VAR sections that define these records. In this case, you need to also change any uses of the DOUBLE datatype to the D_FLOAT datatype, to ensure that the proper floating format is used.

You do not need to isolate the record if it uses the PACKED keyword, since PACKED records are identical regardless of the /ALIGN or /ENUM qualifiers. Nevertheless, isolating the records with dependencies might be useful in the future if you eventually intend to change the format.

For records that you might change, you need to decide whether it is worthwhile to convert the record and any external binary data. If the record is of low use and you have a large quantity of external data, the cost of conversion is probably too high. If a record is of high use but is mostly aligned, then the conversion also may not be worthwhile. However, a high-use record that is poorly aligned suggests conversion of external data regardless of the amount of effort required.

There are two types of poorly aligned records:

• Records that use the PACKED keyword
  PACKED records lay out the same with either setting of the /ALIGN or /ENUMERATION_SIZE qualifiers. To get natural alignment, you must remove the PACKED keyword. However, the keyword PACKED by itself does not guarantee poor alignment. For example:

  type t = packed record f1,f2 : integer; end;

  
  This record is well aligned with or without the PACKED keyword. It is also well aligned with /ALIGN=NATURAL and /ALIGN=VAX. You can remove the PACKED keyword for completeness, but nothing else needs to be done.
• Unpacked records that lay out differently with /ALIGN=NATURAL and /ALIGN=VAX
  These records automatically are well-aligned by the compiler when recompiled with /ALIGN=NATURAL. However, there are some unpacked records are already well-aligned with both alignment formats. For example:

  type t = record f1,f2 : integer; end;

  
  This unpacked record is well aligned with /ALIGN=NATURAL and /ALIGN=VAX. Nothing else needs to be done to this record.

The /USAGE=PERFORMANCE and /SHOW=STRUCTURE_LAYOUT DCL qualifiers can be helpful for identifying poorly aligned records.

For PACKED keywords, you can compile with and without the PACKED keyword to see if the fields are positioned at the same offsets or not.

You have classified the records with external data dependencies into:

• Records that are well-aligned with both alignment/enumeration formats
• Records that are poorly aligned, where conversion is not worthwhile
• Records that are poorly aligned, where conversion is worthwhile

For the well-aligned records, no additional work is needed now, but be aware that you still have an external data dependency that might cause problems if you add fields to the record in the future.

Isolate records that are not being converted into the same environment file or into the TYPE or VAR sections where you placed the records that you could not convert.

For records that are worth converting, you need to plan how to convert the external binary data or cooperating software. For cooperating software, you need to ensure that it gets modified so it views the record with the "natural" layout. You can determine the layout by using the /SHOW=STRUCTURE_LAYOUT command-line option described above. For binary data, you need to write a conversion program.

Converting existing binary data involves writing a program that reads the existing data into a poorly aligned record, copies the data into a well aligned record, and then writes out the new record.

A simple conversion program would look like:

program convert_it(oldfile,newfile);

[align(vax),enumeration_size(byte)]
type oldtype = packed record
               { Existing record fields }
               end;

type newtype = record
               { Record fields reorganized for optimal alignment }
               end;

var oldfile = file of oldtype;
    newfile = file of newtype;
    oldvar : oldtype;
newvar : newtype;

begin
reset(oldfile);
rewrite(newfile);
while not eof(oldfile) do
   begin
   read(oldfile,oldvar);

   { For each field, sub-field, etc. move the data }
   newvar.field1 := oldvar.field1;
   newvar.field2 := oldvar.field2;

   write(newfile,newtype);
   end;
close(oldfile);
close(newfile);
end.

Notice the "type" keyword before the definition of the "newtype" type. Without this keyword, "newtype" would be in the same type definition part as "oldtype" and would be processed with the same ALIGN and ENUMERATION_SIZE settings.

If you have embedded DOUBLE data, you must use the D_FLOAT predefined type in the "oldtype" definition, since the default on OpenVMS I64 systems is for T_floating format and the default on OpenVMS Alpha systems is for G_Floating format. The compiler does not allow a simple assignment of a D_FLOAT value to a T_FLOAT or G_FLOAT variable. You need to use the CNV$CONVERT_FLOAT routine provided with OpenVMS to convert the floating data.

This appendix lists the error conditions detected by the STATUS and STATUSV functions, their symbolic names, and the corresponding values. The symbolic names and their values are defined in the file SYS$LIBRARY:PASSTATUS.PAS, which you can include with a %INCLUDE directive in a CONST section of your program. To test for a specific condition, you compare the STATUS or STATUSV return values against the value of a symbolic name.

The symbolic names correspond to some of the run-time errors listed in Appendix C; however, not all run-time errors can be detected by STATUS.

There is a one-to-one correspondence between the symbolic constants returned by STATUS or STATUSV documented in PASSTATUS.PAS and the OpenVMS condition code values in SYS$LIBRARY:PASDEF.PAS. The following routine shows how to map the return value of STATUS to its corresponding condition code located in PASDEF.PAS:

FUNCTION CONVERT_STATUS_TO_CONDITION(STAT:INTEGER):INTEGER;
   BEGIN
      CONVERT_STATUS_TO_CONDITION := 16#218644 + STAT * 8;
   END;

Table A-1 lists the symbolic names and the values returned by the STATUS and STATUSV functions and explains the error condition that corresponds to each value.