HP OpenVMS Systems Documentation

HP BASIC for OpenVMS
Reference Manual

In I64 BASIC/Alpha BASIC, unlike VAX BASIC, you cannot have duplicate line numbers or line numbers not in ascending numerical order. This restriction applies to single source files or source files concatenated with a plus sign (+) at the DCL command line. Duplicate line numbers or line numbers not in ascending order cause "E" level compilation errors.

VAX BASIC does allow duplicates and lines out of order. I64 BASIC/Alpha BASIC provides an example TPU command procedure to help work around this difference. It can be used to append source files and sort BASIC line numbers into ascending numerical order from one or more source files.

After installation of Alpha BASIC, the TPU command procedure is located in:

SYS$COMMON:[SYSHLP.EXAMPLES.BASIC]BASIC$ENV.TPU.

Instructions for its use are in the file.

To achieve the most efficient performance, the I64 BASIC/Alpha BASIC compiler may reorder the execution of arithmetic instructions. Rarely does this result in error handling semantics that are incompatible with VAX BASIC; most programs are not affected by this change.

Use the I64 BASIC/Alpha BASIC /SYNCHRONOUS_EXCEPTIONS qualifier for those programs that require exact VAX BASIC behavior.

C.2.3.11 Generation of Object Modules

In I64 BASIC/Alpha BASIC, the default behavior places all routines (SUBs, FUNCTIONs, and main programs) compiled within a single source program into a single module in the object file. VAX BASIC generates each routine as a separate module. Use the I64 BASIC/Alpha BASIC /SEPARATE_COMPILATION qualifier to duplicate VAX BASIC behavior. See the information on qualifiers on the BASIC command line in the HP BASIC for OpenVMS User Manual.

C.2.3.12 RESUME and DEF

VAX BASIC does not enforce the documented restriction that a RESUME statement lexically outside a DEF statement (without a target specified) cannot resume program execution within a DEF statement. I64 BASIC/Alpha BASIC enforces this restriction at run time.

C.2.3.13 Exceptions

When the I64 BASIC/Alpha BASIC compiler determines that the result of an expression is never used, the compiler does not generate code to evaluate that expression. This causes an incompatibility with VAX BASIC if the removed expression causes an exception. In the following example, the program generates a divide-by-zero error in VAX BASIC. It runs without error in I64 BASIC/Alpha BASIC because I64 BASIC/Alpha BASIC, recognizing that the variable A is never used, does not generate code to evaluate the expression that is assigned to A:

B = 5
A = B / 0
END

There is a small difference in the way compiler messages are reported. In VAX BASIC, the source information appears before the message text, and includes both source and listing line numbers. In I64 BASIC/Alpha BASIC, the source information appears after the message text and includes only source line numbers.

When the I64 BASIC/Alpha BASIC compiler reports source line information, the message looks like:

%BASIC-E-xxxxxxxxx, xxxxxxxxxxxxx at line number YY in file xxxxxxxxxxx

In both I64 BASIC/Alpha BASIC and VAX BASIC, the reported line number is the physical source line in the file. It is not the BASIC line number that might occur in the source program.

C.2.3.15 Error Status Returned to DCL

When errors occur, the I64 BASIC/Alpha BASIC and VAX BASIC compilers at times return a different status to DCL. For example, when the file specified at the DCL command line cannot be found, I64 BASIC/Alpha BASIC returns BASIC--F--ABORT; VAX BASIC returns BASIC--F--OPENIN.

C.2.3.16 SYS$INPUT

In I64 BASIC/Alpha BASIC, when you specify SYS$INPUT as the input file specification at the DCL command line, the object file and the listing file are named differently from VAX BASIC. In I64 BASIC/Alpha BASIC, the compiler names the files with the file types .OBJ and .LIS (with nothing preceding). In VAX BASIC, the compiler names the files NONAME.OBJ and NONAME.LIS.

C.2.3.17 FSS$ Function

The VAX BASIC compiler compiles a program that uses the FSS$ function, but if the FSS$ function is invoked at run time, the following run-time error is generated:

%BAS-F-NOTIMP, Not implemented

The I64 BASIC/Alpha BASIC compiler reports all uses of the FSS$ function by generating the following error at compile time:

%BAS-E-BLTFUNNOT, built-in function not supported

The BAS$K_FAC_NO constant is not defined on OpenVMS I64/Alpha systems. You should replace all occurrences of the EXTERNAL LONG CONSTANT BAS$K_FAC_NO with EXTERNAL LONG CONSTANT BAS$_FACILITY. OpenVMS VAX systems use the constant BAS$K_FAC_NO to communicate the facility number between SYS$LIBRARY:BASRTL.EXE and SYS$LIBRARY:BASRTL2.EXE; it is not needed on OpenVMS I64/Alpha systems.

