Migrating an Application from OpenVMS VAX to OpenVMS Alpha

The compilers available on Alpha systems are intended to be compatible with their counterparts on VAX systems. The compilers conform to language standards and include support for most VAX language extensions. The compilers produce output files with the same default file types as they do on VAX systems, such as .OBJ for an object module.

Note, however, that some features supported by the compilers on VAX systems may not be available in the same compiler on Alpha systems. In addition, some compilers on Alpha systems support new features not supported by their counterparts on VAX systems. To provide compatibility, some compilers support compatibility modes. For example, the DEC C for OpenVMS Alpha systems compiler supports a VAX C compatibility mode that is invoked by specifying the /STANDARD=VAXC qualifier.

4.2 Relinking Your Application on an Alpha System

Once you successfully recompile your source files, you must relink your application to create a native Alpha image. The linker produces output files with the same file types as on current VAX systems. For example, by default, the linker uses the file type .EXE to identify image files.

Because the way in which you perform certain linking tasks is different on Alpha systems, you will probably need to modify the LINK command used to build your application. The following list describes some of these linker changes that may affect your application's build procedure. See the Bookreader version of the OpenVMS Linker Utility Manual for more information.

Declaring universal symbols in shareable images---If your application creates shareable images, your application build procedure probably includes a transfer vector file, written in VAX MACRO, in which you declare the universal symbols in the shareable image. On Alpha systems, instead of creating a transfer vector file, you must declare universal symbols in a linker options file by specifying the option SYMBOL_VECTOR=option.
Linking against the OpenVMS executive---On VAX systems, you link against the OpenVMS executive by including the system symbol table file (SYS.STB) in your build procedure. On Alpha systems, you link against the OpenVMS executive by specifying the /SYSEXE qualifier.
Optimizing the performance of images---On Alpha systems, the linker can perform certain optimizations that can improve the performance of the images it creates. The linker can also enhance performance by creating shareable images that can be installed as resident images.
Processing shareable images implicitly---On VAX systems, when you specify a shareable image in a link operation, the linker also processes all the shareable images to which that shareable image was linked. On Alpha systems, you must specify these shareable images to include them in your build procedure.

The linker supports several qualifiers and options, listed in Table 4-1, that are specific to Alpha systems. Table 4-2 lists linker qualifiers supported on VAX systems but not on Alpha systems.

Table 4-1 Linker Qualifiers and Options Specific to OpenVMS Alpha Systems
Qualifiers Description

/DEMAND_ZERO Controls how the linker creates demand-zero image sections.

/DSF Directs the linker to create a file called a debug symbol file (DSF) for use by the OpenVMS Alpha System-Code Debugger.

/GST Directs the linker to create a global symbol table (GST) for a shareable image (the default). More typically specified as /NOGST when used to create shareable images for run-time kits.

/INFORMATIONALS Directs the linker to output informational messages during a link operation (the default). More typically specified as /NOINFORMATIONALS to suppress these messages.

/NATIVE_ONLY Directs the linker to not pass along the procedure signature block (PSB) information, created by the compilers, in the image it is creating (the default).
If you specify /NONATIVE_ONLY during linking, the image activator uses the PSB information, if any, provided in the object modules specified as input files to the link operation to invoke jacket routines. Jacket routines are necessary to allow native Alpha images to work with translated VAX images.

/REPLACE Directs the linker to perform certain optimizations that can improve the performance of the image it is creating, when requested to do so by the compilers (the default).

/SECTION_BINDING Directs the linker to create a shareable image that can be installed as a resident image.

/SYSEXE Directs the linker to process the OpenVMS executive image (SYS$BASE_IMAGE.EXE) to resolve symbols left unresolved in a link operation.

Options Description

SYMBOL_TABLE= option Directs the linker to include global symbols as well as universal symbols in the symbol table file associated with a shareable image. By default, the linker includes only universal symbols.

SYMBOL_VECTOR= option Used to declare universal symbols in Alpha shareable images.

