Completing these steps yields the information necessary to write an effective migration plan.

Data Terminology–Table 2.1 describes the major changes to the OpenVMS Calling Standard to for I64.

The Alpha architecture supports both IEEE and VAX floating-point formats in hardware. OpenVMS compilers generate code using the VAX formats by default, with options on Alpha to use IEEE formats. The Itanium architecture implements floating-point arithmetic in hardware using the IEEE floating-point formats, including IEEE single and IEEE double.

If an application was originally written for OpenVMS VAX or OpenVMS Alpha using the default floating-point formats, it can be ported to I64 in one of two ways: continue to use VAX floating-point formats utilizing the conversion features of the VSI compilers or convert the application to use IEEE floating-point formats. VAX floating-point formats can be used in those situations where access to previously generated binary floating-point data is required. VSI compilers generate the code necessary to convert the data between VAX and IEEE formats.

For details about the conversion process, see the OpenVMS Floating-Point Arithmetic on the Intel® Itanium ® Architecture white paper.

IEEE floating-point format should be used in those situations where VAX floating-point formats are not required. The use of IEEE floating-point formats will result in more efficient code.

VAX floating-point formats are supported on the Itanium architecture by converting them to IEEE single and IEEE double floating types. By default, this is a transparent process that will not impact most applications. VSI is providing compilers for C, C++, Fortran, BASIC, Pascal, and COBOL, all with the same floating-point options. Application developers need only recompile their applications using the appropriate compiler. For detailed descriptions of floating-point options, refer to the individual compilers' documentation.

Because IEEE floating-point format is the default, unless an application explicitly specifies VAX floating-point format options, a simple rebuild for I64 uses native IEEE formats directly. For programs that do not depend directly on the VAX formats for correct operation, this is the most desirable way to build for I64.

For more information, refer to the HP OpenVMS Version 8.2 Release Notes.

Native Alpha Development

The standard development tools you have on Alpha are also available as native tools on OpenVMS I64 systems.

Translation

The software translator VSI OpenVMS Migration Software for Alpha to Integrity Servers runs on both Alpha and OpenVMS I64 systems. The Translated Image Environment (TIE), which is required to run a translated image, is part of OpenVMS I64, so final testing of a translated image must either be done on an OpenVMS I64 system or at an OpenVMS I64 Migration Center. In general, the process of translating an Alpha image to run on an OpenVMS I64 system is straightforward, although you may have to modify your code somewhat to get it to translate without error.

Application components can be migrated from OpenVMS VAX and OpenVMS Alpha to I64 by binary translation. Because executable and shareable images can be translated on an individual basis, it is possible (even likely) to construct an environment in which native and translated images are mixed in a single image activation.

Translated images use the calling standard of their original implementation; that is, the argument lists of VAX translated images have the same binary format as they did on the VAX platform. Because the I64 calling standard differs from the OpenVMS VAX and OpenVMS Alpha calling standards, direct calls between native and translated images are not possible. Instead, such calls must be handled by interface routines (called jacket routines) that transform the arguments from one calling standard to the other.

The jacket routines are provided by TIE. In addition to argument transformation, TIE also handles the delivery of exceptions to translated code. TIE is loaded as an additional shareable image whenever a translated image (either main program or shareable image) is activated. The image activator interposes calls to jacket routines as necessary when it resolves references between native and translated images.

These requirements are met by compiling code using the /TIE qualifier and linking it using the /NONATIVE_ONLY qualifier. /TIE is supported by most I64 compilers including the Macro-32 compiler. (It is not supported on C++.) Both qualifiers must be given explicitly in the compile and LINK commands, since the defaults are /NOTIE and /NATIVE_ONLY, respectively. Signatures are not supported by the OpenVMS I64 assembler; therefore, routines coded in OpenVMS I64 assembly language cannot be directly called from translated images. OpenVMS I64 assembly language can call translated code only with an explicit call to OTS$CALL_PROC.

Translated image support carries a minor performance penalty: all calls to function variables are made via OTS$CALL_PROC, at a cost of about 10 instructions for most cases. Performance-critical code should only be built /TIE and /NONATIVE_ONLY if interoperation with translated images is required.

An additional consideration applies to executable and shareable images that are linked /NOSYSSHR. Ordinarily, references to OTS$CALL_PROC are resolved by the shareable image LIBOTS.EXE and require no special attention. Linking an image /NOSYSSHR skips the search of the shareable image library and instead resolves external references from object modules in STARLET.OLB. OTS$CALL_PROC makes a reference to a data cell defined in the system symbol table, and if simply included from STARLET.OLB would result in an unresolved reference to CTL$GQ_TIE_SYMVECT.

Most images linked /NOSYSSHR are so built to avoid interaction with any external images, so calls to translated code are not an issue. For this reason, STARLET.OLB contains a subset version of OTS$CALL_PROC that does not support calls to translated images. This module, named OTS$CALL_PROC_NATIVE, is loaded by default, and images linked /NOSYSSHR by default cannot call out to translated code.

The System-Code Debugger is a symbolic debugger that allows you to debug nonpageable code and device drivers running at any IPL.

OpenVMS provides two tools for analyzing system crashes: the System Dump Analyzer and the Crash Log Utility Extractor.

Because the changes in your application are combined with use of a new architecture, testing your application after it is migrated to I64 is particularly important. Not only can the changes introduce errors into the application, but the new environment can bring out latent problems in the Alpha version.

Testing your migrated application involves the following steps:

Both regression tests and stress tests are useful here. Stress tests are important to test for platform differences in synchronization, particularly for applications that use multiple threads of execution.

Although your standard tests should go a long way toward verifying the function of the migrated application, you should add some tests that look at issues specific to the migration. Points to focus on include the following:

Despite your best efforts, you may encounter bugs that were in your program all along but that never caused a problem on an OpenVMS Alpha system.

For example, failure to initialize some variable in your program might have been benign on an Alpha system but could produce an arithmetic exception on an OpenVMS I64 system. The same could be true of moving between any other two architectures, because the available instructions and the way compilers optimize them is bound to change. There is no magic answer for bugs that have been in hiding, but you should test your programs after porting them and before making them available to other users.

This section describes how to conditionalize OpenVMS code when migrating to OpenVMS I64. This code will be compiled for both Alpha and OpenVMS I64, or for VAX, Alpha, and OpenVMS I64. The symbol ALPHA, referred to in the following sections, is new. However, the symbol EVAX has not been eliminated. You do not need to replace EVAX with ALPHA but feel free to do so if convenient. The architecture symbols available for MACRO and BLISS are VAX, EVAX, ALPHA, and OpenVMS I64.

.IF DF ALPHA
       .
       .
       .
.ENDC 

.IF DF OpenVMS I64
       .
       .
       .
.ENDC 

REQUIRE 'SYS$LIBRARY:ARCH_DEFS';

%if ALPHA %then
        .
        .
        .
%fi

