HP Pascal V6.0-107 for OpenVMS I64 Systems Release Notes 5 April 2006 Copyright 2006 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP and/or its subsidiaries required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. Neither HP nor any of its subsidiaries shall be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for HP products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty. This document contains information about HP Pascal V6.0-107 including new features, differences between V6.0-107 and previous versions, corrections included, and other topics. This file is of interest to both system management and application programmers. CONTENTS CHAPTER 1 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 1.1 Overview Of HP Pascal . . . . . . . . . . . . . . 1-1 1.2 New Features In HP Pascal For OpenVMS I64 . . . . 1-1 1.2.1 New Features . . . . . . . . . . . . . . . . . . 1-1 1.2.2 Differences Between OpenVMS Alpha And OpenVMS I64 . . . . . . . . . . . . . . . . . . . . . . 1-5 1.2.3 Known Problems In HP Pascal V6.0 For OpenVMS I64 1-6 1.3 HP Pascal Web Page . . . . . . . . . . . . . . . . 1-6 1.4 Debug Support For Schema Types . . . . . . . . . . 1-6 1.5 Limited Support For 64-bit Pointer Types . . . . . 1-8 1.5.1 Language Features Not Supported With 64-bit Pointers . . . . . . . . . . . . . . . . . . . . 1-8 1.5.2 Using 64-bit Pointers With System Definition Files . . . . . . . . . . . . . . . . . . . . 1-10 1.6 Creating Files With RMS "Undefined" Record Types 1-12 1.7 Using The POS Attribute With Natural Alignment . 1-12 1.8 Using $FILESCAN With HP Pascal . . . . . . . . . 1-13 1.9 Using Condition Handlers That Return SS$_CONTINUE 1-13 1.10 Known Problems And Restrictions . . . . . . . . 1-15 1.11 STARLET Definition Files . . . . . . . . . . . . 1-19 1.12 Compiling For Optimal Performance . . . . . . . 1-20 1.13 Problems Corrected Since Last Release Of HP Pascal . . . . . . . . . . . . . . . . . . . . . 1-20 2 CHAPTER 1 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 1.1 Overview Of HP Pascal The HP Pascal V6.0-107 compiler contains several new features based on customer requests. The HP Pascal compiler requires OpenVMS I64 V8.2 or later. 1.2 New Features In HP Pascal For OpenVMS I64 The HP Pascal V6.0 compiler for OpenVMS I64 systems contains the following new features based on customer requests. Unless specified, the following new features have been added to all HP Pascal OpenVMS targets. 1.2.1 New Features The following new features have been added. 1. A new BYTE_ALIGNED_POINTERS keyword has been added to the /ASSUME DCL qualifier. This keyword specifies that the compiler should assume that all pointers point to memory that is only aligned on byte boundaries. Normally, the compiler assumes that pointer variables are initialized by a call to the NEW predeclared routine. The memory returned by NEW is at least quadword aligned. The compiler can take advantage of that alignment to generate better code. However, if the program initializes the pointers by some other means such as IADDRESS or typecasting with values that are not quadword aligned, then the generated code may produce alignment faults. While the alignment faults are silently handled by OpenVMS, the resulting performance loss might be significant. 1-1 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES By specifying BYTE_ALIGNED_POINTERS, the compiler will generate slightly slower code to fetch the value. However, compared to the overhead of correcting the alignment faults, this additional overhead is very small. The preferred solution is to ensure that all pointers contain quadword aligned addresses and use the default of NOBYTE_ALIGNED_POINTERS. 2. The IN and NOT IN operators have been enhanced to accept string arguments to determine if the string on the left hand side of the operator is IN, or NOT IN the string on the right hand side, respectively. This enhancement can be used to make programs easier to understand. The string1 IN string2 expression is identical to INDEX(string2,string1) <> 0 and the string1 NOT IN string2 expression is identical to INDEX(string2,string1) = 0 3. The SUBSTR predeclared function has been enhanced to allow the third operand, the substring size, to be optional. When omitted, the SUBSTR function will return the string that starts at the start index and continues to the end of the string. This enhancement has only been added to the Alpha and I64 compilers. The SUBSTR(string,start_index) is identical to SUBSTR(string,start_index,length(string)-string_index+1) 4. A %FLOAT directive has been added to determine the floating point default. The %FLOAT directive expands to either "VAX_FLOAT" or "IEEE_FLOAT" depending on the setting of the /FLOAT DCL qualifier or the [FLOAT] module-level attribute. 1-2 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 5. Several directives have been added to create floating literals of a specific type regardless of the current default floating type of the module. - %F_FLOAT - produce a VAX F_floating literal - %D_FLOAT - produce a VAX D_floating literal - %G_FLOAT - produce a VAX G_floating literal - %S_FLOAT - produce an IEEE S_floating literal - %T_FLOAT - produce an IEEE T_floating literal The syntax is: %x_FLOAT floating-point-literal where "x" is 'F','D','G','S', or 'T'. HP Pascal has had the ability to declare and use both VAX and IEEE floating point types in the same module using the predeclared types, F_FLOAT, D_FLOAT, G_FLOAT, S_FLOAT, and T_FLOAT. However, floating point literals were always parsed based on the default floating type in the module. With the addition of the new directives, you can now write code like: lib$wait(%f_float 1.0); which will pass the correct floating literal to LIB$WAIT regardless of the default floating type of the module. 6. The BIN, OCT, HEX, DEC, and UDEC builtins are now supported in compile-time expressions. However, while the BIN, OCT, and HEX builtins accept expressions of any time when used in run-time expressions, they only support ordinal types when used in compile-time expressions. 7. Two new statements named SELECT and SELECTONE have been added. Patterned after the BLISS statements of the same name, the SELECT and SELECTONE statements look much like the CASE statement except for one very powerful feature. Namely, the labels of a SELECT or SELECTONE statement can be run-time expressions as opposed to the CASE statement which only allows constant expressions. The syntax for the SELECT statement is: SELECT select-selector OF [[{{select-label-list},...: statement};...]] [[ [[OTHERWISE {statement};...]] 1-3 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES [[ALWAYS {statement};...]] ]] [[;]] END where 'select-label-list' is expression [[.. expression]] The expressions in the 'select-label-list' can be full run-time expressions. When two expressions are provided as a lower and upper bound, they must be of the same ordinal type. There is no check to ensure that the lower bound expression is less than or equal to the upper bound expression. If that occurs then there are simply no values of the select-selector that can be in the range. The SELECT statement checks to see if the value of the select-selector is contained in the select-label-list. If so, then the corresponding statement is executed. The select-label-lists are checked in the same lexical order that they appear in the source file. The same value can appear in more than one select-label-list. The optional OTHERWISE and ALWAYS clauses can appear in either order. The ALWAYS clause is always executed. The OTHERWISE clause is executed only if none of the prior statements (except for an optional ALWAYS statement) have been executed. The syntax for the SELECTONE statement is almost identical but does not provide for an ALWAYS clause. SELECTONE select-selector OF [[{{select-label-list},...: statement};...]] [[ OTHERWISE {statement};... ]] [[;]] END Unlike the SELECT statement, the SELECTONE statement stops processing after it executes the first statement that corresponds to a select-label-list that contains the select-selector value. While the SELECT/SELECTONE statements can be used similar to the CASE statement. For example, SELECT expression OF 1: WRITELN('ONE'); 2: WRITELN('TWO'); OTHERWISE WRITELN('not ONE or TWO') 1-4 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES END a more subtle (and powerful) form uses the Boolean constant 'TRUE' as the select-selector. For example, SELECTONE True OF expression < 10: WRITELN('Value is small'); expression < 100: WRITELN('Value is medium'); expression < 1000: WRITELN('Value is big'); OTHERWISE WRITELN('Value is too big'); END SELECTONE True OF expression = "AAA": writeln('String is AAA'); expression = "BBB": writeln('String is BBB'); expression = "CCC": writeln('String is CCC'); OTHERWISE writeln('unknown string'); END FOR i := 1 TO 10 DO SELECT True OF ODD(i): WRITELN('value ',i:1,' is odd'); (i MOD 3) = 0: WRITELN('value ',i:1,' is also a multiple of 3'); END; 1.2.2 Differences Between OpenVMS Alpha And OpenVMS I64 HP Pascal for OpenVMS I64 defaults to IEEE floating whereas HP Pascal for OpenVMS Alpha defaults to VAX floating. If you want or require VAX floating support on OpenVMS I64, you must use the /FLOAT=G_FLOAT or /FLOAT=D_FLOAT DCL qualifier (or the [FLOAT] module-level attribute). When using VAX floating on OpenVMS I64, the compiler generates extra code to convert the VAX floating value to IEEE floating, perform the desired operation, and convert the value back to VAX floating. While this model is intended to be invisible and identical to the VAX floating support on OpenVMS Alpha, the inherent differences between the floating point formats can produce minor differences in floating point computations. In addition, programs that try to interpret random data as floating values might generate floating inexact or floating invalid faults on OpenVMS I64 where they didn't exist on OpenVMS Alpha. 1-5 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 1.2.3 Known Problems In HP Pascal V6.0 For OpenVMS I64 These problems include: 1. When unwinding routines that have open files, the Pascal RTL does not automatically close the files like it does on OpenVMS Alpha and OpenVMS VAX. This will be corrected in a future release of OpenVMS I64. 2. The compiler and run-time libraries does not always raise an error when attempting to take the logarithm of a negative number. This will be corrected in a future release of OpenVMS I64. 3. DEBUG support is limited. - A few programs will generate internal compiler errors when compiling with /DEBUG. In those cases, the only workaround is to remove the /DEBUG qualifier. However, these programs should be rare. Most programs will compile with /NOOPT/DEBUG. - Some Pascal variables cannot be examined or deposited correctly in the debugger. Some will generate internal errors in the debugger or display incorrect data. Please exercise caution when using the debugger with Pascal. We are actively working on improving the debug support for the next release of OpenVMS I64. Thank you for your patience in this area. 1.3 HP Pascal Web Page You can find the HP Pascal home page at http://h71000.www7.hp.com/commercial/pascal/pascal_index.html Please visit the web site and register with us via the "Pascal Feedback" button. By registering with us, we can send out updates on future HP Pascal releases as well as getting your feedback on HP Pascal features and future directions. 1.4 Debug Support For Schema Types HP Pascal for OpenVMS Alpha and OpenVMS I64 has debugging support for schema types. When /DEBUG is used along with schema types, the compiler generates helper routines that will be used by the debugger 1-6 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES to compute various pieces of run-time information it needs to examine or deposit into schematic variables. These routines have names that include "%BOUND", "%STRIDE", "%SIZE", and "%OFFSET" strings in their names. They should not impact the user program other than the fact that these routines are included in the generated code. We strongly encourage you to use /NOOPTIMIZE along with /DEBUG when debugging code that contains schema types. We have tested debugging with optmizations enabled, but the impact of optimization techiques make debugging difficult. This support for debugging schema types exposes several bugs in the existing debugger especially on OpenVMS I64. If you try to debug schema types with the existing debugger, you may encounter wrong answers or debug errors. We are actively working on these problems for future releases of HP Pascal and OpenVMS I64. Thank you for your patience in this area. For example, program test; type subr(l,u:integer) = l..u; var a : [volatile] integer value 3; b : [volatile] integer value 3; r : record f5_1 : array [subr(a,b)] of integer; case f5_tag : integer of 1 : (f5_case_1 : integer); 2 : (f5_case_2 : boolean); end; { case } begin r := zero; r.f5_tag := 2; end. You can examine variable R as an entire variable, but if you ask for R.F5_CASE_1 or R.F5_CASE_2, the debugger tries to examine the wrong virtual address. For example, DBG> ex r TEST\R F5_1 [3]: 0 F5_TAG: 2 Variant Record with Tag Value: 2 F5_CASE_2: False 1-7 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES DBG> ex r.f5_case_1 %DEBUG-E-NOACCESSR, no read access to address 000000007F46E0FC DBG> ex r.f5_case_2 %DEBUG-E-NOACCESSR, no read access to address 000000007F46E0FC The debug engineering team is aware of this problem. 1.5 Limited Support For 64-bit Pointer Types HP Pascal for OpenVMS Alpha and OpenVMS I64 has been enhanced to provide support for 64-bit pointers. By using the [QUAD] attribute on pointer types, the compiler will create and use a 64-bit pointer instead of a 32-bit pointer. The NEW and DISPOSE procedures have been enhanced to work with 64-bit pointers. 1.5.1 Language Features Not Supported With 64-bit Pointers Several language features are not supported with 64-bit pointers. These features are: o Base types of 64-bit pointers cannot contain file types. o The READ, READV, and WRITEV builtin routines cannot read or write into variables accessed via 64-bit pointers. For example, the following code fragment will be rejected by the compiler var quad_ptr : [quad] ^integer; begin new(quad_ptr); read(quad_ptr^); end you can work-around this by using a temporary variable, as in, var quad_ptr : [quad] ^integer; tmp : integer; begin new(quad_ptr); read(tmp); quad_ptr^ := tmp; end 1-8 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES o Since HP Pascal only understands 32-bit descriptors as defined by the OpenVMS Calling Standard, any HP Pascal construct that relies on descriptors is not supported for variables accessed via 64-bit pointers. The features rejected for 64-bit pointers are: - The use of %DESCR or %STDESCR on actual parameter values accessed via 64-bit pointers. For example, you cannot do type s32 = packed array [1..32] of char; var qp : [quad] ^s; begin new(qp); some_routine( %stdescr qp^ ); end; - Passing variables accessed with 64-bit pointers to formal parameters declared with %DESCR OR %STDESCR foreign mechanism specifiers. - Passing variables accessed with 64-bit pointers to conformant array or conformant varying parameters. - Passing variables accessed with 64-bit pointers to STRING parameters. - At run-time, the compiler will generate incorrect code when passing a VAR parameter that is accessed via a 64-bit pointer to a parameter that requires a descriptor. The generated code will build the descriptor with the lower 32-bits of the 64-bit address. We will add a run-time check for this situation in a future release. For example, type s32 = packed array [1..32] of char; var qp : [quad] ^s32; procedure a( p : packed array [l..u:integer] of char ); begin writeln(p); end; procedure b( var p : s32 ); begin a(p); { This will generate a bad descriptor } end; 1-9 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES begin new(qp); b(qp^); end; 1.5.2 Using 64-bit Pointers With System Definition Files The STARLET Definition files for Pascal have not been enhanced to reflect the new 64-bit pointer support in the compiler. For routines that have parameters that are 64-bit pointers, the Pascal definition will use a record type that is 64-bits in size. The definition files do not know about either the INTEGER64 datatype or 64-bit pointers. We will try to improve the definition files in a future release. However, you can still use these new routines from HP Pascal. By using a foreign mechanism specifier (ie, %IMMED, %REF, %STDESCR, and %DESCR) on an actual parameter, you can override the formal definition inside of definition files. For example, here is an example of calling lib$get_vm_64 using %ref to override the definition from PASCAL$LIB_ROUTINES.PEN. Note, that starting with HP Pascal V5.9, the NEW predeclared routine will call lib$get_vm_64 directly. However, this example is demonstrating how to override any system parameter definition using 64-bit pointers. [inherit('sys$library:pascal$lib_routines')] program p64(input,output); const arr_size = (8192 * 10) div 4; ! Make each array be 10 pages type arr = array [1..arr_size] of integer; arrptr = [quad] ^arr; var ptr : arrptr; ptrarr : array [1..10] of arrptr; i,j,stat : integer; sum : integer64; ! PASCAL$LIB_ROUTINES.PAS on a V7.1 system contains ! the following definitions for LIB$GET_VM_64 ! !type ! $QUAD = [QUAD,UNSAFE] RECORD 1-10 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES ! L0:UNSIGNED; L1:INTEGER; END; ! $UQUAD = [QUAD,UNSAFE] RECORD ! L0,L1:UNSIGNED; END; ! lib$routines$$typ4 = ^$QUAD; ! ![ASYNCHRONOUS] FUNCTION lib$get_vm_64 ( ! number_of_bytes : $QUAD; ! VAR base_address : [VOLATILE] lib$routines$$typ4; ! zone_id : $UQUAD := %IMMED 0) : INTEGER; EXTERNAL; ! ! Note that the BASE_ADDRESS parameter is a 64-bit pointer ! that will be returned by LIB$GET_VM_64. The definition ! incorrectly declared it as a pointer to a record that is ! quadword sized. ! begin ! Allocate memory with lib$get_vm_64. The definition of ! lib$get_vm_64 declares the return address parameter as ! a quadword-sized record since it doesn't have sufficient ! information to generate a INTEGER64 or other type. ! ! Use an explicit '%ref' foreign mechanism specifier to ! override the formal parameter's type definition and pass ! our pointer to lib$get_vm_64. ! writeln('arr_size = ',arr_size:1); for i := 1 to 10 do begin stat := lib$get_vm_64( size(arr), %ref ptrarr[i] ); if not odd(stat) then begin writeln('Error from lib$get_vm_64: ',hex(stat)); lib$signal(stat); end; writeln('ptrarr[',i:1,'] = ',hex(ptrarr[i])); end; ! Read/write all the memory locations to get some page faults ! writeln('Initialize all memory'); for i := 1 to 10 do for j := 1 to arr_size do ptrarr[i]^[j] := i + j; sum := 0; writeln('Add up all memory in reverse direction'); for i := 10 downto 1 do for j := arr_size downto 1 do 1-11 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES sum := sum + ptrarr[i]^[j]; writeln('Sum of array contents = ',sum:1); end. 1.6 Creating Files With RMS "Undefined" Record Types On OpenVMS I64, object files are created with the RMS record type of "undefined" to correctly describe these files as pure byte stream files. Prior to that, the "undefined" record type was not commonly seen on OpenVMS systems. The HP Pascal OPEN predeclared routine does not have direct support to say "RECORD_TYPE := UNDEFINED". However, you can create a file with "undefined" record type using a USER_ACTION routine. A new example file (SYS$SYSROOT:[SYSHLP.EXAMPLES.PASCAL]CREATE_UDF_FILE.PAS) has been included in the HP Pascal kit that shows how to do it. 1.7 Using The POS Attribute With Natural Alignment The description of the POS attribute does not describe the interaction with using the POS attribute with field types whose natural preferred alignment conflicts with the bit position specified. Prior to V5.9-103, the compiler would issue an error if the specified bit position conflicted with the type's preferred alignment. For example, type uw = [word] 0..65535; uw_array = array [1..2] of uw; uw_rec = packed record f1 : char; f2 : [pos(8)] uw_array; end; The compiler would issue a POSALIGNCON error message for the POS attribute eventhough the compiler would have placed the field on that boundary by default if the POS attribute was not specified. The compiler was confused by the implicit natural alignment of each word element of the uw_array and rejected any POS attribute that did not specify a word-aligned bit offset. The compiler's check has been relaxed to allow such POS attributes on fields of PACKED records that do not have explicit alignment 1-12 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES specifications. The description of the POS attribute will be expanded to include the additional rule: o In an unpacked array, the specified bit position must not conflict with the default preferred alignment of the field's type. 1.8 Using $FILESCAN With HP Pascal The definition of $FILESCAN in STARLET.PAS declares the 1st parameter as a value parameter accepting a string expression. The system service returns pointers back into this parameter via the item list parameter. When a string variable is passed to this first parameter, the compiler may make a local copy of the string before calling the system service. The system service will then return addresses back into this temporary copy of the string on the stack. As the program executes further, this stack space is reused and the returned pointers become useless. This behavior wasn't apparent on OpenVMS VAX systems since HP Pascal would generally not make a copy in that environment. If the actual parameter passed to $FILESCAN is a PACKED ARRAY OF CHAR variable, then you can workaround this problem by using the %STDESCR foreign mechanism specifier on the actual parameter. If the actual parameter is a VARYING OF CHAR or STRING, you will have to build your own local descriptor referencing the .BODY of the VARYING OF CHAR or STRING and pass that descriptor to $FILESCAN using the %REF foreign mechanism specifier. In both cases, you need to add VOLATILE to the variable being passed so the compiler knows that the variable must remain active after $FILESCAN has been called. This is needed since the code will be accessing pieces of the variable via the returned addresses. 1.9 Using Condition Handlers That Return SS$_CONTINUE In HP Pascal, condition handlers can do one of the following things after doing whatever is appropriate for the error: 1. Use a non-local GOTO to transfer control to a label in an enclosing block. 1-13 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 2. Return SS$_CONTINUE if the handler wants the error dismissed and to continue processing. 3. Return SS$_RESIGNAL if the handler wants the system to continue searching for additional handlers to call. 4. Call the $UNWIND system service to establish a new point to resume execution when the handler returns to the system. When an exception occurs, the system calls a handler in the Pascal Run-Time Library that is established by the generated code. This handler in the RTL in turn calls the user's condition handler that was established with the ESTABLISH builtin routine. The RTL's handler contains a check to prevent a user's handler from returning SS$_CONTINUE for a certain class of Pascal Run-Time Errors that could cause an infinite loop if execution was to continue at the point of the error. There are two situations where this check may cause unexpected behavior. The first situation is where the user's handler called $UNWIND and then returned with SS$_CONTINUE. Since the $UNWIND service was called, execution won't resume at the point of the error even if SS$_CONTINUE is returned to the system. However, the RTL's handler isn't aware that $UNWIND has been called and complains that you cannot continue for this type of error. The solution is to return SS$_RESIGNAL instead of SS$_CONTINUE after calling $UNWIND in the user's handler. However, this solution isn't possible if you establish the LIB$SIG_TO_RET routine with the ESTABLISH builtin routine. LIB$SIG_TO_RET is a routine that can be used as a condition handler to convert a signal into a "return to the caller of the routine that established LIB$SIG_TO_RET". Since LIB$SIG_TO_RET returns SS$_NORMAL which in turn is the same value as SS$_CONTINUE, the handler in the Pascal RTL will complain that you cannot continue from this type of error. The solution for this case is to establish your own handler with the ESTABLISH builtin routine that calls LIB$SIG_TO_RET and then returns SS$_RESIGNAL. You cannot establish LIB$SIG_TO_RET directly as a handler with the ESTABLISH builtin routine. The second situation where the RTL's check for SS$_CONTINUE from a user's handler can cause problem is moving code from OpenVMS VAX to OpenVMS Alpha or OpenVMS I64. On OpenVMS VAX, only certain run-time errors were not allowed to return SS$_CONTINUE from a handler. These errors for those associated with the SUBSTR and PAD builtin routines as well as checking code for set constructors. On OpenVMS Alpha and OpenVMS I64, many more 1-14 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES run-time errors are not allowed to return SS$_CONTINUE from a handler. The exact lists of run-time errors which can be continued and which ones cannot be continued has never been provided. The compilers may choose to generate different code in the future which might move an error from one list to the other. We recommend that do you not return SS$_CONTINUE for any Pascal run-time error that is not due to a file operation. 1.10 Known Problems And Restrictions Here is a list of language features that are not yet implemented or do not work as documented in HP Pascal for OpenVMS I64 Systems. 1. UNSIGNED8 and UNSIGNED16 Predeclared Subranges The UNSIGNED8 and UNSIGNED16 predeclared subrange types are documented as being subranges of UNSIGNED. However, they are actually subranges of INTEGER with positive values that correspond to an UNSIGNED subrange of the same size. This subtle distinction in the definition is almost impossible to detect from a program and shouldn't be a problem in the general case. One visible difference is that expressions involving UNSIGNED8 and UNSIGNED16 values are performed with overflow detection enabled (just like any INTEGER expression). So if you multiply the largest UNSIGNED16 value with itself, the operation will produce an overflow where you would not expect an overflow. For example, VAR A,B : UNSIGNED16 VALUE 65535; A := A * B; will produce an integer overflow where you would expect the rules for unsigned arithmetic to produce the value 1. 2. Using Discriminated Schema as Formal Discriminant Types Extended Pascal allows a discriminated ordinal schema type to be subsequently used as the type of a formal schema discriminant. For example, TYPE SUBR(L,U:INTEGER) = L..U; DSUBR = SUBR(expression,expression); SCH1(D:DSUBR) = ARRAY [1..D] OF INTEGER; SCH2(D:DSUBR) = RECORD CASE D OF 1: (F1:INTEGER); 2: (F2:CHAR); 1-15 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES END; HP Pascal does not currently support this construct. 3. Files with Schema Components Extended Pascal allows file components to contain schematic items and therefore provide run-time sized file components. For example, TYPE SUBR(L,U:INTEGER) = L..U; FILE_COMP = ARRAY [SUBR(expr,expr)] OF INTEGER; VAR F : FILE OF FILE_COMP; HP Pascal does not currently support this feature and requires that the component sizes of files be known at compile-time. 4. Using Formal Discriminants Inside Initial State Specifiers Extended Pascal allows the formal discriminant to appear in an initial state specifier in the schema definition. For example, TYPE R(D:INTEGER) = RECORD F1 : INTEGER VALUE D; END; A(D:INTEGER) = ARRAY [1..D] OF INTEGER VALUE [OTHERWISE D]; HP Pascal does not currently support this feature and requires that all initial state values be compile-time expressions. 5. Changing Variants When Selector Is A Discriminant If a formal discriminant is used as a variant tag, it is illegal to change the variant once the variable has been created. For example, TYPE R(D:INTEGER) = RECORD CASE D OF 1: (ONE : INTEGER); 2: (TWO : INTEGER); OTHERWISE (OTHERS : BOOLEAN); END; VAR V : R(1); BEGIN V.TWO := 2; { Is illegal since it changes variants from 1 to 2 } END; 1-16 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES HP Pascal does not currently generate run-time checking code to detect this violation. 6. The AND_THEN and OR_ELSE Boolean operators do not short-circuit when used in constant expressions. All constant expressions currently do full evaluation in a left-to-right order. For example, CONST X = FALSE AND_THEN (1 DIV 0 = 0); This example will currently generate a compilation error instead of correctly definiting the constant X to be the value FALSE. 7. The HP Pascal compiler currently allows you to use the SIZE function on TIMESTAMP variables. As in the case for file variables, these types are abstract objects and the compiler should not permit assumptions about their size to be used. 8. When the buffer variable of a file is passed as a VAR parameter, the allocation size of the formal VAR parameter must match that of the components of the file. Failure to do so will result in an Internal Compiler Error. For example: PROGRAM A; VAR F : PACKED FILE OF 0..65535; G : FILE OF [WORD] 0..65535; PROCEDURE P( VAR I : INTEGER ); EXTERNAL; BEGIN P(F^); { causes an Internal Compiler Error } P(G^); { causes an Internal Compiler Error } END. 9. The LSE templates for the Pascal language are shipped as part of DECset. These templates have not yet been updated to reflect all the new language features added to HP Pascal. 10. The HELP file has undergone extensive revision which included renaming some topic strings. This will cause problems with using the language-sensitive help feature from LSE. 11. Due to an interaction with the OpenVMS Linker and OpenVMS Image Activator, unknown results will occur if a compilation unit places a file variable in a [COMMON] block and then a shareable image is made from the object file. To share data in a shareable image, use environment files or use the [GLOBAL]/[EXTERNAL] attributes. 1-17 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES 12. When using the SYS$SYSTEM:PASCAL$SET_VERSION.COM command file to select older versions of the HP Pascal, the older compiler may issue an error if the /VERSION qualifier is specified. Normally, older compilers will simply ignore any qualifiers that were added after its release. However, due to the implementation of /VERSION, older compilers will issue errors while trying to process other qualifiers. If you receive these errors, do not use /VERSION to determine the older compiler's version. You will need to look in the first line of a listing file or in the ANALYZE/IMAGE output. 13. Jumping into a WITH statement with a GOTO statement may result in an Internal Compiler Error if compiled with /OPTIMIZE. Such programs are illegal in nature as bypassing the prologue of the WITH statement skips around the code that precomputes the address of the record used in the WITH statement. 14. The ALIGNED attribute only allows upto 8192 byte boundaries at present (ie, ALIGNED(13)). Support for larger alignments will be considered for a future release if there is customer demand. 15. Incomplete support for INTEGER64/UNSIGNED64; Currently, the following uses of the INTEGER64/UNSIGNED64 datatypes are unsupported: a) Literals requiring more than 32-bits cannot be used in the declaration section. This implies that you cannot write such things as: CONST BigNum = 12345678912345678; but you CAN write things such as: i64 := 12345678912345678; b) INTEGER64/UNSIGNED64 expressions cannot be used as case selectors or variant record tags. c) Subranges requiring more than 32-bits cannot be declared (since you cannot specify literals large enough to construct them). d) Array index types cannot be INTEGER64/UNSIGNED64 (since you cannot specify subranges of them). e) The predeclared constants MAXINT64 and MAXUNSIGNED64 are not present. However, you can use LOWER(INTEGER64), LOWER(UNSIGNED64), UPPER(INTEGER64), and UPPER(UNSIGNED64) in an executable section to obtain the 1-18 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES same values. f) INTEGER64/UNSIGNED64 types cannot be used in variable typecasts. 16. When debugging programs that contain schema, you must use the /NOOPTIMIZE qualifier on the PASCAL DCL command. If you do not use /NOOPTIMIZE, you might receive incorrect debug information or an Internal Debug Error when manipulating schema. Pointers to undiscriminated schema cannot be correctly described to the debugger at this time since the type of the pointer is dependent upon the value pointed to by the pointer. They are described as pointers to UNSIGNED integers instead. For example, TYPE S(I:INTEGER) = ARRAY [1..I] OF INTEGER; VAR P : ^S; BEGIN NEW(P,expression); END; 1.11 STARLET Definition Files The contents of STARLET.PAS and other definition files provided during the HP Pascal installation are derived or extracted from a file provided by the OpenVMS system. On OpenVMS Alpha systems prior to V8.2, the Pascal files are converted from binary data shipped by OpenVMS (SYS$LIBRARY:STARLETSD.TLB). The Pascal installation extracts the binary information, converts it to Pascal source files, compiles them, and places the precompiled environment files on the system. The SYS$LIBRARY:STARLETSD.TLB file is not used once the installation is finished. On OpenVMS I64 and OpenVMS Alpha V8.2 and later, the Pascal files are produced during the OpenVMS build process and are shipped compressed inside SYS$LIBRARY:STARLETPAS.TLB. The Pascal installation extracts the Pascal source files, compiles them, and places them and the precompiled environment files on the system. The SYS$LIBRARY:STARLETPAS.TLB file is not used once the installation is finished. Programs that provide their own Pascal version of system constants, data structures, or entry points may have to be modified if these 1-19 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES items are provided by the OpenVMS system in the future. For example, the CLI$_ constants are now been provided by the system. Finally, be aware that OpenVMS VAX, OpenVMS Alpha, and OpenVMS I64 systems may not provide the exact same set of definitions. 1.12 Compiling For Optimal Performance The following command line will result in producing the fastest code from the compiler. PASCAL /NOZERO_HEAP /OPTIMIZE /NOCHECK /ASSUME=NOACCURACY_SENSITIVE You may also want to use the performance flagger ( /USAGE=PERFORMANCE ) to identify datatypes that could be modified for additional performance. Note that the is another level of optimization (LEVEL=5) above the default level of 4. However, from our experience, /OPTIMIZE=LEVEL=5 provides little benefit to most Pascal program and may actually result in slower code than level 4. Please note that /ASSUME=NOACCURACY_SENSITIVE may cause programs that depend on exact mathematical results to produce incorrect answers. The remaining qualifiers should not impact the results of programs. 1.13 Problems Corrected Since Last Release Of HP Pascal o The compiler would generate incorrect code for string length checking operations. It would not generate the needed sign-extend instruction so if the fetched length was next to memory with non-zero values in it, the resulting checking code would see an incorrect length. This problem has been fixed. o The compiler would generate incorrect code for the SUBSTR predeclared reoutine that would produce spurious run-time errors. Most of the errors would occur when the source was compiled with the /ALIGN=VAX/ENUM=BYTE qualifiers, but could also have occurred in other situations. These problems have been fixed. 1-20 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES o An Internal Compiler Error occurred when using the /DEBUG qualifier with a source file that used the C_STR_T predeclared type. This problem has been fixed. o An Internal Compiler Error occurred when trying to typecast from a VAX floating point type to an integer. This problem has been fixed. o An Internal Compiler Error occurred when compiled certain schematic records with the /DEBUG qualifier. The compiler now generates correct debug information, but certain versions of the symbolic debugger cannot correctly examine these records. The debugger will be corrected in a future release of OpenVMS. o Improve the debug information for subrange types used as array bounds. Previously the compiler generated an extra subrange ELF record when it only should have generated one. This problem has been fixed. o The V5.9 compiler contained a regression such that an Internal Compiler Error would occur in the SEF_VARIABLE_DEPENDENCIES compiler routine when optimization is enabled for programs that contain certain complicated loop constructs. This problem has been fixed. o An Internal Compiler Error occurred when generating debug information for certain forward pointer declarations. This problem has been fixed. o An Internal Compiler Error would sometimes occur when trying to inherit an environment file compiled on another OpenVMS platform. The compiler would generate the correct ENVWRGCMP error message but would somethings generate an Internal Compiler Error as well. This problem has been fixed. o The compile-time check for using the POS attribute with bit positions that conflicted with the field's alignment has been modified to not complain when the specified bit offset conflicted with the field's "preferred" alignment. o The compiler would sometimes save an intermediate boolean value in register pr15 and then call a routine that would destroy that register. The compiler now understands not to 1-21 HP PASCAL V6.0-107 FOR OPENVMS I64 SYSTEMS RELEASE NOTES use pr15 in those situations. o The debug information produced for enumerated types was incorrect. The compiler produced two different debug descriptions using the same name. This problem has been fixed. o The output from /SHOW=STRUCTURE_LAYOUT placed a closing parenthesis on the wrong line when formatting nested variant records. This problem has been fixed. The output from /SHOW=STRUCTURE_LAYOUT will now insert a line break when displaying an inherited typename when listing the module name would have generated a line longer than 132 characters. o Add the new /ASSUME=BYTE_ALIGNED_POINTERS DCL option to tell the compiler to assume that pointers point only to byte-aligned data, not to quadword-aligned data. By default, the compiler assumes that pointers point to memory that has been allocated using the NEW predeclared routine. NEW returns memory that is at least quadword-aligned. o The compiler would generate code that caused an alignment fault when performing an initial state assignment to an 8 byte record that used 0 (or ZERO) as the initial state value. This problem has been fixed. The generated code will no longer generate an alignment fault, but isn't as efficient as possible. We intend to improve this in the near future. o Add the following new features: - Enhance "IN" and "NOT IN" operators - Enhance SUBSTR predeclared procedure - Allow BIN, OCT, HEX, DEC, and UDEC in constant expressions - Add SELECT and SELECTONE statements - Add new floating directives For more information on these new features, see the sections earlier in the release notes. 1-22