C.2.3.19 Math Functions with Different Results

Some math function results differ between I64 BASIC/Alpha BASIC and VAX BASIC, because underlying OpenVMS I64/Alpha system routines use improved algorithms to perform these operations.

C.2.3.20 Floating-Point Errors

Some programs that run successfully on OpenVMS VAX systems may fail on OpenVMS I64/Alpha systems with division by zero or other floating-point errors. Examine your failing program for a dirty floating-point zero. A dirty floating-point zero is a number represented by a zero exponent and a nonzero mantissa. Most OpenVMS VAX system instructions treat the invalid floating-point number as a zero, but it causes an exception to be generated by some OpenVMS I64/Alpha instructions.

You cannot create a dirty zero by using BASIC arithmetic expessions. You can create a dirty zero by reading it from a file. BASIC I/O statements, such as GET and MOVE FROM, move bytes of data to a variable without checking that the data is valid for the variable.

Correct the problem in one of the following ways:

• Determine how the dirty zero was created and make the correction. This is the preferred way.
• Write a routine to clean any floating-point numbers that receive a dirty zero value.

The following is an example of a routine that cleans a single precision floating-point number (you can write similiar routines to clean double or G-floating numbers):

SUB CLEAN_SINGLE( SINGLE A )
    MAP (OVER) SINGLE B
     MAP (OVER) WORD W1,W2
     B = A
     IF (W1 AND 32640%) = 0% THEN
            A = 0
     END IF
END SUB

The routine accepts a floating-point number, checks for a zero exponent, and clears the mantissa. It redefines the floating-point number as an integer so that the proper bits are tested.

For more information on floating-point formats and dirty zeros, see the Alpha Architecture Reference Manual.

C.2.3.21 Error Detection on Illegal MAT Operations

Following are two differences in error detection on illegal MAT operations:

• I64 BASIC/Alpha BASIC correctly reports ILLOPE (Error 141 - "Illegal operation") if an attempt is made to perform matrix multiplication when the destination matrix is identical to either source matrix. VAX BASIC does not correctly detect and report the ILLOPE message if an attempt is made to perform the following matrix multiplication, where B is a virtual array, and A is either a virtual array or an in-memory array:

  MAT B = A * B

• Under certain conditions, VAX BASIC does not enforce the documented restriction that arrays used in MAT operations must have zero lower bounds. I64 BASIC/Alpha BASIC always reports either a LOWNOTZER error at compile time, or a MATDIMERR error at run time, when attempting to perform MAT operations on arrays with nonzero lower bounds.

There are debugging differences between VAX BASIC and I64 BASIC/Alpha BASIC, especially during use of the debugger STEP command around exception handlers, DEF functions, external subprograms, and GOSUB routines.

These differences are described below and in the HP BASIC for OpenVMS User Manual.

When the debugger STEP command is used in source code containing an error, differences occur in the Debugger behavior between OpenVMS VAX and OpenVMS I64/Alpha. These differences are due to architectural differences in the hardware and software of the two systems.

In I64 BASIC/Alpha BASIC, a STEP at a statement that causes an exception might never return control to the debugger. The debugger cannot determine what statement in the BASIC source code will execute after the exception occurs. Therefore, set explicit breaks if you use STEP on statements that cause exceptions.

The following hints should help when you use the STEP command to debug programs that handle errors:

• When you STEP at a statement that takes an error, the debugger will not regain control unless the program reaches an explicit breakpoint or the next statement that would have executed if no error had occurred. Set explicit breaks if you want the program to stop in any other place.
• Use of the STEP command at a statement that takes an error does not return control to the debugger when the program reaches the error handler code. If you want the program to break when program execution enters an error handler, explicitly set a breakpoint at the error handler. This applies to both ON ERROR handlers and WHEN handlers.
• If you are within a WHEN handler, a STEP at a statement that terminates execution within the WHEN handler (CONTINUE, RETRY, END WHEN, END HANDLER, EXIT HANDLER) will not stop unless program flow reaches a point where an explicit breakpoint is set.
• A STEP at a RESUME statement in an ON ERROR handler stops program execution at the first line of non-error-handler code.
• Use SET BREAK/EXCEPTION at the beginning of the debugging session to prevent unexpected errors from occurring. This breakpoint is not necessary if you have set explicit breakpoints at all error handlers. However, use of this command will break at all exceptions, allowing you to check that you have the proper breakpoints to stop program execution following the exception.

Following are differences in listing files between I64 BASIC/Alpha BASIC and VAX BASIC:

