User`s guide

Recommended and Required Source Changes
3.8 Arithmetic Exceptions
Recommended Change
If the condition handling routine in your application only counts the number
of arithmetic exceptions that occurred, or aborts when an arithmetic exception
occurs, it does not matter that the exception is delivered asynchronously on
Alpha. These condition handling routines require only the addition of a test for
the SS$_HPARITH condition code. The VAX arithmetic exceptions will never
be returned on OpenVMS Alpha (except from translated VAX images). If your
application attempts to restart the operation that caused the exception, you must
either rewrite your code or use a compiler qualifier or directive that ensures the
exact reporting of arithmetic exceptions. Note, however, that the compiler must
drain the instruction pipeline after using each arithmetic instruction to provide
this function, which severely affects performance.
The EVAX_TRAPB built-in can be used to force any preceding traps to be
signaled. Because of the performance impact of this built-in, it should be used
only after arithmetic instructions you need to isolate.
3.9 Page Size
A set of macros has been developed which can be used to standardize the way
page size dependencies are coded and to make future changes easier. These are
discussed in Appendix D.
3.10 Locking Pages into a Working Set
Pages are commonly locked down in the following ways:
• At image initialization, locking a section of code for the life of the image. This
method uses the $LKWSET system service call to lock the pages in memory.
The $LKWSET call is often in a different module from the code to be locked.
• On-the-fly, locking down a small section of code for a specific operation. This
method often uses the poor programmer’s lockdown method of raising IPL
and specifying the IPL as a data location at the end of the code to be locked.
On an OpenVMS Alpha system, not only must the code pages be locked in
memory, but the code’s linkage section must also be locked. Because of this and
other constraints, the LOCK_SYSTEM_PAGES, UNLOCK_SYSTEM_PAGES,
PMLREQ, and PMLEND macros do not exist on OpenVMS Alpha systems.
On OpenVMS I64 systems, $LKWSET has been modified to avoid the problems
encountered on OpenVMS Alpha systems by locking the entire image referenced
by the parameters. This insures correct behavior, but might result in a
performance penalty. See the HP OpenVMS Version 8.2 Release Notes for
more information.
Recommended Change
To minimize code changes, both cases are accommodated by means of several new
macros.
For lockdown done at image initialization time, three macros are provided: two
as ‘‘begin’’ and ‘‘end’’ markers to delimit code to be locked, and an additional
initialization macro to create the descriptors and issue the $LKWSET calls.
To lock and unlock code where poor programmer’s lockdown or other on-the-fly
lockdown was done, two other macros are provided. For architectural reasons
discussed in this section, these macros also use the $LKWSET and the $ULWSET
system service calls to lock and unlock pages.
3–18 Recommended and Required Source Changes