**Table 4-1 Linker Qualifiers and Options Specific to OpenVMS Alpha Systems**
Qualifiers	Description
/DEMAND_ZERO	Controls how the linker creates demand-zero image sections.
/DSF	Directs the linker to create a file called a debug symbol file (DSF) for use by the OpenVMS Alpha System-Code Debugger.
/GST	Directs the linker to create a global symbol table (GST) for a shareable image (the default). More typically specified as /NOGST when used to create shareable images for run-time kits.
/INFORMATIONALS	Directs the linker to output informational messages during a link operation (the default). More typically specified as /NOINFORMATIONALS to suppress these messages.
/NATIVE_ONLY	Directs the linker to not pass along the procedure signature block (PSB) information, created by the compilers, in the image it is creating (the default). If you specify /NONATIVE_ONLY during linking, the image activator uses the PSB information, if any, provided in the object modules specified as input files to the link operation to invoke jacket routines. Jacket routines are necessary to allow native Alpha images to work with translated VAX images.
/REPLACE	Directs the linker to perform certain optimizations that can improve the performance of the image it is creating, when requested to do so by the compilers (the default).
/SECTION_BINDING	Directs the linker to create a shareable image that can be installed as a resident image.
/SYSEXE	Directs the linker to process the OpenVMS executive image (SYS$BASE_IMAGE.EXE) to resolve symbols left unresolved in a link operation.
Options	Description
SYMBOL_TABLE= option	Directs the linker to include global symbols as well as universal symbols in the symbol table file associated with a shareable image. By default, the linker includes only universal symbols.
SYMBOL_VECTOR= option	Used to declare universal symbols in Alpha shareable images.

Table 4-2 Linker Options Specific to OpenVMS VAX Systems
Options Description

BASE= option Specifies the base address (starting address) that you want the linker to assign to the image.

DZRO_MIN= option Specifies the minimum number of contiguous, uninitialized pages that the linker must find in an image section before it can extract the pages from the image section and place them in a newly created demand-zero image section. By creating demand-zero image sections (image sections that do not contain initialized data), the linker can reduce the size of images.

ISD_MAX= option Specifies the maximum number of image sections allowed in the image.

UNIVERSAL= option Declares a symbol in a shareable image as universal, causing the linker to include it in the global symbol table of a shareable image.

**Table 4-2 Linker Options Specific to OpenVMS VAX Systems**
Options	Description
BASE= option	Specifies the base address (starting address) that you want the linker to assign to the image.
DZRO_MIN= option	Specifies the minimum number of contiguous, uninitialized pages that the linker must find in an image section before it can extract the pages from the image section and place them in a newly created demand-zero image section. By creating demand-zero image sections (image sections that do not contain initialized data), the linker can reduce the size of images.
ISD_MAX= option	Specifies the maximum number of image sections allowed in the image.
UNIVERSAL= option	Declares a symbol in a shareable image as universal, causing the linker to include it in the global symbol table of a shareable image.

4.3 Compatibility Between the Mathematics Libraries Available on VAX and Alpha Systems

Mathematical applications using the standard OpenVMS call interface to the OpenVMS Mathematics (MTH$) Run-Time Library need not change their calls to MTH$ routines when migrating to an OpenVMS Alpha system. Jacket routines are provided that map MTH$ routines to their math$ counterparts in the Digital Portable Mathematics Library (DPML) for OpenVMS Alpha systems. However, there is no support in the DPML for calls made to JSB entry points and vector routines. Note that DPML routines are different from those in the OpenVMS MTH$ RTL and you should expect to see small differences in the precision of the mathematical results.

To maintain compatibility with future libraries and to create portable mathematical applications, Digital recommends that you use the DPML routines available through the high-level language of your choice (for example, DEC C or DEC Fortran) rather than using the call interface. Significantly higher performance and accuracy are also available to you with DPML routines.

See the Digital Portable Mathematics Library manual for more information about the DPML routines.

4.4 Determining the Host Architecture