• /MACHINE/LIST---In VAX BASIC, if you specify BASIC/MACHINE, you get a listing file containing a machine language listing but no source code listing. I64 BASIC/Alpha BASIC, if you specify BASIC/MACHINE, you do not get either listing. You must specify /LIST to get listing files. In I64 BASIC/Alpha BASIC, specifying /MACHINE/LIST gives you both the machine language and the source code in the listing file.
  When VAX BASIC creates a listing file for a program with more than one routine, it places the machine code for each routine after the source code for that routine. The listing file produced by the I64 BASIC/Alpha BASIC compiler contains the source listing for all the routines followed by the machine code listing for all the routines, unless you use the /SEPARATE_COMPILATION qualifier.
• %PAGE---In I64 BASIC/Alpha BASIC, the %PAGE directive appears on the page following the page break. In VAX BASIC, the %PAGE directive appears on the page before the page break.
• %TITLE and %SBTTL strings---These are truncated at 31 characters in I64 BASIC/Alpha BASIC, and 45 characters in VAX BASIC.
• Form feeds---VAX BASIC treats form feeds as %PAGE directives. I64 BASIC/Alpha BASIC does no special processing with form feeds. When a form feed occurs in the source file, that form feed occurs in the listing file, but no listing header information accompanies the form feed.
• /SHOW=MAP qualifier---The following differences occur in I64 BASIC/Alpha BASIC when you use the /SHOW=MAP qualifier:
  • I64 BASIC/Alpha BASIC leaves the offset field in the allocation map blank in cases where the values are not applicable, or not available to the listing phase.
  • In dynamic maps of arrays, VAX BASIC reports the size of the array descriptors; I64 BASIC/Alpha BASIC reports the size of the array.
• Message placement---The placement of some error messages in the listing file may differ between VAX BASIC and I64 BASIC/Alpha BASIC. For example, in I64 BASIC/Alpha BASIC, errors that require flow analysis such as "unreachable code" and "routine can never be called" appear in the listing after the source code and allocation map listing. In listings for source files that contain more than one routine, these errors appear after the source and allocation listing for all routines in the compilation, unless the /SEPARATE_COMPILATION is specified.

This section describes differences between I64 BASIC/Alpha BASIC, VAX BASIC, and other languages within the common language environment.

C.2.4.1 Creating PSECTs with COMMON and MAP Statements

In I64 BASIC/Alpha BASIC, the PSECT attributes are different from those in VAX BASIC, as follows:

In I64 BASIC/Alpha BASIC, the lengths of the PSECTs that the COMMON and MAP statements create are rounded up to a multiple of 16. The size of COMMON or MAP does not change; the size of the PSECT does. This change is visible only to applications that use shareable images in a multilanguage environment.

Both I64 BASIC/Alpha BASIC and VAX BASIC create PSECTs that are compatible with those of other languages on the same platform, with the exception of MACRO. You can link with modules written in languages other than MACRO without changing code. If you link against MACRO modules that reference these PSECTs, you may need to make corresponding changes in the MACRO code.

C.2.4.2 64-Bit Floating-Point Data

In most other HP languages, the default 64-bit floating-point data type has changed from D_floating on OpenVMS VAX systems to G_floating on OpenVMS Alpha systems to T_floating on OpenVMS IA64 systems. If you communicate BASIC DOUBLE (OpenVMS D_floating) data between BASIC and one of the other languages that have made this change, you need to do one of the following:

• In the compiler command line of the other language, change the 64-bit floating-point data type to D_floating to match the behavior of Alpha BASIC or to T_floating to match the behavior of I64 BASIC.
• In your BASIC program, change the data type of the 64-bit floating-point data from DOUBLE to GFLOAT or TFLOAT to match the other language.

Direct use of the following routines by I64 BASIC/Alpha BASIC programs is unsupported. Attempts to execute any of these routines will result in an error.

In LIB$ROUTINES module:

LIB$INSERT_TREE_64
LIB$SHOW_VM_64
LIB$SHOW_VM_ZONE_64

In STARLET module:

SYS$CREATE_BUFOBJ_64
SYS$CREATE_GFILE
SYS$CREATE_GPFILE
SYS$CREATE_REGION_64
SYS$CRETVA_64
SYS$CRMPSC_FILE_64
SYS$CRMPSC_GFILE_64
SYS$CRMPSC_GPFILE_64
SYS$DELTVA_64
EXPREG_64
SYS$IO_CLEANUP
SYS$IO_PERFORM
SYS$IO_PERFORMW
SYS$LCKPAG_64
SYS$LKWSET_64
SYS$MGBLSC_64
SYS$PURGE_WS
SYS$SETPRI_64
SYS$ULKPAG_64
SYS$ULWSET_64
SYS$UPDESC_64
SYS$UPDSEC_64W