HP 3000 Manuals

Getting Started as an MPE/iX Programmer Programmer's Guide

Coding for Performance and Optimization 

The MPE/iX Optimizer modifies code to use machine resources efficiently,
using less space and running faster.  It improves code, but does not
alter the algorithm used in code.  Coding for good performance requires
recognition of the following facts:

   *   Coding practices alter performance.

   *   Mismatches exist between programming languages and most
       architectures.

   *   Coding techniques can enhance or inhibit optimization
       opportunities.

Coding for optimization provides the following methods of optimizing a
program at the source code level:

   *   Reduces or avoids aliasing
   *   Uses optimal data types
   *   Identifies common subexpressions
   *   Reduces procedure calls
   *   Avoids non-native alignment

Reduce Aliasing 

The compiler must generate explicit loads and stores when programs use
aliasing with pointers.  If you specify that the pointer does not change
(for example, by using WITH in HP Pascal/iX), you can eliminate some
loads and stores.  Thus, more optimization (such as using registers) can
occur.  Figure 5-1  shows an example of reducing aliasing.


          Figure 5-1.  Reducing Aliasing 

Use Optimal Data Types 

Examples of optimal data types are 8-bit character and 32-bit integer.
For detailed information refer to the appropriate manual in the Language
Series.

Eliminate Common Subexpressions 

You can improve the performance of optimized and unoptimized code by
using programmer identification of common subexpressions.  Figure 5-2  
shows an example of common subexpression elimination.


          Figure 5-2.  Eliminating Common Subexpressions 

Instructions Required for Operations on Simple Data Types 

Comparison of floating point instructions and integer instructions is not
valid because the floating point instructions may execute in a different
cycle from the integer instructions and may require synchronization.  The
instructions that compute floating-point arithmetic are done in a
coprocessor and do not execute in a single machine cycle.  However, the
instructions that compute integer arithmetic are done in a CPU and
complete in a single machine cycle.  Figure 5-3  shows examples of the
instructions for operations on simple data types.

These examples assume the following characteristics are true:

   *   Unoptimized code
   *   Well aligned operands
   *   No range or overflow checking


          Figure 5-3.  Instructions Operations on Simple Data Types 

Optimize Arrays 

The compiler does not always initialize array elements when an array is
created.  Ensure that all variables are properly initialized.
Uninitialized variables that did not cause problems on MPE V/E-based
systems may cause programs to abort on MPE/iX-based systems.  Figure 5-4
(*) shows examples of array optimization.


          Figure 5-4.  Optimizing Arrays 

Reduce Procedure Calls 

Procedure calls in code limit optimization because some registers cannot
be kept live (retain values) across calls.  You can remove calls to user
procedures from the main body of code and, instead, branch to a common
area.  Figure 5-5  shows an example of reducing procedure calls.


          Figure 5-5.  Reducing Procedure Calls 

Expand Small Procedures In-line 

Expanding a small procedure in-line increases the scope for the
optimizer, reduces procedure call overhead, and allows additional
constant folding of constant value parameters.  You should expand
procedures shorter than five lines.  Figure 5-6  shows an example of
expanding a procedure in FORTRAN 77/iX. In HP Pascal/iX, the you can use
the compiler option $OPTION INLINE$ to expand the code for a routine
in-line at the point of call.


          Figure 5-6.  Expanding Small Procedures In-line 

Extract Procedure Calls from Loops 

It is inefficient to code a loop containing only a procedure call because
of the required overhead by each procedure call.  It is a recommended
programming practice to code the loop inside the procedure.  Figure 5-7
(*) shows an example of extracting a procedure call from a loop.


          Figure 5-7.  Extracting Calls from Loops 

Avoid Non-native Alignment 

Figure 5-8  shows an example of avoiding non-native alignment.


          Figure 5-8.  Avoiding Non-native Alignment 

Optimize HP COBOL II/XL Data Types 

Optimizing HP COBOL II/XL data types requires recognition of the
following considerations:

   *   32-bit binary integers are desirable.  PIC S9(9) COMP SYNC
       specification is optimal.

   *   Relying on default specifications is undesirable.  You must
       specify COMP to get a binary integer.  Otherwise, it defaults to a
       decimal integer.  You must specify SYNC to guarantee word
       alignment.

   *   Decimal validation adds overhead.

   *   Signed numeric fields are preferable to unsigned numeric fields.

Optimize HP COBOL II/XL Data Types 

Optimizing HP COBOL II/XL data types requires recognition of the
following considerations:

   *   32-bit binary integers are desirable.  PIC S9(9) COMP SYNC
       specification is optimal.

   *   Relying on default specifications is undesirable.  You must
       specify COMP to get a binary integer.  Otherwise, it defaults to a
       decimal integer.  You must specify SYNC to guarantee word
       alignment.

   *   Decimal validation adds overhead.

   *   Signed numeric fields are preferable to unsigned numeric fields.

MPE/iX 5.0 Documentation