%if OpenVMS I64 %then
        .
        .
        .
%fi

#ifdef __alpha
        .
        .
        .
#endif

#ifdef __ia64
        .
        .
        .
#endif

%IF VAX %THEN
  vvv
  vvv
%FI

%IF EVAX %THEN
  aaa
  aaa
%FI

%IF OpenVMS I64 %THEN
  iii
  iii
%FI 

%IF VAX %THEN
  vvv
  vvv
%ELSE
  aaa
  aaa
%FI 

Certain system services that work well in applications on OpenVMS Alpha do not port successfully to OpenVMS I64. The following sections describe system services and their replacement services.

This section describes coding practices on Alpha that produce different results on OpenVMS I64 and may require changes to your application.

http://www.caldera.com/developers/gabi

http://www.eagercon.com/dwarf/dwarf3std.htm 

OpenVMS Alpha supports VAX floating-point data types and IEEE floating point data types in hardware. I64 supports IEEE floating-point in hardware and VAX floating-point data types in software.

Most of the I64 compilers provide the /FLOAT=D_FLOAT and /FLOAT=G_FLOAT qualifiers to enable you to produce VAX floating-point data types. If you do not specify one of these qualifiers, IEEE floating-point data types will be used.

to specify a default floating-point data types using the OpenVMS I64 BASIC compiler, you use the /REAL_SIZE qualifier. The possible values that can be specified are SINGLE (Ffloat), DOUBLE (Dfloat), GFLOAT, SFLOAT, TFLOAT, and XFLOAT.

You can test an application's behavior with IEEE floating-point values on Alpha by compiling it with an IEEE qualifier on OpenVMS Alpha. If that produces acceptable results, you can build the application on an OpenVMS I64 system using the same qualifier.

When you compile an OpenVMS application that specifies an option to use VAX floating-point on OpenVMS I64, the compiler automatically generates code for converting floating-point formats. Whenever the application performs a sequence of arithmetic operations, this code does the following:

Where no arithmetic operations are performed (VAX float fetches followed by stores), conversions do not occur. The code handles such situations as moves.

In a few cases, arithmetic calculations might have different results because of the following differences between VAX and IEEE formats:

These differences might cause problems for certain applications.

For more information about the differences between floating-point data types on OpenVMS Alpha and I64 and how these differences might affect ported applications, see Chapter 5 and refer to the OpenVMS Floating-Point Arithmetic on the Intel® Itanium ® Architecture white paper.

float wait_time = 2.0;
lib$wait(&wait_time);

#ifdef __ia64
 int float_type = 4;  /* use S_FLOAT for OpenVMS I64 */
#else
 int float_type = 0;  /* use F_FLOAT for Alpha */
#endif
 float wait_time = 2.0;
 lib$wait(&wait_time,0,&float_type);

#include <libwaitdef.h>
.
.
.
#ifdef __ia64
 int float_type = LIB$K_IEEE_S;  /* use S_FLOAT for IPF */
#else
 int float_type = LIB$K_VAX_F;  /* use F_FLOAT for Alpha */
#endif
 float wait_time = 2.0;
 lib$wait(&wait_time,0,&float_type); 

An incorrect declaration of a command table in code ported to I64 can cause unexpected results. For example, for an application, the Command Definition Utility is used to create an object module from a CLD file. The application then calls CLI$DCL_PARSE to parse command lines. CLI$DCL_PARSE may fail with:

%CLI-E-INVTAB, command tables have invalid format - see documentation 

The code must be modified so that the command table is defined as an external data object.

For example, if in an application, on VAX and Alpha, the command table (DFSCP_CLD) is incorrectly declared in a BLISS module as:

EXTERNAL ROUTINE DFSCP_CLD

This should be changed to

EXTERNAL DFSCP_CLD

Or if it was in a FORTRAN module incorrectly declared as:

EXTERNAL DFSCP_CLD

then it should be changed to

INTEGER DFSCP_CLD
CDEC$ ATTRIBUTES EXTERN :: DFSCP_CLD 

Similarly, in an application written in C, if the command tables previously were defined as follows:

int jams_master_cmd(); 

The code should be changed to be an external reference:

extern void* jams_master_cmd;

The changed, correct declaration works on all platforms: VAX, Alpha or OpenVMS I64.

I64 supports all the thread interfaces that have been supported on OpenVMS since thread support was first introduced. Most OpenVMS Alpha code that uses threads can be ported to I64 without change. This section describes the exceptions. The major porting issue for code that uses threads is the usage of stack space. OpenVMS I64 code uses much more stack space than does equivalent Alpha code. Therefore, a threaded program that works on Alpha might get stack overflow failures on OpenVMS I64.

The default stack size is larger on I64 to help alleviate overflow problems. If the application requests a specific stack size, then the change to the default will be irrelevant, and the application source code might need to be changed to request more stack. VSI recommends starting with an increase of three 8-Kb pages (24576 bytes).

Another side effect of the increased stack size requirement is increased demand on the P0 address region. Thread stacks are allocated from the P0 heap. Larger stacks might cause the process to exceed its memory quotas. In an extreme case, the P0 region could fill completely, in which case the process might need to reduce the number of threads in use concurrently (or make other changes to lessen the demand for P0 memory).

VSI recommends that you familiarize yourself with thread support in OpenVMS. One change to the POSIX Threads C language header file PTHREAD_EXCEPTION.H caused problems when porting an application that relied on its former behavior.

The DCL command THREADCP is not supported on I64. For OpenVMS I64, the DCL commands SET IMAGE and SHOW IMAGE can be used to check and modify the state of threads-related image header flags, similar to the THREADCP command on OpenVMS Alpha. For details, refer to the VSI OpenVMS DCL Dictionary.

The THREADCP command is documented in the Guide to POSIX Threads Library.

If you want to change the setting of threads-related image flags, you need to use the new command SET IMAGE. For example:

$ SET IMAGE/FLAGS=(MKTHREADS,UPCALLS) FIRST.EXE