Your application may need to determine whether it is running on an OpenVMS VAX system or an Alpha system. From within your program, you can obtain this information by calling the $GETSYI system service (or the LIB$GETSYI RTL routine), specifying the ARCH_TYPE item code. When your application is running on a VAX system, the $GETSYI system service returns the value 1. When your application is running on an Alpha system, the $GETSYI system service returns the value 2.

Example 4-1 shows how to determine the host architecture in a DCL command procedure by calling the F$GETSYI DCL command and specifying the ARCH_TYPE item code. (For an example of calling the $GETSYI system service to obtain the page size of an Alpha system, see Section 5.4.)

Example 4-1 Using the ARCH_TYPE Keyword to Determine Architecture Type

$! Determine architecture type 
$ type_symbol = f$getsyi("arch_type") 
$ if type_symbol .eq. 1 then goto ON_VAX 
$ if type_symbol .eq. 2 then goto ON_ALPHA 
$ ON_VAX: 
$ ! 
$ ! Do VAX-specific processing 
$ ! 
$ exit 
$ ON_ALPHA: 
$ ! 
$ ! Do Alpha-specific processing 
$ ! 
$ exit

Note, however, that the ARCH_TYPE item code is available only on VAX systems running OpenVMS Version 5.5 or later. If your application needs to determine the host architecture for earlier versions of the operating system, use one of the other $GETSYI system service item codes listed in Table 4-3.

Table 4-3 $GETSYI Item Codes That Specify Host Architecture
Keyword Usage

ARCH_TYPE Returns 1 on a VAX system; returns 2 on an Alpha system. Supported on Alpha systems and on VAX systems running OpenVMS Version 5.5 or later.

ARCH_NAME Returns text string "VAX" on VAX systems and text string "Alpha" on Alpha systems. Supported on Alpha systems and on VAX systems running OpenVMS Version 5.5 or later.

HW_MODEL Returns an integer that identifies a particular hardware model. All values equal to or larger than 1024 identify Alpha systems.

CPU Returns an integer that identifies a particular CPU. The value 128 identifies a system as "not a VAX." This code is supported on much earlier versions of OpenVMS than the ARCH_TYPE and ARCH_NAME codes.

**Table 4-3 $GETSYI Item Codes That Specify Host Architecture**
Keyword	Usage
ARCH_TYPE	Returns 1 on a VAX system; returns 2 on an Alpha system. Supported on Alpha systems and on VAX systems running OpenVMS Version 5.5 or later.
ARCH_NAME	Returns text string "VAX" on VAX systems and text string "Alpha" on Alpha systems. Supported on Alpha systems and on VAX systems running OpenVMS Version 5.5 or later.
HW_MODEL	Returns an integer that identifies a particular hardware model. All values equal to or larger than 1024 identify Alpha systems.
CPU	Returns an integer that identifies a particular CPU. The value 128 identifies a system as "not a VAX." This code is supported on much earlier versions of OpenVMS than the ARCH_TYPE and ARCH_NAME codes.

Chapter 5
Adapting Applications to a Larger Page Size

This chapter describes how to identify dependencies your application may have on the VAX page size and makes recommendations for correcting those dependencies.

5.1 Overview

In general, page size, the basic unit of memory manipulated by the operating system, is below the level of applications, especially for applications written in high- or mid-level programming languages. However, your application may contain page-size dependencies if it calls system services or run-time library routines to perform memory management functions such as the following:

Allocating virtual memory
Mapping sections into the virtual address space of your process
Locking memory into your working set
Protecting segments of your virtual address space

The system services and run-time library routines that perform these functions manipulate memory in pages. The values you specified as arguments to these routines are based on an assumption of a 512-byte page, the page size defined by the VAX architecture. The Alpha architecture supports an 8KB, 16KB, 32KB, or 64KB page size, depending on the implementation, so you should examine the values you specify as arguments to the routines to make sure they still satisfy the requirements of your application. The following sections provide more information about examining the routines.

Note that this difference in page sizes does not affect memory allocation using higher level routines, for example, the run-time library routines that manipulate virtual memory zones or language-specific memory allocation routines such as the malloc and free routines in C.

