![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
To create VAX images from these examples, compile the source modules using a C compiler on a VAX system. To implement Example 10-2 as a shareable image, link the module, specifying the /SHAREABLE qualifier on the LINK command line and declaring the universal symbols in the shareable image by using the UNIVERSAL= option or by creating a transfer vector file. (See the Bookreader version of the OpenVMS Linker Utility Manual for information about how to create a shareable image.) The following example shows a LINK command that creates the shareable image MYMATH.EXE:
$ LINK/SHAREABLE MYMATH.OBJ,SYS$INPUT/OPT GSMATCH=LEQUAL,1,1000 UNIVERSAL=myadd UNIVERSAL=mysub UNIVERSAL=mydiv UNIVERSAL=mymul [Ctrl/Z]
You can then link the main program with the shareable image to create the executable image MYMAIN.EXE, as in the following example:
$ LINK MYMAIN.OBJ,SYS$INPUT/OPT MYMATH.EXE/SHAREABLE [Ctrl/Z]
Note that you may need to specify the /BPAGE qualifier on the LINK command line to force the linker to create image sections using a larger page size than the default page size on VAX systems (512 bytes). Otherwise, when VEST translates your VAX image, VEST may collect a number of these 512-byte image sections on a single Alpha page. When VEST puts neighboring image sections with conflicting protection attributes on the same Alpha page, it assigns the most permissive protection to all the image sections and issues a warning. (See the Bookreader version of the OpenVMS Linker Utility Manual for more information about using the /BPAGE qualifier.)
After creating the VAX images, translate them using VEST. Note that you must translate the shareable image first. (For more information about using the VEST command, see DECmigrate for OpenVMS AXP Systems Translating Images.) The following example creates the translated files named MYMATH_TV.EXE and MYMAIN_TV.EXE (VEST appends the characters "_TV" to the end of the image's file name):
$ VEST MYMATH.EXE $ VEST MYMAIN.EXE
To replace the translated main executable image MYMAIN_TV.EXE with a native version, compile the source module in Example 10-1 using a compiler that generates Alpha code, specifying the /TIE qualifier on the compile command line. Then link the native object module MYMAIN.OBJ to create a native Alpha image, specifying the translated shareable image in the linker options file as you would any other shareable image, as in the following example:
$ LINK/NONATIVE_ONLY MYMAIN.OBJ,SYS$INPUT/OPT MYMATH_TV.EXE/SHAREABLE [Ctrl/Z]
You can run the native main image as you would any other Alpha image. Define the name of the translated shareable image, MYMATH_TV, as a logical name that points to the location of the translated shareable image (unless it is located in the directory pointed to by the SYS$SHARE logical name) and execute the RUN command, as in the following example:
$ DEFINE MYMATH_TV YOUR$DISK:[YOUR_DIR]MYMATH_TV.EXE $ RUN MYMAIN
To create a native Alpha shareable image that can be called by a translated VAX image, perform the following steps:
Note
When creating a native Alpha shareable image to replace a translated VAX shareable image, always leave the first entry of a symbol vector empty by specifying the SPARE keyword as the first entry in the SYMBOL_VECTOR= option. VEST reserves the first symbol vector entry in the translated VAX image for its own use.
$ LINK/SHAREABLE MYMATH.OBJ,SYS$INPUT/OPT GSMATCH=LEQUAL,1,1000 SYMBOL_VECTOR=(SPARE,- myadd=procedure,- mysub=procedure,- mydiv=procedure,- mymul=procedure) [Ctrl/Z]
You can run the translated main image, MYMAIN_TV.EXE, with either the translated VAX shareable image, MYMATH_TV.EXE, or with the native Alpha shareable image, MYMATH.EXE. By default, the translated executable image calls the translated shareable image. (The translated executable image contains a global image section descriptor [GISD] that points to the translated shareable image. The image activator activates the shareable images to which the image has been linked.)
To run the translated main image with the native shareable image, define the name of the shareable image MYMATH_TV as a logical name that points to the location of the native Alpha shareable image, MYMATH.EXE, as in the following example:
$ DEFINE MYMATH_TV YOUR_DISK:[YOUR_DIR]MYMATH.EXE $ RUN MYMAIN_TV
To create a native Alpha shareable image that can replace a translated VAX shareable image in an application, you must ensure that the universal symbols in the shareable images appear at the same offsets in the symbol vectors in both images. When a VAX shareable image is translated, VEST creates a symbol vector for the image that includes the universal symbols declared in the original VAX shareable image. (A translated image is actually an Alpha image, created by VEST, and, like any other Alpha shareable image, it lists universal symbols in a symbol vector.) To create a native shareable image that is compatible with a translated shareable image, you must make sure that the same symbols appear at the same offsets in the symbol vector in the native Alpha shareable image and in the translated VAX shareable image it replaces.
To control how VEST lays out the symbol vector it creates in the translated VAX image, create a symbol information file (SIF) and include it in the translation operation. An SIF is a text file with which you can specify the layout of entries in the symbol vector VEST creates for the translated image and to determine which symbols should appear in the global symbol table (GST) of the translated shareable image. If you do not specify the layout of the symbol vector, VEST may change the layout in subsequent retranslations of the shareable image. Note that VEST reserves the first symbol vector entry for its own use. For more information about SIFs, see DECmigrate for OpenVMS AXP Systems Translating Images.
You control the layout of the symbol vector in a native shareable image by specifying the SYMBOL_VECTOR= option. The linker lays out the entries in a symbol vector in the order in which you specify the symbols in the SYMBOL_VECTOR= option statement. Make sure you list the symbols in the SYMBOL_VECTOR= option in the same order as they appear in the transfer vector used to create the VAX shareable image. For more information about using the SYMBOL_VECTOR= option, see the Bookreader version of the OpenVMS Linker Utility Manual.
To make sure the symbol vector in a translated shareable image matches the symbol vector in a native shareable image, perform the following steps:
! .SIF Generated by VEST (V1.0) on ! Image "MYMATH", "V1.0" MYDIV 00000018 +S +G 00000030 00 4e MYSUB 0000000c +S +G 00000020 00 4e MYADD 00000008 +S +G 00000010 00 4e MYMUL 00000010 +S +G 00000040 00 4e
. . . 4) Universal Symbol Specification (EGSD$C_SYMG) data type: DSC$K_DTYPE_Z (0) symbol flags: (0) EGSY$V_WEAK 0 (1) EGSY$V_DEF 1 (2) EGSY$V_UNI 1 (3) EGSY$V_REL 1 (4) EGSY$V_COMM 0 (5) EGSY$V_VECEP 0 (6) EGSY$V_NORM 1 psect: 0 value: 16 (%X'00000020') symbol vector entry (procedure) %X'00000000 00010000' %X'00000000 00000050' symbol: "MYSUB" . . .
In some cases, it is not possible to completely replace a VAX shareable image with an Alpha shareable image. For example, there may be functions in the VAX shareable image that are specific to the VAX architecture. In this situation, it may be necessary to build both a translated image and a native image that together provide the functionality of the original VAX shareable image. In other cases, there may be a need to define a relationship between a translated VAX shareable image and a new Alpha shareable image. In both situations, the translated VAX image must be a jacket image.
When building a jacket image, create a stub version of the new Alpha image on a VAX system. Then create a modified VAX shareable image that depends on it and translate it, specifying the /JACKET=shrimg qualifier, where shrimg is the name of the new Alpha shareable image. Note that a throwaway translation of the stub image must be performed in advance so that there is an IIF that describes it. For complete information about creating stub images, see DECmigrate for OpenVMS AXP Systems Translating Images.
This chapter provides information about the features that are specific to the native OpenVMS Alpha compilers. In addition, it lists the features of the OpenVMS VAX compilers that are not supported by or that have changed behavior in their OpenVMS Alpha counterparts.
The following compilers are covered in this appendix:
Compiler differences can exist for two reasons: differences between earlier and current versions of compilers running on OpenVMS VAX and differences between the DEC versions running on the VAX and Alpha computers. The OpenVMS Alpha compilers are intended to be compatible with their OpenVMS VAX counterparts. They include several qualifiers that contribute to compatibility, as described in the following sections.
The languages conform to language standards and include support for most OpenVMS VAX language extensions. The compilers produce output files with the same default file types as they do on OpenVMS VAX systems, such as .OBJ for an object module.
Note, however, that some features supported by the compilers on OpenVMS VAX systems may not be available on OpenVMS Alpha systems.
For more information about the compiler differences for each language,
refer to its documentation, especially the user's guides and the
release notes.
11.1 Compatibility of DEC Ada Between Alpha Systems and VAX Systems
DEC Ada includes nearly all the standard and extended Ada language features included in VAX Ada. These features are documented in the following manuals:
However, owing to differences in the platform hardware, some features are not supported or are implemented differently on VAX systems than on Alpha systems. To aid in porting programs from one system to another, the following sections highlight these differences.
Note
Not all of these features may be implemented on all systems for each release. See the DEC Ada release notes for more information.
In general, DEC Ada supports the same data types on all platforms. However, keep in mind the following differences:
Task priorities and scheduling and task control block size are
architecture specific. See the release notes for specifics.
11.1.3 Differences in Language Pragmas
Note the following differences in language pragmas:
Note the following changes to the system package:
In addition, the following types and subprograms supported on VAX systems are not supported on Alpha systems:
Note the following differences in these other packages:
The following two predefined instantiations supported on VAX systems are not supported on Alpha systems:
The DEC C compiler defines a core, ANSI-conforming C language that can
be used on all strategic Digital platforms, including the Alpha
architecture. For comprehensive information, see the DEC C
documentation.
11.2.1 Language Modes
DEC C for OpenVMS Alpha systems conform to the ANSI C standard, with optional support for VAX C and Common C (pcc) extensions. You invoke these optional extensions, called modes, using the /STANDARD qualifier. Table 11-1 describes these modes and the command-qualifier syntax needed to invoke them.
| Mode | Command Qualifier | Description |
|---|---|---|
| Default | /STANDARD=RELAXED_ANSI89 | Follows ANSI C standard but also allows additional Digital keywords and predefined macros that do not begin with an underscore. |
| ANSI C | /STANDARD=ANSI89 | Accepts only strictly conforming ANSI C language. |
| VAX C | /STANDARD=VAXC | Allows use of VAX C extensions to the ANSI C standard, even where the extensions may be incompatible with the ANSI C standard. |
| Common C (pcc) | /STANDARD=COMMON | Allows use of Common C extensions to the ANSI C standard, even where the extensions may be incompatible with the ANSI C standard. |
| Microsoft compatibility | /STANDARD=MS | Interprets source programs according to certain language rules followed by the C compiler provided with Microsoft Visual C++ compiler product. |
The DEC C for OpenVMS Alpha systems compiler supports most of the same data-type mappings as its VAX counterpart. Table 11-2 lists the sizes of the C arithmetic data types on the Alpha architecture.
| C Data Type | VAX C Mapping |
DEC C Mapping |
|---|---|---|
| pointer | 32 | 32 or 64¹ |
| long | 32 | 32 |
| int | 32 | 32 |
| short | 16 | 16 |
| char | 8 | 8 |
| float | 32 | 32² |
| double | 64² | 128² |
| long double | 64² | 64² |
| __int16 | NA | 16 |
| __int32 | NA | 32 |
| __int64 | NA | 64 |
To aid portability, the DEC C for OpenVMS Alpha compiler provides a
header file that defines typedefs for the signed and unsigned variants
of these data types. For example, if you have a data type that is a
64-bit integer, use the int64 typedef.
11.2.2.1 Specifying Floating-Point Mapping
The mapping between the C floating-point data types and the Alpha floating-point data types is controlled by command-line qualifiers. The Alpha architecture supports the following floating-point types:
By using a command line qualifier, you control which of the Alpha floating-point data types the standard C data types float and double map to. For example, if you specify the /FLOAT=G_FLOAT qualifier, DEC C maps the float data type to the Alpha F_floating data type and maps the double data type to the Alpha G_floating data type. Table 11-3 describes the complete list of floating-point options. Note that you can specify only one floating-point qualifier in a command line.
| Compiler Option | Float | Double | Long Double |
|---|---|---|---|
| /FLOAT=F_GLOAT | F_floating format | G_floating format | |
| /FLOAT=D_FLOAT | F_floating format | D-53 floating point | |
| /FLOAT=IEEE_FLOAT | S_floating format | T_floating format | |
| /L_DOUBLE_SIZE=128 (default) | --- | --- | X_floating format |
DEC C includes features, listed in Table 11-4, that are specific to Alpha systems. The following sections describe these features.
| Feature | Description |
|---|---|
| Access to some Alpha instructions | Available as built-ins |
| Access to some VAX instruction equivalents | Available through Alpha PALcode |
| Atomicity built-ins | Ensures the atomicity of AND, OR, and ADD operations |
DEC C supports certain Alpha instructions to provide functions that cannot be expressed in the C language, especially for system-level programming; for example:
The Alpha architecture implements certain VAX instructions as privileged architecture library (PALcode) instructions. DEC C allows access to the following PALcode instructions:
In the VAX architecture, certain combined operations, such as incrementing a variable, are guaranteed to be atomic (that is, they complete without interruption). To provide an equivalent function on Alpha systems, DEC C provides built-ins that perform the operations with the guarantee of atomicity. For example, several of these atomic built-ins are listed in Table 11-5. For a complete description of these built-ins, see the DEC C language documentation.
| Atomicity Built-In | Description |
|---|---|
|
__ADD_ATOMIC_LONG(ptr, expr, retry_count)
__ADD_ATOMIC_QUAD(ptr, expr, retry_count) |
Add the expression expr to the data segment pointed to by ptr. The optional retry_count parameter specifies the number of times the operation should be attempted (the default is forever). |
|
__AND_ATOMIC_LONG(ptr, expr, retry_count)
__AND_ATOMIC_QUAD(ptr, expr, retry_count) |
Fetch the data segment pointed to by ptr, perform a logical AND operation with the expression expr, and store the resulting value. The retry_count parameter specifies the number of times the operation should be attempted (the default is forever). |
|
__OR_ATOMIC_LONG(ptr, expr, retry_count)
__OR_ATOMIC_QUAD(ptr, expr, retry_count) |
Fetch the data segment pointed to by ptr, perform a logical OR operation with the expression expr, and store the resulting value. The retry_count parameter specifies the number of times the operation should be attempted (the default is forever). |
6459P011.HTM OSSG Documentation 22-NOV-1996 13:07:21.24
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.