cma_delay (
    ^
%CC-W-LONGEXTERN, The external identifier name exceeds 31
characters; truncated to "CMA_DELAY_NEEDS_VAX_FLOAT______".

VSI recommends that you align your data naturally to achieve optimal performance for data referencing. Unaligned data can seriously degrade performance on both OpenVMS Alpha and I64.

Data is naturally aligned when its address is an integral multiple of the size of the data in bytes. For example, a longword is naturally aligned at any address that is a multiple of 4, and a quadword is naturally aligned at any address that is a multiple of 8. A structure is naturally aligned when all its members are naturally aligned.

Because natural alignment is not always possible, I64 systems provide help to manage the impact of unaligned data references. Alpha and OpenVMS I64 compilers automatically correct most potential alignment problems and flag others.

In addition to performance degradation, unaligned shared data can cause a program to execute incorrectly. Therefore, you must align shared data naturally. Shared data might be between threads of a single process, between a process and ASTs, or between several processes in a global section.

Finding the Problem

To find instances of unaligned data, you can use a qualifier provided by most OpenVMS I64 compilers that allows the compiler to report compile-time references to unaligned data.

Additional assistance, such as an OpenVMS Debugger qualifier to reveal unaligned data at run time, is planned for a future release.

Eliminating the Problem

To eliminate unaligned data, you can use one or more of the following methods:

If your application relies explicitly on characteristics of the OpenVMS Alpha calling standard, you likely have to change it. The I64 calling standard is based on the Intel calling standard with some OpenVMS modifications. Significant differences introduced in the I64 calling standard include the following:

For more information, see Chapter 2.

This section describes categories of privileged code that require examination, and may require modifications.

http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources

For new program development for I64, VSI recommends the use of high-level languages. VSI provides the VAX Macro-32 compiler for I64 to convert existing VAX MACRO code into machine code that runs on I64 systems.

For more information about porting VAX MACRO programs to I64 systems, refer to the VSI OpenVMS MACRO Compiler Porting and User's Guide.

The VSI OpenVMS Migration Software for Alpha to Integrity Servers is a binary translator for translating Alpha user code images to run on I64 systems. This tool is useful in cases where the source code is no longer available, or when the compiler is not available on OpenVMS I64, or when a third-party product has not been ported to I64. A third-party product's permission is required from the owner of the software.

The VSI OpenVMS Migration Software for Alpha to Integrity Servers offers functionality similar to that of DECmigrate, a binary translator that was used to port OpenVMS VAX images to run on OpenVMS Alpha systems.

For more information, see Section 4.1.2.1.

Some of these qualifiers and options are described in the following sections. For more details on these qualifiers and options see the HP OpenVMS Version 8.2 New Features and Documentation Overview.

%ILINK-E-INVOVRINI, incompatible multiple initializations for overlaid section
    section: <section name>
    module: <module name for first overlaid section>
    file: <file name for first overlaid section>
    module: <module name for second overlaid section>
    file: <file name for second overlaid section>

For an example linker map illustrating this new information, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.

Some new linker options and qualifiers have been added to support linking on I64 systems. This section describes these features.

$ link/SHARE public/PUBLISH,implementation/EXPORT=public
$ link/SHARE plib/LIBRARY/PUBLISH/INCLUDE=public/EXPORT=public

CASE_SENSITIVE=YES.

CASE_SENSITIVE=NO

Note that the NO keyword must appear in uppercase or it will not be recognized by the linker.

To maintain VAX and Alpha behavior it is recommended to switch to case sensitivity only when needed.

For more information and examples, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.

The debugger provided on I64 is different from the OpenVMS VAX and Alpha debugger. Although the I64 debugger shares a similar command interface and debugging functionality, some differences do exist. The following sections describe the capabilities of the I64 Debugger and assume a familiarity with the debugger on OpenVMS VAX and Alpha systems.

In general, the XDelta Debugger for I64 systems behaves the same as XDelta on OpenVMS Alpha systems, with some restrictions. This section describes new capabilities added for OpenVMS and differences between XDelta on I64 and OpenVMS Alpha systems.

You can use the DCL command LIBRARY (or Librarian LBR routines) to create libraries such as an OpenVMS I64 (ELF) object library, OpenVMS I64 (ELF) shareable image library, macro library, help library, and text library. You can maintain the modules in a library or display information about a library and its modules. The OpenVMS I64 Librarian cannot create or process Alpha and VAX objects and shareable images. Rather, the architecture for the Librarian is Intel Itanium.

The default library type created is an object library, if no OBJECT and SHARE qualifiers are specified.

Due to the requirements of the Intel C++ compiler, the OpenVMS I64 library format has been expanded to accommodate new UNIX-style weak symbols. Multiple modules matching key names of new UNIX-style weak symbols can now exist in the same library. The Librarian ignores the OpenVMS-style weak symbol definitions as it has in the past.

UNIX-style weak symbol definitions behave in the same manner as weak transfer addresses on OpenVMS; that is, their definitions are tentative. If a definition of a stronger binding type is not seen during a link operation, the tentative definition is designated as the definitive definition.

This section discusses file types and output file location defaults for the BLISS compiler.

File Types

The default file type for object files for the OpenVMS compilers is .OBJ.

The default output file type for library files is .L32 for BLISS-32EN and BLISS-32IN, and .L64 for BLISS-64EN and BLISS-64IN. Library files are not compatible between dialects.

Output File Location Defaults

For the OpenVMS compilers, regardless of whether they run on OpenVMS Alpha or OpenVMS I64, the location of the output files depends on where in the command line the output qualifier is found.

In both OpenVMS Alpha and OpenVMS I64 BLISS, if an output file qualifier, such as /OBJECT, /LIST, or /LIBRARY, is used after an input file specification and does not include an output file specification, the output file specification defaults to the device, directory, and file name of the immediately preceding input file. For example:

$ BLISS /A32 [FOO]BAR/OBJ     ! Puts BAR.OBJ in directory FOO 
$ BLISS /I32 [FOO]BAR/OBJ     ! Puts BAR.OBJ in directory FOO 
$ 
$ BLISS /A32 /OBJ [FOO]BAR    ! Puts BAR.OBJ in default directory 
$ BLISS /I32 /OBJ [FOO]BAR    ! Puts BAR.OBJ in default directory 
$ 
$ BLISS /A32 [FOO]BAR/OBJ=[]  ! Puts BAR.OBJ in default directory 
$ BLISS /I32 [FOO]BAR/OBJ=[]  ! Puts BAR.OBJ in default directory 

This section describes OpenVMS Alpha BLISS features that are not supported by I64 BLISS.

OpenVMS Alpha BLISS Machine-Specific Built-ins

For information about CMP_SWAP_LONG and CMP_SWAP_QUAD, see the section called “Compare and Swap Built-in Functions”.

OpenVMS Alpha BLISS PALcode Built-in Functions

CALL_PAL           PAL_MFPR_PCBB      PAL_MTPR_SIRR
PAL_BPT            PAL_MFPR_PRBR      PAL_MTPR_SSP    
PAL_BUGCHK         PAL_MFPR_PTBR      PAL_MTPR_TBIA   
PAL_CFLUSH         PAL_MFPR_SCBB      PAL_MTPR_TBIAP  
PAL_CHME           PAL_MFPR_SISR      PAL_MTPR_TBIS   
PAL_CHMK           PAL_MFPR_SSP       PAL_MTPR_TBISD  
PAL_CHMS           PAL_MFPR_TBCHK     PAL_MTPR_TBISI  
PAL_CHMU           PAL_MFPR_USP       PAL_MTPR_USP    
PAL_DRAINA         PAL_MFPR_VPTB      PAL_MTPR_VPTB   
PAL_HALT           PAL_MFPR_WHAMI     PAL_PROBER      
PAL_GENTRAP        PAL_MTPR_ASTEN     PAL_PROBEW      
PAL_IMB            PAL_MTPR_ASTSR     PAL_RD_PS       
PAL_LDQP           PAL_MTPR_DATFX     PAL_READ_UNQ    
PAL_MFPR_ASN       PAL_MTPR_ESP       PAL_RSCC        
PAL_MFPR_ASTEN     PAL_MTPR_FEN       PAL_STQP        
PAL_MFPR_ASTSR     PAL_MTPR_IPIR      PAL_SWPCTX      
PAL_MFPR_ESP       PAL_MTPR_IPL       PAL_SWASTEN     
PAL_MFPR_FEN       PAL_MTPR_MCES      PAL_WRITE_UNQ   
PAL_MFPR_IPL       PAL_MTPR_PRBR      PAL_WR_PS_SW    
PAL_MFPR_MCES      PAL_MTPR_SCBB      PAL_MTPR_PERFMON

Macros are placed in STARLET.REQ for PALCALL built-ins. OpenVMS supplies the supporting code. The privileged CALL_PALs call executive routines and the unprivileged CALL_PALs will call system services.

OpenVMS Alpha BLISS Register Names

   R0       zero register 
   R1       global pointer 
   R2       volatile and GEM scratch register 
   R12      stack pointer 
   R13      thread pointer 
   R14-R16  volatile and GEM scratch registers 
   R17-R18  volatile scratch registers

INTERRUPT and EXCEPTION Linkages

INTERRUPT and EXCEPTION linkages are not supported.

BUILTIN Rn

You cannot specify an OpenVMS I64 register name to the BUILTIN keyword.

I64 BLISS provides only those existing OpenVMS Alpha BLISS features necessary to support I64. Although OpenVMS Alpha BLISS enabled support for features of operating systems other than OpenVMS, such functionality is not included in the OpenVMS I64 BLISS compiler.

I64 BLISS Built-ins

Only those built-ins necessary for the correct operation of I64 are supported by the BLISS OpenVMS I64 compilers.

Common BLISS Built-ins

ABS               CH$FIND_NOT_CH  CH$WCHAR     
ACTUALCOUNT       CH$FIND_SUB     CH$WCHAR_A                
ACTUALPARAMETER   CH$GEQ          MAX             
ARGPTR            CH$GTR          MAXA            
BARRIER           CH$LEQ          MAXU         
CH$ALLOCATION     CH$LSS          MIN             
CH$A_RCHAR        CH$MOVE         MINA            
CH$A_WCHAR        CH$NEQ          MINU            
CH$COMPARE        CH$PLUS         NULLPARAMETER   
CH$COPY           CH$PTR          REF             
CH$DIFF           CH$RCHAR        SETUNWIND       
CH$EQL            CH$RCHAR_A      SIGN            
CH$FAIL           CH$SIZE         SIGNAL          
CH$FILL           CH$TRANSLATE    SIGNAL_STOP   
CH$FIND_CH        CH$TRANSTABLE

RETURNADDRESS Built-in

A new built-in function RETURNADDRESS returns the PC of the caller's caller.

This built-in takes no arguments. The format is:

RETURNADDRESS()

Machine-Specific Built-ins

BARRIER 
ESTABLISH 
REVERT 
 
ROT   
SLL   
SRA   
SRL 
UMULH   
 
AdaWI 
 
ADD_ATOMIC_LONG   AND_ATOMIC_LONG  OR_ATOMIC_LONG 
ADD_ATOMIC_QUAD   AND_ATOMIC_QUAD  OR_ATOMIC_QUAD

TESTBITSSI TESTBITCC  TESTBITCS 
TESTBITCCI TESTBITSS  TESTBITSC

ADDD    DIVD    MULD    SUBD    CMPD 
ADDF    DIVF    MULF    SUBF    CMPF 
ADDG    DIVG    MULG    SUBG    CMPG 
ADDS    DIVS    MULS    SUBS    CMPS 
ADDT    DIVT    MULT    SUBT    CMPT 
 
CVTDF   CVTFD   CVTGD   CVTSF   CVTTD 
CVTDG   CVTFG   CVTGF   CVTSI   CVTTG 
CVTDI   CVTFI   CVTGI   CVTSL   CVTTI 
CVTDL   CVTFL   CVTGL   CVTSQ   CVTTL 
CVTDQ   CVTFQ   CVTGQ   CVTST   CVTTQ 
CVTDT   CVTFS   CVTGT           CVTTS 
 
CVTID   CVTLD   CVTQD 
CVTIF   CVTLF   CVTQF 
CVTIG   CVTLG   CVTQG 
CVTIS   CVTLS   CVTQS 
CVTIT   CVTLT   CVTQT 
 
CVTRDL  CVTRDQ 
CVTRFL  CVTRFQ 
CVTRGL  CVTRGQ 
CVTRSL  CVTRSQ 
CVTRTL  CVTRTQ

New Machine-Specific Built-ins

A number of new built-ins added to I64 BLISS provide access to single OpenVMS I64 instructions that can be used by the operating system.

Built-ins for Single OpenVMS I64 Instructions

  BREAK   (break)         LOADRS (loadrs)        RUM    (rum) 
  BREAK2  (break)*        PROBER (probe.r)       SRLZD  (srlz.d)     
  FC      (fc)            PROBEW (probe.w)       SRLZI  (srlz.i)     
  FLUSHRS (flushrs)       PCTE   (ptc.e)         SSM    (ssm)      
  FWB     (fwb)           PCTG   (ptc.g)         SUM    (sum)    
  INVALAT (invala)        PCTGA  (ptc.ga)        SYNCI  (sync.i) 
  ITCD    (itc.d)         PTCL   (ptc.l)         TAK    (tak)      
  ITCI    (itc.i)         PTRD   (ptr.d)         THASH  (thash) 
  ITRD    (itr.d)         PTRI   (ptr.i)         TPA    (tpa)    
  ITRI    (itr.i)         RSM    (rsm)           TTAG   (ttag)

Access to Processor Registers

These built-ins execute the mov.i instruction, which is detailed in the Intel IA-64 Architecture Software Developer's Manual. The two GET built-ins return the value of the specified register.

To specify the register, a specially encoded integer constant is used, which is defined in an Intel C header file. See the Intel IA-64 Architecture Software Developer's Manual for the contents of this file.

PALcode Built-ins

   PAL_INSQHIL        PAL_REMQHIL
   PAL_INSQHILR       PAL_REMQHILR
   PAL_INSQHIQ        PAL_REMQHIQ
   PAL_INSQHIQR       PAL_REMQHIQR
   PAL_INSQTIL        PAL_REMQTIL
   PAL_INSQTILR       PAL_REMQTILR
   PAL_INSQTIQ        PAL_REMQTIQ
   PAL_INSQTIQR       PAL_REMQTIQR
   PAL_INSQUEL        PAL_REMQUEL
   PAL_INSQUEL_D      PAL_REMQUEL_D
   PAL_INSQUEQ        PAL_REMQUEQ
   PAL_INSQUEQ_D      PAL_REMQUEQ_D

Each of the 24 queue-manipulation PALcalls is implemented by BLISS as a call to an OpenVMS SYS$PAL_xxxx run-time routine.

BLI$CALLG

The VAX idiom CALLG(.AP, ...) is replaced by an assembly routine BLI$CALLG(ARGPTR(), .RTN) for Alpha BLISS. This routine as defined for Alpha BLISS has been rewritten for the OpenVMS I64 architecture and is supported for I64 BLISS.

OpenVMS I64 Registers

The OpenVMS I64 general registers, which can be named in REGISTER, GLOBAL REGISTER, and EXTERNAL REGISTER, and as parameters to LINKAGE declarations, are R3 through R11 and R19 through R31. In addition, parameter registers R32 through R39 can be named for parameters in LINKAGE declarations only.

Currently, there are no plans to support the naming of the OpenVMS I64 general registers R40 through R127.

Naming of any of the OpenVMS I64 Floating Point, Predicate, Branch and Application registers via the REGISTER, GLOBAL REGISTER, EXTERNAL REGISTER, and LINKAGE declarations is not provided.

A register conflict message is issued when a user request for a particular register cannot be satisfied.

ALPHA_REGISTER_MAPPING Switch

A new module level switch, ALPHA_REGISTER_MAPPING, is provided for I64 BLISS.

This switch can be specified in either the MODULE declaration or a SWITCHES declaration. Use of this switch causes a remapping of OpenVMS Alpha register numbers to OpenVMS I64 register numbers as described in this section.

Any register number specified as part of a REGISTER, GLOBAL REGISTER, EXTERNAL REGISTER, or as parameters to GLOBAL, PRESERVE, NOPRESERVE or NOT USED in linkage declarations in the range of 0-31 are remapped according to the IMACRO mapping table as follows:

0  = GEM_TS_REG_K_R8         16 = GEM_TS_REG_K_R14 
1  = GEM_TS_REG_K_R9         17 = GEM_TS_REG_K_R15     
2  = GEM_TS_REG_K_R28        18 = GEM_TS_REG_K_R16     
3  = GEM_TS_REG_K_R3         19 = GEM_TS_REG_K_R17     
4  = GEM_TS_REG_K_R4         20 = GEM_TS_REG_K_R18     
5  = GEM_TS_REG_K_R5         21 = GEM_TS_REG_K_R19     
6  = GEM_TS_REG_K_R6         22 = GEM_TS_REG_K_R22     
7  = GEM_TS_REG_K_R7         23 = GEM_TS_REG_K_R23     
8  = GEM_TS_REG_K_R26        24 = GEM_TS_REG_K_R24     
9  = GEM_TS_REG_K_R27        25 = GEM_TS_REG_K_R25     
10 = GEM_TS_REG_K_R10        26 = GEM_TS_REG_K_R0      
11 = GEM_TS_REG_K_R11        27 = GEM_TS_REG_K_R0      
12 = GEM_TS_REG_K_R30        28 = GEM_TS_REG_K_R0      
13 = GEM_TS_REG_K_R31        29 = GEM_TS_REG_K_R29     
14 = GEM_TS_REG_K_R20        30 = GEM_TS_REG_K_R12     
15 = GEM_TS_REG_K_R21        31 = GEM_TS_REG_K_R0  

The mappings for register numbers 16-20, 26-28, and 30-31 translate into registers that are considered invalid specifications for I64 BLISS (see the section called “OpenVMS Alpha BLISS Register Names” and the section called “OpenVMS I64 Registers”). Declarations that include any of these registers when ALPHA_REGISTER_MAPPING is specified will generate an error such as the following:

         r30 = 30, 
.........^ 
%BLS64-W-TEXT, OpenVMS Alpha register 30 cannot be declared, invalid mapping to 
IPF register 12 at line number 9 in file ddd:[xxx]TESTALPHAREGMAP.BLI

Notice that the source line names register number 30 but the error text indicates register 12 is the problem. It is the translated register for 30, register 12, that is illegal to specify.

16 = GEM_TS_REG_K_R32
17 = GEM_TS_REG_K_R33
18 = GEM_TS_REG_K_R34
19 = GEM_TS_REG_K_R35
20 = GEM_TS_REG_K_R36
21 = GEM_TS_REG_K_R37

ALPHA_REGISTER_MAPPING and "NOTUSED"

When ALPHA_REGISTER_MAPPING is specified, any OpenVMS Alpha register that maps to an IA64 scratch register and is specified as NOTUSED in a linkage declaration will be placed in the PRESERVE set.

This will cause the register to be saved on entry to the routine declaring it NOTUSED and restored on exit.

/ANNOTATIONS Qualifier

The I64 BLISS compiler supports a new compilation qualifier, /ANNOTATIONS. This qualifier provides information in the source listing regarding optimizations that the compiler is making (or not making) during compilation.

All keywords, with the exception of ALL and NONE, are negotiable. The qualifier itself is also negotiable. By default it is not present in the command line.

If the /ANNOTATIONS qualifier is specified without any parameters, the default is ALL.

/ALPHA_REGISTER_MAPPING Qualifier

The I64 BLISS compiler supports a new compilation qualifier to enable ALPHA_REGISTER_MAPPING without having to modify the source. This is a positional qualifier. Specifying this qualifier on the compilation line for a module is equivalent to setting the ALPHA_REGISTER_MAPPING switch in the module header.

/ALPHA_REGISTER_MAPPING Informationals

ADD, AND, Built-in Functions for Atomic Operations

The ADD_ATOMIC_XXXX, AND_ATOMIC_XXXX, and OR_ATOMIC_XXXX built-in functions for atomic updating of memory are supported by I64 BLISS. They are listed in the section called “Machine-Specific Built-ins”.

option_ATOMIC_size(ptr, expr [;old_value] ) !Optional output

where:

option can be AND, ADD, or OR.

size can be LONG or QUAD.

ptr must be a naturally aligned address.

value can be 0 (operation failed) or 1 (operation succeeded).

The operation is addition (or ANDing or ORing) of the expression EXPR to the data segment pointed to by PTR in an atomic fashion.

The optional output parameter OLD_VALUE is set to the previous value of the data segment pointed to by PTR.

Any attempt to use the Alpha BLISS optional retry-count parameter results in a syntax error.

TESTBITxxI and TESTBITxx Built-in Functions for Atomic Operations

The TESTBITxxI and TESTBITxx built-in functions for atomic operations are supported by I64 BLISS. They are listed in the section called “Machine-Specific Built-ins”.

Because the OpenVMS I64 instruction to support these built-ins waits until the operation succeeds, the optional input parameter retry-count and the optional output parameter success_flag have been eliminated. These built-ins now have the following form:

    TESTBITxxx( field )

Any attempt to use the Alpha BLISS optional retry-count or success_flag parameters results in a syntax error.

Granularity of Longword and Quadword Writes

I64 BLISS supports the /GRANULARITY=keyword qualifier, the switch DEFAULT_GRANULARITY=n, and the data attribute GRANUALRITY(n) as described in this section.

Users can control the granularity of stores and fetches by using the command line qualifier /GRANULARITY=keyword, the switch DEFAULT_GRANULARITY=n, and the data attribute GRANULARITY(n).

The keyword in the command line qualifier must be either BYTE, LONGWORD, or QUADWORD. The parameter n must be either 0(byte), 2(longword) or 3(quadword).

When these are used together, the data attribute has the highest priority. The switch, when used in a SWITCHES declaration, sets the granularity of data declared after it within the same scope. The switch may also be used in the module header. The command line qualifier has the lowest priority.

Shift Built-in Functions

Built-in functions for shifts in a known direction are supported for I64 BLISS. They are listed in the section called “Machine-Specific Built-ins”. These functions are valid only for shift amounts in the range 0..%BPVAL-1.

Compare and Swap Built-in Functions

These functions do the following interlocked operations: compare the longword or quadword at addr with comparand and, if they are equal, store value at addr. They return an indicator of success (1) or failure (0).

OpenVMS I64-Specific Multimedia Instructions

There are no plans to support access to the OpenVMS I64-specific multimedia-type instructions.

Linkages

CALL Linkage

The CALL linkage, as described in this section for Alpha BLISS, is also supported by I64 BLISS.

Routines compiled with a 32-bit compiler can call routines compiled with a 64-bit compiler and vice versa. Parameters are truncated when shortened, and sign-extended when lengthened.

By default, CALL linkages pass an argument count. This can be overridden using the NOCOUNT linkage option.

Although the arguments are passed in quadwords, the 32-bit compilers can "see" only the lower 32 bits.

JSB Linkage

The I64 BLISS compilers have a JSB linkage type. Routines declared with the JSB linkage comply with the JSB rules developed for I64.

/[NO]TIE Qualifier

Support for this qualifier continues for I64. The default is /NOTIE.

TIE is used to enable the compiled code to be used in combination with translated images, either because the code might call into a translated image or might be called from a translated image.

/ENVIRONMENT=([NO]FP) and ENVIRONMENT([NO]FP)

The /ENVIRONMENT=([NO]FP) qualifier and the ENVIRONMENT([NO]FP) switch were provided for Alpha BLISS to cause the compiler to disable the use of floating point registers for certain integer division operations.

For I64 BLISS, the /ENVIRONMENT=NOFP command qualifier or ENVIRONMENT(NOFP) switch does not totally disable floating point because of the architectural features of OpenVMS I64. Instead, source code is still restricted not to have floating-point operations, but the generated code for certain operations (in particular, integer multiplication and division and the constructs that imply them) are restricted to using a small subset of the floating-point registers. Specifically, if this option is specified, the compiler is restricted to using f6-f11, and sets the ELF EF_IA_64_REDUCEFP option described in the Intel Itanium Processor-Specific Application Binary Interface.

The /ENVIRONMENT=FP command qualifier and ENVIRONMENT(FP) switch are unaffected.

Floating-Point Support

The following sections discuss support for floating-point operations using the BLISS compiler.

Floating-Point Built-in Functions

BLISS does not have a high level of support for floating-point numbers. The extent of the support involves the ability to create floating-point literals, and there are machine-specific built-ins for floating-point arithmetic and conversion operations. For a complete list. see the section called “Machine-Specific Built-ins”.

None of the floating point built-in functions detect overflow, so they do not return a value.

Floating-Point Literals

The floating-point literals supported by I64 BLISS are the same set supported by Alpha BLISS: %E, %D, %G, %S and %T.

Floating-Point Registers

Direct use of the OpenVMS I64 floating-point registers is not supported.

Calling Non-BLISS Routines with Floating-Point Parameters

It is possible to call standard non-BLISS routines that expect floating-point parameters passed by value and that return a floating-point or complex value.

The standard functions %FFLOAT, %DFLOAT, %GFLOAT, %SFLOAT and %TFLOAT are supported by I64 BLISS.

New and Expanded Lexicals

I64 BLISS Support for IPF Short Data Sections

The IPF calling standard requires that all global data objects with a size of 8 bytes or smaller be allocated in short data sections.

Short data sections can be addressed with an efficient code sequence that involves adding a 22-bit literal to the contents of the GP base register. This code sequence limits the combined size of all the short data sections. A linker error occurs if the total amount of data allocated to short data sections exceeds a size of 2**22 bytes. Compilers on IPF can use GP relative addressing when accessing short globals and short externals.

I64 BLISS exhibits new behavior for the PSECT attribute GP_RELATIVE and for the new PSECT attribute SHORT, which supports allocating short data sections.

Specifying the GP_RELATIVE keyword as a PSECT attribute causes PSECT to be labeled as containing short data so that the linker will allocate the PSECT close to the GP base address.

The syntax of the SHORT attribute is as follows:

"SHORT" "(" psect-name ")"

Example

PSECT 
 
  NODEFAULT = $GLOBAL_SHORT$ 
    (READ,WRITE,NOEXECUTE,NOSHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3), 
    GP_RELATIVE), 
 