5.1.1 Compatibility Features

Wherever possible, system services or run-time library routines attempt to present the same interface and return values on Alpha systems as they do on VAX systems. For example, on Alpha systems, the routines that accept page-count values as arguments still interpret these arguments in 512-byte quantities, now called pagelets to distinguish them from the CPU-specific page size. The routines convert pagelet values into CPU-specific pages. The routines that return page-count values convert from CPU-specific pages to pagelets so that the return values expected by your application are still measured in 512-byte units.

Note
On Alpha systems, when creating page frame sections using the $CRMPSC system service (with the SEC$M_PFNMAP flag bit set), the value specified in the page count argument (pagcnt) is interpreted as the CPU-specific page size, not as a pagelet value.

5.1.2 Summary of Memory Management Routines with Potential Page-Size Dependencies

Despite the compatibility, some routines behave differently on Alpha systems than they do on VAX systems and may require you to modify your source code. For example, on Alpha systems, the system services that map section files ($CRMPSC and $MGBLSC) require you to specify address value arguments that are aligned on CPU-specific page boundaries. On VAX systems, these routines round the address values specified in arguments to VAX page boundaries. On Alpha systems, the routines do not round these addresses to CPU-specific page boundaries.

Table 5-1 lists the memory management routines with the arguments they support that may contain page-size dependencies. The table lists the arguments with their intended function and describes how these arguments are interpreted on Alpha systems. Note that the table does not attempt to list all the arguments accepted by each routine. For more information about the routines and their argument lists, see the OpenVMS System Services Reference Manual.

Table 5-1 Potential Page-Size Dependencies in Memory Management Routines
Routine Argument Behavior on Alpha Systems

Adjust Working Set Limit ($ADJWSL) pagcnt specifies the number of pages to add to (or subtract from) the current working set limit. Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.

wsetlm specifies the value of the current working set limit. Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.

Create Process
($CREPRC) quota accepts several quota descriptors that specify page counts, such as the default working set size, paging file quota, and working set expansion quota. Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.

Create Virtual Address ($CRETVA) inadr specifies the start- and end-addresses of the memory to be allocated. If the end-address is the same as the start-address, a single page is allocated. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory affected by the call. Unchanged.

Create and Map Section ($CRMPSC) inadr specifies the start- and end-addresses that define the region to be remapped. If the end-address is the same as the start-address, a single page is mapped, unless the SEC$M_EXPREG flag is set, in which case the start-address is interpreted as determining whether the allocation should be in P0 or P1 space. Addresses must be aligned on CPU-specific pages (unless the SEC$M_EXPREG flag is set); no rounding is done. (See Section 5.3 for more information about mapping.)

retadr specifies the actual start- and end-addresses of the memory affected by the call. Returns the start- and end-addresses of the usable range of addresses, which may be different than the total amount mapped. This argument is required when the relpag argument is specified.

flags specifies the type and characteristics of the section to be created or mapped. The flag bit SEC$M_NO_OVERMAP indicates that existing address space should not be overmapped. When the flag bit SEC$M_PFNMAP is set, the pagcnt argument is interpreted as CPU-specific pages, not pagelets.

relpag specifies the page offset at which mapping of the section file should begin. Interpreted as an index into the section file, measured in pagelets.

pagcnt specifies the number of pages (blocks) in the file to be mapped. Interpreted in pagelets; no rounding is done. When the flag bit SEC$M_PFNMAP is set, the pagcnt argument is interpreted as CPU-specific pages, not pagelets.

pfc specifies the number of pages that should be mapped when a page fault occurs. Interpreted in CPU-specific-sized pages. When specifying a value for this argument, remember that, because Alpha systems support 8K, 16K, 32K, and 64K byte physical page sizes, at least 16 pagelets will be mapped for each physical page. The system cannot map less than a physical page.

Delete Virtual Address ($DELTVA) inadr specifies the start- and end-addresses of the memory to be deallocated. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was deleted. Unchanged.