! The above declaration of $GLOBAL_SHORT$ is not needed.  If the above 
! declaration were deleted then the SHORT($GLOBAL_SHORT$) attribute in 
! the following declaration would implicitly make an identical 
! declaration of $GLOBAL_SHORT$. 
 
  GLOBAL = $GLOBAL$ 
    (READ,WRITE,NOEXECUTE,NOSHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3), 
    SHORT($GLOBAL_SHORT$)), 
 
  NODEFAULT = MY_GLOBAL 
    (READ,WRITE,NOEXECUTE,SHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3)), 
 
  PLIT = $PLIT$ 
    (READ,NOWRITE,NOEXECUTE,SHARE,NOPIC,CONCATENATE,GLOBAL,ALIGN(3), 
    SHORT($PLIT_SHORT$)); 
 
GLOBAL 
        X1,                     ! allocated in $GLOBAL_SHORT$ 
        Y1 : VECTOR[2,LONG],    ! allocated in $GLOBAL_SHORT$ 
        Z1 : VECTOR[3,LONG],    ! allocated in $GLOBAL$ 
        A1 : PSECT(MY_GLOBAL),  ! allocated in MY_GLOBAL 
        B1 : VECTOR[3,LONG] PSECT(MY_GLOBAL), ! allocated in MY_GLOBAL 
        C1 : VECTOR[3,LONG] 
                PSECT($GLOBAL_SHORT$); ! allocated in $GLOBAL_SHORT$ 
 
PSECT GLOBAL = MY_GLOBAL; 
! use MY_GLOBAL as default for both noshort/short 
 
GLOBAL 
        X2,                     ! allocated in MY_GLOBAL 
        Y2 : VECTOR[2,LONG],    ! allocated in MY_GLOBAL 
        Z2 : VECTOR[3,LONG],    ! allocated in MY_GLOBAL 
        A2 : PSECT($GLOBAL$),   ! allocated in $GLOBAL_SHORT$ 
        B2 : VECTOR[3,LONG] PSECT($GLOBAL$); ! allocated in $GLOBAL$; 
 
! Note that the allocations of A1, X2 and Y2 violate the calling 
! standard rules.  These variables cannot be shared with other 
! languages, such as C or C++. 
 
PSECT GLOBAL = $GLOBAL$; 
! back to using $GLOBAL$/$GLOBAL_SHORT$ as default noshort/short 
 
GLOBAL BIND 
        P1 = UPLIT("abcdefghi"),        ! allocated in $PLIT$ 
        P2 = PLIT("abcdefgh"),          ! allocated in $PLIT_SHORT$ 
        P3 = PSECT(GLOBAL) PLIT("AB"),  ! allocated in $GLOBAL_SHORT$ 
        p4 = PSECT($PLIT_SHORT$) 
                PLIT("abcdefghijklmn"), ! allocated in $PLIT_SHORT$ 
        P5 = PSECT(MY_GLOBAL) PLIT("AB"); ! allocated in MY_GLOBAL