Expand Program/Control Region ($EXPREG) pagcnt specifies the amount of memory to allocate, in 512-byte units. Interpreted in pagelets.

retadr specifies the actual start- and end-addresses of the memory affected by the call. Unchanged.

Get Job/Process Information ($GETJPI) itmlst specifies which information about the process is to be returned. Many items, such as JPI$_WSEXTENT, interpreted as pagelet values. See the OpenVMS System Services Reference Manual for more information.

Get Queue Information ($GETQUI) itmlst specifies information to be used in performing the function specified by the func argument. Several items interpreted as pagelet values. See the OpenVMS System Services Reference Manual for more information.

Get Systemwide Information ($GETSYI) itmlst specifies which information is to be returned about the node or nodes. Several items interpreted as pagelet values. One additional item, SYI$_PAGE_SIZE, specifies the page size supported by the node. See the OpenVMS System Services Reference Manual for more information.

Get User Authorization Information ($GETUAI) itmlst specifies which information from the user's user authorization file is to be returned. Several items return pagelet values. See the OpenVMS System Services Reference Manual for more information.

Lock Page
($LCKPAG) inadr specifies the start- and end-addresses of the memory to be locked. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was locked. Unchanged.

Lock Working Set
($LKWSET) inadr specifies the start- and end-addresses of the memory to be locked. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was locked. Unchanged.

Map Global Section
($MGBLSC) inadr specifies the start- and end-addresses that define the region to be remapped. If the end-address is the same as the start-address, a single page is mapped, unless the SEC$M_EXPREG flag is set, in which case the start-address is interpreted as determining whether the allocation should be in P0 or P1 space. Addresses must be aligned on a CPU-specific page (unless the SEC$M_EXPREG flag is set); no rounding is done. (See Section 5.3 for more information about mapping.)

retadr specifies the actual start- and end-addresses of the memory affected by the call. Returns start- and end-addresses of usable portion of memory mapped.

relpag specifies the page offset at which mapping of the section file should begin. Interpreted as an index into the section file, measured in pagelets.

Purge Working Set
($PURGWS) inadr specifies the start- and end-addresses of the memory to be purged. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

Set Protection
($SETPRT) inadr specifies the start- and end-addresses of the memory to be protected. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was protected. Unchanged.

Set User Authorization File ($SETUAI) itmlst specifies which information from the user authorization file is to be set. Several items interpreted in pagelet values. See the OpenVMS System Services Reference Manual for more information.

Send to Job Controller ($SNDJBC) itmlst specifies information to be used in performing the function specified by the func argument. Several items interpreted in pagelet values. See the OpenVMS System Services Reference Manual for more information.

Unlock Page
($ULKPAG) inadr specifies the start- and end-addresses of the memory to be unlocked. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was unlocked. Unchanged.

Unlock Working Set
($ULWSET) inadr specifies the start- and end-addresses of the memory to be unlocked. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

retadr specifies the actual start- and end-addresses of the memory that was unlocked. Unchanged.

Update Section
($UPDSEC) inadr specifies the start- and end-address of the section to write to disk. Rounds requests to CPU-specific pages. Note that only the address range actually represented by on-disk storage will be written to disk.

retadr specifies the actual start- and end-addresses of the memory that was written to disk. Addresses are adjusted up or down to fall on CPU-specific page boundaries.

**Table 5-1 Potential Page-Size Dependencies in Memory Management Routines**
Routine	Argument	Behavior on Alpha Systems
Adjust Working Set Limit ($ADJWSL)	pagcnt specifies the number of pages to add to (or subtract from) the current working set limit.	Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.
	wsetlm specifies the value of the current working set limit.	Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.