The COBOL compiler on Alpha defaults to /FLOAT=D_FLOAT. For OpenVMS I64, the default is /FLOAT=IEEE_FLOAT.

The COBOL compiler does not support /IEEE_MODE. The COBOL RTL sets up the run-time environment on OpenVMS I64 to be similar in terms of exception handling and rounding to what is provided in the COBOL run-time environment on OpenVMS Alpha.

The COBOL Release Notes and the white paper entitled OpenVMS Floating-Point Arithmetic on the Intel® Itanium ® Architecture together describe how COBOL deals with floating-point issues on OpenVMS I64.

For the sake of "compile-and-go" compatibility, OpenVMS Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted by the COBOL compiler on OpenVMS I64. An informational message is displayed indicating that they are ignored.

OpenVMS I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the COBOL compiler for development purposes only. Their behavior is unpredictable and they should not be used.

The Fortran release notes and the white paper entitled OpenVMS Floating-Point Arithmetic on the Intel ® Itanium ® Architecture together describe how VSI Fortran for OpenVMS I64 deals with floating-point issues.

See the Related Documents section in the Preface for the web location of this white paper and other OpenVMS-to-Itanium architecture resources.

Highlights are summarized as follows:

As specified in the white paper, OpenVMS Floating-Point Arithmetic on the Itanium® Architecture, the number, type and location of floating-point exceptions raised during the execution of an application on OpenVMS I64 may not be the same as on OpenVMS Alpha. This is particularly true for VAX-format floating-point. In that case exceptions are (in general) only raised on the convert back to VAX-format after the computation is over.

Three consequences may be of interest for users of VAX-format floating-point:

The F77 compiler, previously invoked with the /OLD_F77 qualifier, is not available. Development is currently underway to provide the following functionality contained in the OpenVMS Alpha F77 compiler that is not available in the OpenVMS I64 and OpenVMS Alpha F90 compilers:

For the sake of "compile-and-go" compatibility, OpenVMS Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted on the compiler invocation command. An informational message is printed saying they are ignored.

OpenVMS I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the I64 compiler for development purposes only. Their behavior is unpredictable and they should not be used.

The native OpenVMS Alpha compiler defaults to /FLOAT=G_FLOAT. For OpenVMS I64, the default is /FLOAT=IEEE_FLOAT/IEEE=DENORM.

On I64, there is no hardware support for floating-point representations other than IEEE. The VAX floating point formats are supported in the compiler by generating run-time code to convert to IEEE format in order to perform arithmetic operations, and then convert the IEEE result back to the appropriate VAX format. This imposes additional run-time overhead and a possible loss of accuracy compared to performing the operations in hardware on the OpenVMS Alpha (and VAX). The software support for the VAX formats is an important functional compatibility requirement for certain applications that deal with on-disk binary floating-point data, but its use should not be encouraged by letting it remain the default. This change is similar to the change in default from /FLOAT=D_FLOAT on VAX to /FLOAT=G_FLOAT on OpenVMS Alpha.

Note also that the default /IEEE_MODE has changed from FAST (on Alpha) to DENORM_RESULTS on I64. This means that, by default, floating-point operations silently generate values that print as Infinity or Nan (the industry-standard behavior) instead of issuing a fatal run-time error as they would using VAX format float or /IEEE_MODE=FAST. Also, the smallest-magnitude nonzero value in this mode is much smaller because results are permitted to enter the denormal range instead of being flushed to zero as soon as the value is too small to represent with normalization.

On Alpha, the /IEEE_MODE qualifier generally has its greatest effect on the generated code of a compilation. When calls are made between functions compiled with different /IEEE_MODE qualifiers, each function produces the /IEEE_MODE behavior with which it was compiled.

On I64, the /IEEE_MODE qualifier primarily affects only the setting of a hardware register at program startup. In general, the /IEEE_MODE behavior for a given function is controlled by the /IEEE_MODE option that was specified on the compilation that produced the main program. The compiler marks the object module of each compilation with the floating-point control options specified by the compile-time qualifiers. When the OpenVMS I64 linker produces an executable image, it copies the floating point controls from the object module that supplied the main entry point transfer address for the image into the image itself; this is called the "whole program floating-point mode" for the image. Then when the image is activated for execution, the hardware's floating-point controls are initialized according to this whole program floating point mode. It is expected that code that modifies the floating-point controls at run-time will be written to ensure that the whole program floating point mode settings get restored whenever control passes out of the section of code that required the specific setting of the controls at run-time.

When the /IEEE_MODE qualifier is applied to a compilation that does not contain a main program, the qualifier does have some effect: it can affect the evaluation of floating-point constant expressions, and it is used to set the EXCEPTION_MODE used by the math library for calls from that compilation.

The qualifier has no effect on the exceptional behavior of floating-point calculations generated as inline code for that compilation. Therefore, if floating point exceptional behavior is important to an application, all of its compilations, including the one containing the main program, should be compiled with the same /FLOAT and /IEEE_MODE settings.

Note that even on OpenVMS Alpha, setting /IEEE_MODE=UNDERFLOW_TO_ZERO requires the setting of a run-time status register; therefore, this setting needs to be specified on the compilation containing the main program in order to be effective in other compilations.

Finally, note that the /ROUNDING_MODE qualifier is affected in the same way as /IEEE_MODE, and is included in the whole program floating-point mode, and that because VAX floating point operations are actually performed using IEEE instructions, compilations that use VAX format floating-point exhibit the same whole program floating-point mode settings as compilations with /IEEE_MODE=DENORM/ROUND=NEAREST.