Create Process ($CREPRC)	quota accepts several quota descriptors that specify page counts, such as the default working set size, paging file quota, and working set expansion quota.	Interpreted in pagelets, adjusted up or down to represent CPU-specific-sized pages.
Create Virtual Address ($CRETVA)	inadr specifies the start- and end-addresses of the memory to be allocated. If the end-address is the same as the start-address, a single page is allocated.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory affected by the call.	Unchanged.
Create and Map Section ($CRMPSC)	inadr specifies the start- and end-addresses that define the region to be remapped. If the end-address is the same as the start-address, a single page is mapped, unless the SEC$M_EXPREG flag is set, in which case the start-address is interpreted as determining whether the allocation should be in P0 or P1 space.	Addresses must be aligned on CPU-specific pages (unless the SEC$M_EXPREG flag is set); no rounding is done. (See Section 5.3 for more information about mapping.)
	retadr specifies the actual start- and end-addresses of the memory affected by the call.	Returns the start- and end-addresses of the usable range of addresses, which may be different than the total amount mapped. This argument is required when the relpag argument is specified.
	flags specifies the type and characteristics of the section to be created or mapped.	The flag bit SEC$M_NO_OVERMAP indicates that existing address space should not be overmapped. When the flag bit SEC$M_PFNMAP is set, the pagcnt argument is interpreted as CPU-specific pages, not pagelets.
	relpag specifies the page offset at which mapping of the section file should begin.	Interpreted as an index into the section file, measured in pagelets.
	pagcnt specifies the number of pages (blocks) in the file to be mapped.	Interpreted in pagelets; no rounding is done. When the flag bit SEC$M_PFNMAP is set, the pagcnt argument is interpreted as CPU-specific pages, not pagelets.
	pfc specifies the number of pages that should be mapped when a page fault occurs.	Interpreted in CPU-specific-sized pages. When specifying a value for this argument, remember that, because Alpha systems support 8K, 16K, 32K, and 64K byte physical page sizes, at least 16 pagelets will be mapped for each physical page. The system cannot map less than a physical page.
Delete Virtual Address ($DELTVA)	inadr specifies the start- and end-addresses of the memory to be deallocated.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was deleted.	Unchanged.
Expand Program/Control Region ($EXPREG)	pagcnt specifies the amount of memory to allocate, in 512-byte units.	Interpreted in pagelets.
	retadr specifies the actual start- and end-addresses of the memory affected by the call.	Unchanged.
Get Job/Process Information ($GETJPI)	itmlst specifies which information about the process is to be returned.	Many items, such as JPI$_WSEXTENT, interpreted as pagelet values. See the OpenVMS System Services Reference Manual for more information.
Get Queue Information ($GETQUI)	itmlst specifies information to be used in performing the function specified by the func argument.	Several items interpreted as pagelet values. See the OpenVMS System Services Reference Manual for more information.
Get Systemwide Information ($GETSYI)	itmlst specifies which information is to be returned about the node or nodes.	Several items interpreted as pagelet values. One additional item, SYI$_PAGE_SIZE, specifies the page size supported by the node. See the OpenVMS System Services Reference Manual for more information.
Get User Authorization Information ($GETUAI)	itmlst specifies which information from the user's user authorization file is to be returned.	Several items return pagelet values. See the OpenVMS System Services Reference Manual for more information.
Lock Page ($LCKPAG)	inadr specifies the start- and end-addresses of the memory to be locked.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was locked.	Unchanged.
Lock Working Set ($LKWSET)	inadr specifies the start- and end-addresses of the memory to be locked.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was locked.	Unchanged.
Map Global Section ($MGBLSC)	inadr specifies the start- and end-addresses that define the region to be remapped. If the end-address is the same as the start-address, a single page is mapped, unless the SEC$M_EXPREG flag is set, in which case the start-address is interpreted as determining whether the allocation should be in P0 or P1 space.	Addresses must be aligned on a CPU-specific page (unless the SEC$M_EXPREG flag is set); no rounding is done. (See Section 5.3 for more information about mapping.)
	retadr specifies the actual start- and end-addresses of the memory affected by the call.	Returns start- and end-addresses of usable portion of memory mapped.
	relpag specifies the page offset at which mapping of the section file should begin.	Interpreted as an index into the section file, measured in pagelets.