The compiler predefines a number of macros with the same meanings as in the native OpenVMS Alpha compiler, except that it does not predefine any of the macros that specify the OpenVMS Alpha architecture. Instead, it predefines the macros __ia64 and __ia64__, as is the practice in the Intel and gcc compilers for OpenVMS I64. The change in floating-point representation from G_FLOAT to IEEE is reflected in the macros that are predefined by default.

Some users have tried defining the macro __ALPHA explicitly by using /DEFINE or by putting it in a header file as a quick way to deal with source code conditionals that were written to assume that if __ALPHA is not defined, then the target must be a VAX system. Doing this causes the CRTL headers and other OpenVMS headers to take the wrong path for OpenVMS I64. You must not define any of the OpenVMS Alpha architecture predefined macros when using this compiler.

Exactly the same considerations for floating-point defaults, /IEEE_MODE semantics, and predefined macros as described for the C compiler above apply to the C++ compiler.

The long double type is always represented in 128-bit IEEE quad precision. The /L_DOUBLE_SIZE=64 qualifier is ignored with a warning. Note that on OpenVMS Alpha, C++ library support for 64-bit lon double was limited - code that requires a 64-bit floating point type should use double instead of long double.

The object model and name mangling schemes used by the C++ compiler on OpenVMS I64 differ significantly from those used on OpenVMS Alpha. The "ARM" object model is not available, the only object model is one that supports the ANSI/ISO C++ standard. However, this still differs from the /MODEL=ANSI object model implemented on OpenVMS Alpha, as the model on OpenVMS I64 is an implementation of the industry-standard OpenVMS I64 ABI. Programs that rely on the layout of C++ objects (non "POD" data), or on the external mangles names as encoded in the .obj file, will need to be reworked. Such programs are inherently highly implementation-dependent. But programs that use standard C++ features in a reasonable implementation-independent manner should not have difficulty in porting.

The "cfront" dialect is no longer supported (and will be removed from OpenVMS Alpha as well). Compilations specifying /standard=cfront will instead use the "relaxed_ansi" dialect.

On I64, .OBJ files are implemented in ELF format rather than EOBJ, and along with the OpenVMS I64 linker they support the notion of "COMDAT" sections that have been used for some time on both Windows and Unix platforms to resolve the issues of duplicate definitions at link-time that arise when using C++ templates and inline functions. On OpenVMS Alpha, these issues are handled by the repository mechanism, which arranges to present a single defining instance to the linker. On OpenVMS I64, no repository mechanism is needed to do this, as duplicates are discarded by the linker automatically. So the repository-based template instantiation options supported on OpenVMS Alpha are not supported on IPF. OpenVMS Alpha build procedures that attempt to manipulate objects in the repository will fail on OpenVMS I64 and will need to be changed (because there are no objects in the repository on OpenVMS I64, just the demangler database). In most cases, the reason for manipulating the repository directly in the build procedure has been eliminated by the compiler's use of COMDAT instantiation.

For the sake of “compile-and-go” compatibility, OpenVMS Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted on the compiler invocation command. An informational message is printed saying they are ignored.

OpenVMS I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the I64 compiler for development purposes only. Their behavior is unpredictable and they should not be used.

For the sake of "compile-and-go" compatibility, OpenVMS Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted on the compiler invocation command. An informational message is printed saying they are ignored.

OpenVMS I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the I64 compiler for development purposes only. Their behavior is unpredictable and they should not be used.

The Itanium architecture was developed by HP and Intel as a 64-bit processor for engineering workstations and e-commerce servers. The Itanium processor family uses a new architecture called Explicitly Parallel Instruction Computing (EPIC).

Some of the most important goals in the design of EPIC were instruction-level parallelism, software pipelining, speculation, predication, and large register files. These allow Itanium processors to execute multiple instructions simultaneously. EPIC exposes many of these parallel features to the compiler (hence "Explicitly" in the name). This increases the complexity of the compiler, but it allows the compiler to directly take advantage of these features.

EPIC is designed so future generations of processors can utilize different levels of parallelism, which increases the flexibility of future designs. This allows the machine code to express where the parallelism exists without forcing the processor to conform to previous machine widths.

For more information on assembly programming for the Intel Itanium processor family, see the Intel ® Itanium ® Architecture Assembly Language Reference Guide, available at:

http://developer.intel.com/software/products/opensource/tools1/tol_whte2.html

Alpha is a 64-bit load/store RISC architecture that is designed with particular emphasis on the three elements that most affect performance: clock speed, multiple instruction issue, and multiple processors.

The Alpha architects examined and analyzed current and theoretical RISC architecture design elements and developed high-performance alternatives for the Alpha architecture.

The Alpha architecture is designed to avoid bias toward any particular operating system or programming language. Alpha supports the OpenVMS Alpha, Tru64 UNIX, and Linux operating systems and supports simple software migration for applications that run on those operating systems.

Alpha was designed as a 64-bit architecture. All registers are 64 bits in length and all operations are performed between 64-bit registers. It is not a 32-bit architecture that was later expanded to 64 bits.

The instructions are very simple. All instructions are 32 bits in length. Memory operations are either loads or stores. All data manipulation is done between registers.

The Alpha architecture facilitates pipelining multiple instances of the same operations because there are no special registers and no condition codes.

The instructions interact with each other only by one instruction writing a register or memory and another instruction reading from the same place. That makes it particularly easy to build implementations that issue multiple instructions every CPU cycle.

Alpha makes it easy to maintain binary compatibility across multiple implementations and easy to maintain full speed on multiple-issue implementations. For example, there are no implementation-specific pipeline timing hazards, no load-delay slots, and no branch-delay slots.

The Alpha architecture reads and writes bytes between registers and memory with the LDBU and STB instructions. (Alpha also supports word read/writes with the LDWU and STW instructions.) Byte shifting and masking are performed with normal 64-bit register-to-register instructions, crafted to keep instruction sequences short.

As viewed from a second processor (including an I/O device), a sequence of reads and writes issued by one processor can be arbitrarily reordered by an implementation. This allows implementations to use multibank caches, bypassed write buffers, write merging, pipelined writes with retry on error, and so forth. If strict ordering between two accesses must be maintained, explicit memory barrier instructions can be inserted in the program.

The basic multiprocessor interlocking primitive is a RISC-style load_locked, modify, store_conditional sequence. If the sequence runs without interrupt, exception, or an interfering write from another processor, then the conditional store succeeds. Otherwise, the store fails and the program eventually must branch back and retry the sequence. This style of interlocking scales well with very fast caches and makes Alpha an especially attractive architecture for building multiple-processor systems.

A privileged architecture library (PALcode) is a set of subroutines that are specific to a particular Alpha operating system implementation. These subroutines provide operating-system primitives for context switching, interrupts, exceptions, and memory management. PALcode is similar to the BIOS libraries that are provided in personal computers.

For more information, refer to the Alpha Architecture Handbook.