Purge Working Set ($PURGWS)	inadr specifies the start- and end-addresses of the memory to be purged.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
Set Protection ($SETPRT)	inadr specifies the start- and end-addresses of the memory to be protected.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was protected.	Unchanged.
Set User Authorization File ($SETUAI)	itmlst specifies which information from the user authorization file is to be set.	Several items interpreted in pagelet values. See the OpenVMS System Services Reference Manual for more information.
Send to Job Controller ($SNDJBC)	itmlst specifies information to be used in performing the function specified by the func argument.	Several items interpreted in pagelet values. See the OpenVMS System Services Reference Manual for more information.
Unlock Page ($ULKPAG)	inadr specifies the start- and end-addresses of the memory to be unlocked.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was unlocked.	Unchanged.
Unlock Working Set ($ULWSET)	inadr specifies the start- and end-addresses of the memory to be unlocked.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.
	retadr specifies the actual start- and end-addresses of the memory that was unlocked.	Unchanged.
Update Section ($UPDSEC)	inadr specifies the start- and end-address of the section to write to disk.	Rounds requests to CPU-specific pages. Note that only the address range actually represented by on-disk storage will be written to disk.
	retadr specifies the actual start- and end-addresses of the memory that was written to disk.	Addresses are adjusted up or down to fall on CPU-specific page boundaries.

The run-time library routines listed in Table 5-2 allocate (or free) pages of memory. For compatibility, these routines also interpret the page-count information you specify in pagelets.

Table 5-2 Potential Page-Size Dependencies in Run-Time Library Routines
Routine Argument Behavior on Alpha Systems

LIB$GET_VM_PAGE number-of-pages argument specifies the number of contiguous pages to allocate. Interpreted in pagelets, rounded to CPU-specific pages.

LIB$FREE_VM_PAGE number-of-pages argument specifies the number of contiguous pages to free. Interpreted in pagelets, rounded to CPU-specific pages.

**Table 5-2 Potential Page-Size Dependencies in Run-Time Library Routines**
Routine	Argument	Behavior on Alpha Systems
LIB$GET_VM_PAGE	number-of-pages argument specifies the number of contiguous pages to allocate.	Interpreted in pagelets, rounded to CPU-specific pages.
LIB$FREE_VM_PAGE	number-of-pages argument specifies the number of contiguous pages to free.	Interpreted in pagelets, rounded to CPU-specific pages.

5.2 Examining Memory Allocation Routines

To determine if the memory allocation performed by your application requires modification, check to see where the memory is allocated. The system service routines that perform memory allocation ($EXPREG and $CRETVA) allow you to allocate memory in two ways:

By expanding the size of the P0 or P1 regions of your application's virtual address space
By reclaiming a region of your application's existing virtual address space, starting at a location you specify

The Alpha architecture defines the same virtual address space layout as the VAX architecture and allows for growth of the P0 and P1 regions in the same direction as on VAX systems. Figure 5-1 shows this layout.

Figure 5-1 Virtual Address Layout

5.2.1 Allocating Memory in Expanded Virtual Address Space

If your application allocates memory by expanding virtual address space using the $EXPREG system service, you may not need to make any source code changes because the values you specified as arguments are valid on Alpha systems and VAX systems. The reasons for this are as follows:

On Alpha systems, the $EXPREG system service interprets the amount of memory requested (specified as a page count in the pagcnt argument) in 512-byte units, the same as on an VAX system. Thus, the value your application specified still requests the same amount of memory. Note, however, that because the system service rounds the value up to CPU-specific pages, the actual amount of memory allocated by the system for your application may be larger on an Alpha system than it is on a VAX system. The entire amount of memory allocated is available for use by your application. Because applications typically allocate memory to satisfy buffer requirements, which do not change with different platforms, the value you specified should still satisfy the requirements of your application.
Because the allocation occurs in an expanded area of virtual address space, the discrepancy between the amount requested and the amount actually allocated by the system should have no effect on the function of your application.

Recommendation

  6459P005.HTM
  OSSG Documentation
  22-NOV-1996 13:07:11.53

Legal