CHAPTER 1 BLISS-32 V4.7 RELEASE NOTES This document contains information about the VAX BLISS-32 V4.7-999 compiler. This compiler is for internal use only. It is organized into four chapters: o Chapter 1 provides an overview of this file. o Chapter 2 describes the changes since the last release of BLISS-32, V4.6-902. o Chapter 3 describes incompatibilities and known deficiencies in this version. o Chapter 4 describes how to install the BLISS-32 compiler. 1-1 CHAPTER 2 MAINTENANCE CORRECTIONS FOR BLISS-32 This chapter describes all changes made since the last release (V4.6-902). 2.1 BUG FIXES The following bugs have been fixed. o Incorrect code could be generated for compares of fields with similar position, size and extension attributes, as in the example below: .(.p1)<0,1> EQL .(.p2)<0,1> o Incorrect code could be generated for SUBM when the destination operand was the same as the first source operand, as in the example below: SUBM(4, BLK[3], X, BLK[3]) o An error in the compiler caused it to look in the wrong directory for the PDF (Program Design Facility) comment processing routines. This error only showed up when invoking the compiler with /DESIGN or /DESIGN=COMMENTS to process comments for PDF. The compiler now looks in the SYS$LIBRARY directory, instead of PDS$PUBLIC. o Very large BLISS programs could get an internal compiler error during the Final phase. It is unlikely that any human-written program will ever be this big -- the program which found this problem was machine-generated. 2-1 MAINTENANCE CORRECTIONS FOR BLISS-32 o When compiling very large programs (over 65000 bytes of instructions for a routine) the compiler could mistakenly truncate the offset of a JMP instruction to a word. It would then issue a truncation warning. o Very small programs on very fast machines could get a divide by zero when the number of lines per CPU minute was calculated. o ENABLE declarations may only appear in the outermost block of a routine. Although this restriction has always been in the Language Reference Manual, it was not fully enforced in the past. o The restrictions on ENABLE listed in section 13.3.2 of the BLISS Language Reference Manual were not being enforced. Violations of those restrictions now generate the warning message "Linkage conventions are incompatible with ENABLE declaration." o Declarations of global registers which did not specify a register number could lead to internal errors when a call using a linkage with that global register was being processed: linkage gg = call : global( g = 5 ); forward routine call_me : gg; : routine do_call = begin global register g; ! No register number specified. call_me(); ! Used to cause internal error. The user now gets only the warning message for the missing register number. o BLISS incorrectly stored a fullword into non-fullword variables listed as output parameters. This could over-write other variables: LINKAGE FOO = JSB (; REGISTER = 1); EXTERNAL ROUTINE BAR : FOO NOVALUE; OWN X : WORD, Y : WORD; BAR(; X ); ! Generated a fullword move ! and modified Y as well. 2-2 MAINTENANCE CORRECTIONS FOR BLISS-32 o The compiler did not issue a warning when a valued routine was declared as using a user-defined linkage which preserved the value-return register: LINKAGE L = CALL : PRESERVE(0); ROUTINE R : L = 1; ! Should get a warning A similar warning is already given when the value-returned register is declared NOTUSED. o When a EXTERNAL LITERAL was also declared as a GLOBAL LITERAL in the same module, correctly matching range attributes were incorrectly diagnosed. o If a structure body contained a general structure reference, and an access formal of the structure being defined was an access actual of the general structure reference, the results were unpredictable for certain structure references. 2-3 MAINTENANCE CORRECTIONS FOR BLISS-32 2.2 NEW FEATURES The following features have been added. o A new command-line qualifier has been added to allow new reserved words to be added in an upward-compatible manner. /SYNTAX_LEVEL=level To compile with the original set of reserved words (see Appendix A of the LRM) set the level to 1; to compile with the words QUAD, SHARED, EXTERNAL_NAME, GRANULARITY, ALIAS and NOCHECK_ALIGNMENT as reserved words (and thus having their specific BLISS meaning), set the level to 2. Level equal to 1 is the default. QUAD is an illegal allocation-quantity in BLISS-32. GRANULARITY and SHARED are unimplemented. ALIAS, EXTERNAL_NAME and NOCHECK_ALIGNMENT are described elsewhere in this document. o The predeclared structure BLOCK_BYTE has been added. This structure is functionally equivalent to BLOCK[,BYTE]. The definition is STRUCTURE BLOCK_BYTE[O,P,S,E; BS] = [BS] (BLOCK_BYTE + O); BLOCK_BYTE is like BLOCK as regards the BLOCK_ALIGNMENT qualifier. o BLISS now gives the informational message "Numeric literal overflow" when it encounters numeric literals that cannot be represented in a fullword. o BLISS now gives a better error message when output parameters are specified for machine-specific built-ins which do not expect output parameters. o The error message for missing case label values has been improved to list the values that are missing. o An informational is now given for DECRU to 0, indicating that it is an infinite loop. 2-4 MAINTENANCE CORRECTIONS FOR BLISS-32 o The ALIAS attribute has been added for compatibility with other dialects. ALIAS indicates that variables that may change due to hidden effects of routine calls and indirect assignments. In this compiler, it is equivalenced to VOLATILE. In order for the compiler to recognize the ALIAS attribute, /SYNTAX_LEVEL=2 must be specified. o BLISS has added new compiler-state lexicals and expanded old ones to support new dialects. o %BLISS recognizes BLISS32M, BLISS32E, BLISS64E and BLISS32V. o %BLISS32M, %BLISS32E, %BLISS64E and %BLISS32V have been added. BLISS32 refers to both VAX, MIPS and Alpha 32-bit compilers and BLISS languages. BLISS32M refers to MIPS-specific features. BLISS32E refers to Alpha-specific features. BLISS32V refers to VAX-specific features. The %BLISS lexical function now accepts unknown arguments. This will allow backward compatibility of code written for future dialects. o Two new lexical functions, %HOST and %TARGET, have been added to ease porting BLISS programs to other targets. Their take as arguments one or two keywords representing the host or target architecture and operating system. %HOST returns 1 if its arguments represent the system on which the compiler is running, and 0 otherwise. %TARGET returns 1 if its arguments represent the system for which the compiler generates code, and 0 otherwise. The following keywords are recognized by these functions. For compatibility with future compilers, unrecognized keywords will not generate a diagnostic, but will cause the functions to return 0. Architecture Operating System VAX VMS MIPS ULTRIX ALPHA UNIX OSF WNT o There are three new lexical functions that return strings containing the compiler's state. %MODULE returns the current module name. %ROUTINE returns the current routine name. %IDENT returns the current module ident. 2-5 MAINTENANCE CORRECTIONS FOR BLISS-32 o The LANGUAGE switch will now accept BLISS32V, BLISS32M, BLISS32E, and BLISS64E as values. It is important to note that BLISS32 means the same as BLISS32V in the LANGUAGE switch. It does not mean all 32-bit dialects as it does in the %BLISS32 predeclared macro or the %BLISS(BLISS32) lexical function. The reason for this is that changing BLISS32 to mean all 32-bit could break already existing programs. When there was only one 32 bit dialect (BLISS-32), LANGUAGE(BLISS32) meant only do transportabilty for BLISS-32. If we changed LANGUAGE(BLISS32) to mean all 32-bit dialects, transportability checking would be done for BLISS-32 and BLISS-32M. This could cause working programs to break (or at least get checking errors). o /LANGUAGE has been added as a command line qualifier. Its behavior is identical to the module switch LANGUAGE. o Harmless duplication of attributes no longer gets a warning message. The message can be re-enabled by use of /CHECK=REDECLARE. The attributes which can be so duplicated are VOLATILE, NOVALUE and WEAK. o Re-declaration of a GLOBAL REGISTER in a routine's linkage can now generate an informational message if requested with the qualifier /CHECK=REDECLARE. LINKAGE L3 = CALL : GLOBAL( THREE = 3 ); ROUTINE A : L3 = BEGIN EXTERNAL REGISTER THREE; ! Normal case, uses the R3 : ! declared global in its caller. ROUTINE B : L3 = BEGIN GLOBAL REGISTER THREE = 3; ! Other case, creates a new global. : ! Not the R3 from its caller. Please note that the re-declaration is not a bug, unless you really meant to use EXTERNAL REGISTER. More detail on the use of global registers is in the Language Reference Manual, in section 13.7. o The limit on the number of actual parameters has been raised from 64 to 256. 2-6 MAINTENANCE CORRECTIONS FOR BLISS-32 o The attribute EXTERNAL_NAME and the new qualifier /NAMES (keywords UPPERCASE and LOWERCASE) have been added to support mixed-case names. In order for the compiler to recognize the EXTERNAL_NAME attribute, /SYNTAX_LEVEL=2 must be specified. The EXTERNAL_NAME attribute can be applied to the following declarations: GLOBAL, EXTERNAL, GLOBAL ROUTINE, EXTERNAL ROUTINE, GLOBAL LITERAL, EXTERNAL LITERAL, GLOBAL BIND, GLOBAL BIND ROUTINE. The string specified by this attribute is used as the external name for the linker. THE EXTERNAL_NAME attribute treats its parameter as the %STRING function does. The /NAMES command line qualifier that can be used to force external names to upper or lower case. The qualifier only affects external names which do not have the EXTERNAL_NAME attribute. It defaults to /NAMES=UPPERCASE or upper case names. /NAMES=LOWERCASE can be used to generate lower case names. The name in the object file, printed in the listing records is the modified or external name. The name as described to the debugger is still the internal name. Please note that BLISS makes no promises about the treatment of lowercase names by VMS services, such as the librarian or the linker. Examples of the use of the EXTERNAL_NAME attribute follow: GLOBAL ! Inside the module, the global X X : EXTERNAL_NAME('xna') ! is referenced by the name 'X'. INITIAL (2); ! Outside the module, the name 'xna' ! has to be used. EXTERNAL ! Other string functions can be used Y : EXTERNAL_NAME(%CHAR(1)); ! inside the EXTERNAL_NAME attribute. ! In this case, the external name of ! 'Y' would be control-A. o A new CHECK option, /CHECK=[NO]ALIGNMENT, has been added. When /CHECK=ALIGNMENT is specified, the compiler now checks the alignment of field references and these declarations: EXTERNAL, GLOBAL, LOCAL, STACKLOCAL, OWN, MAP, BIND, GLOBAL BIND. A warning level message is issued when the compiler can determine that a declaration or field reference is poorly aligned. An informational message is issued when a data declaration is well aligned by coincidence (i.e. the alignment attribute is less than the default, but the segment happens to fall on the proper boundary). The default is no alignment checking. 2-7 MAINTENANCE CORRECTIONS FOR BLISS-32 o The following on-off switches have been added: [NO]CHECK_INITIAL Equivalent to /CHECK=[NO]INITIAL. [NO]CHECK_ALIGNMENT Equivalent to /CHECK=[NO]ALIGNMENT. [NO]CHECK_FIELD Equivalent to /CHECK=[NO]FIELD. [NO]CHECK_OPTIMIZE Equivalent to /CHECK=[NO]OPTIMIZE. [NO]CHECK_REDECLARE Equivalent to /CHECK=[NO]REDECLARE. [NO]CHECK_SHARE Equivalent to /CHECK=[NO]SHARE. These switches are available both in the module header and in the SWITCHES statement. o The ALIGN and VOLATILE attributes can now be placed between REF and the structure name in data declarations. Placing them there indicates that the pointed-to structure (and not the pointer) has those attributes. Examples: LOCAL ptra: REF VOLATILE BLOCK, ptrb: REF ALIGN(0) BLOCK; Both ptra and ptrb have default alignment and are not volatile. The BLOCK pointed to by ptra is volatile, and the BLOCK pointed to by ptrb is byte-aligned. If these attributes are placed either before REF or after the structure name, the behavior is unchanged from previous BLISS compilers: ALIGN applies to the pointer only (not the pointed-to structure), and VOLATILE applies to both the pointer and the pointed-to structure. o The ALIGN attribute is now allowed on EXTERNAL, BIND, and GLOBAL BIND declarations. On these declarations, it indicates the expected alignment. 2-8 MAINTENANCE CORRECTIONS FOR BLISS-32 o Built-in functions for dynamic condition handlers are now implemented. ESTABLISH(handler) is equivalent to .FP = handler. REVERT() is equivalent to .FP = 0. ESTABLISH and REVERT may not be used in the same routine as ENABLE. o Attributes have been added to field declarations. The supported attributes are VOLATILE and NOCHECK_ALIGNMENT. In order for the compiler to recognize the NOCHECK_ALIGNMENT attribute, /SYNTAX_LEVEL=2 must be specified. All stores and fetches of fields with the VOLATILE attribute are treated as VOLATILE accesses. If a field has the NOCHECK_ALIGNMENT attribute, /CHECK=ALIGNMENT does not generate alignment diagnostics for stores and fetches that use that field name. Example: FIELD foo= SET foo1 = [0,0,32,0] : VOLATILE, foo2 = [5,0,16,0] : NOCHECK_ALIGNMENT TES; o The new storage-class INITIAL has been added. INITIAL storage is used by the compiler to initialize non-static variables that have the INITIAL or PRESET attribute. This data used to be allocated in the PSECT associated with the PLIT storage-class. This presented a problem when initial values were relocatable and the PLIT PSECT was supposed to be shareable. The default name for the INITIAL PSECT is $INITIAL$. It has the same attributes as the default PLIT PSECT. Please note that you may get new truncation errors at link time for data that used to be put in the PLIT PSECT and is now put in the INITIAL PSECT. These errors can be avoided by appropriate use of the ADDRESSING_MODE switch. | This new behavior can be disabled by using the command line qualifier | /NOINITIAL_PSECT. Its complement (the default) is /INITIAL_PSECT. o A warning is now given when a relocatable expression is put in a | shareable PSECT for the PLIT or INITIAL storage-class. This warning | can be disabled by using the command line qualifier /CHECK=NOSHARE or | the NOCHECK_SHARE switch. The default is /CHECK=SHARE. 2-9 MAINTENANCE CORRECTIONS FOR BLISS-32 o The restriction in section 12.4.2 of the BLISS Language Reference Manual on assignments to routine formals has never been enforced in VAX BLISS. BLISS now commits to generating "reasonable" code for such assignments, though they are still illegal given the rules of the VAX calling standard, as that standard gives ownership of the argument list to the calling routine, not the called routine. To detect assignments to formals, use /CHECK=REDECLARE to detect the implicit re-declaration of a formal as a locally-owned data-segment. The following warning message is given: Assignment to formal parameter is illegal 2-10 CHAPTER 3 INCOMPATIBILITIES, KNOWN DEFICIENCIES AND DOCUMENTATION ERRORS This chapter describes incompatibilities, known compiler deficiencies and documentation errors. 3.1 INCOMPATIBILITIES The format of BLISS library files has changed. All library files must be recompiled. 3.2 KNOWN DEFICIENCIES PROBLEM: The debug symbol table for routines with JSB linkages is not generated correctly. Specifically, the addresses of parameters and locals on the stack are correct only at routine entry, since they are given in terms of SP, whose value may change. SOLUTION: At routine entry, use the debugger's DEFINE command to define a symbol as the current address of the variable. Example: DBG> EVALUATE X DBG> DEFINE X = \ 3-1 INCOMPATIBILITIES, KNOWN DEFICIENCIES AND DOCUMENTATION ERRORS KNOWN DEFICIENCIES PROBLEM: The following code fragment: d = 0; ..... WHILE .d NEQ 0 DO BEGIN .... x = 66 / .d; ! Assume "d" never written ... IF .y THEN EXITLOOP END will cause a zero-divide exception during execution when compiled with normal optimization. The compiler believes that the expression "66/.d" is loop invariant and moves the computation out of the loop. SOLUTION: In this particular case, the expression can be rewritten as: WHILE 1 DO BEGIN ..... IF .d EQL 0 THEN EXITLOOP; .... x = 66 / .d; ..... END; In this case, the expression cannot be moved out of the loop. 3-2 INCOMPATIBILITIES, KNOWN DEFICIENCIES AND DOCUMENTATION ERRORS KNOWN DEFICIENCIES PROBLEM: Incorrect code generated for structure definitions of the form: STRUCTURE BAD[I,P,S]= [%UPVAL] (IF .I THEN BAD ELSE BAD + .BAD<16,16>); OWN X: BAD[]; LOCAL T; T = .X[.T,0,12]; "X" is loaded into a register in the THEN-branch, but the ELSE-branch uses the register without loading it. SOLUTION: This is the result of a design flaw in the way structure references are expanded. BLISS semantics guarantee that a structure actual-parameter is evaluated only once. This is implemented by treating the first occurrence of a structure formal as if it were a BIND declaration. The other occurrences of the structure formal are then treated as if they were uses of the "imaginary" bind-name. This choice of implementation fails when the first occurrence of the structure formal is in conditional flow. The problem can be avoided by ensuring that the first occurrence of each formal is outside of conditional flow. The example structure should be written as: STRUCTURE GOOD[I,P,S] = [%UPVAL] (GOOD; IF .I THEN GOOD ELSE GOOD + .GOOD<16,16>); Note that the "structure-name" is the zeroth structure formal parameter. The formals "I", "P", and "S" are already outside of conditional flow, so they are processed correctly. This change will cause the compiler to use slightly more memory, but the resulting code will be correct. There also should be no reduction in optimization. Be aware that no problem will occur when the conditional flow is constant folded at compile time, or when there is no conditional flow in the structure body. 3-3 INCOMPATIBILITIES, KNOWN DEFICIENCIES AND DOCUMENTATION ERRORS KNOWN DEFICIENCIES PROBLEM: If uninitialized variable checking is in effect, the compiler occasionally generates spurious messages when a variable is initialized in one branch of an IF, CASE, or SELECT in a loop and then referenced in another. For example: LOCAL X, FIRST_TIME,...; FIRST_TIME = 1; WHILE condition DO BEGIN IF .FIRST_TIME THEN X = 0 ELSE X = .X + 1; FIRST_TIME = 0; . . . END; The compiler will report that X is uninitialized in "X = .X + 1". SOLUTION: The simplest and best solution is to initialize such variables before they appear in the loop. You can do this with an assignment or by using an INITIAL attribute on the variable declaration. You can also suppress uninitialized variable messages by using the /CHECK=NOINIT qualifier on the compiler command line. 3.3 DOCUMENTATION ERRORS o In the description of the CMPC5 BUILTIN in the User Manual, FILLA is referred to as the "address of a word." It should be "address of a byte." o In the Language Reference Manual's Appendix D, CVTRDH and CVTRGH are listed as builtin functions for BLISS-32. Neither function exists. 3-4 CHAPTER 4 HOW TO INSTALL BLISS-32 V4.7 This chapter describes the installation procedures for the VAX-11 Bliss-32 Version 4.7 compiler. You should read this chapter completely before beginning the installation. 4.1 INSTALLATION PROCEDURE To install Bliss-32, proceed as follows: 1. Log in under the privileged system manager's account. Since this installation procedure will recompile STARLET.REQ and LIB.REQ (if present in [SYSLIB]), this account should have a large working-set limit (500 to 1000 pages is recommended) to insure that the installation proceeds quickly. Issue the command: $ @SYS$UPDATE:VMSINSTAL BLS32047 TLE::BLS32$V47_VMS5 (To install in a system root other than the root of the running system, you can use the following alternative command: $ @SYS$UPDATE:VMSINSTAL BLS32047 TLE::BLS32$V47_VMS5 OPTIONS R where specifies the alternate system root in the format "__ddcu:[SYSn.]".) NOTE You should have at least 5000 free blocks on your system disk device before beginning the installation procedure. 4-1 HOW TO INSTALL BLISS-32 V4.7 INSTALLATION PROCEDURE 2. If there are other users on the system, or you have DECnet running, VMSINSTAL will warn you and ask if you want to continue with the installation. DECnet should not cause any problems. It is slightly safer to install when you have the system to yourself, but other users on the system normally will not cause problems. VMSINSTAL will also ask if you are satisfied with the backup of your system disk. It is always a good idea to have a current system disk backup before performing an installation. VMSINSTAL will then report: The following products will be processed: BLS32 V4.7 Beginning installation of BLS32 V4.7 at hh:mm %VMSINSTAL-I-RESTORE, Restoring product save set A ... %VMSINSTAL-I-RELMOVED, Product's release notes have been moved to SYS$HELP. BLISS-32 V4.7 Copyright © Digital Equipment Corporation. 1976, 1993. All rights reserved. Product: BLISS32 Producer: DEC Version: 4.7 Release Date: 3-OCT-1989 * Does this product have an authorization key registered and loaded? If you respond "NO" the installation continues: %BLS32-W-NOLICENSE, License not registered. Installation will continue. After your BLISS-32 license has been registered, compile the system require files and run the IVP. To compile the system require files: $ SET DEFAULT SYS$LIBRARY $ BLISS/LIBRARY STARLET $ BLISS/LIBRARY=LIB STARLET+LIB 4-2 HOW TO INSTALL BLISS-32 V4.7 INSTALLATION PROCEDURE $ BLISS/LIBRARY TPAMAC To run the IVP: $ @SYS$TEST:BLISS32$IVP The installation continues: %VMSINSTAL-I-RESTORE, Restoring product save set B ... * Do you want to purge files replaced by this installation [YES]? * Do you want to run the IVP after the installation [YES]? This kit contains a file summarizing the new features, changes, restrictions, and compatibility issues in this release of VAX BLISS-32. This file is named BLS32047.RELEASE_NOTES and will be placed in SYS$HELP:. The release notes contains information valuable to VAX BLISS-32 programmers. Please inform your VAX BLISS-32 users of this file's existence. The BLISS help file contains extensive documentation on the BLISS language. Since this material requires about 525 blocks of disk space, its inclusion is optional. * Do you want the long help file [YES]? All questions regarding the installation have now been asked. The system directories will now be updated. %BLS32-I-LIBBUILD, Building the precompiled libraries This phase of the installation process compiles the STARLET, LIB, and TPAMAC L32 files. The corresponding REQ files are expected to be in SYS$LIBRARY. If one is missing, you will receive a warning message and that library file will not be created. This will not interfere with the rest of the installation. %VMSINSTAL-I-SYSDIR, This product creates system disk directory VMI$ROOT:[SYSTEST.BLS32]. * * * * * * * * * * * * * * * * * * * * * * * * This kit and its contents are for * * * * DIGITAL INTERNAL USE ONLY. * * * * * * * * * * * * * * * * * * * * * * * * 4-3 HOW TO INSTALL BLISS-32 V4.7 INSTALLATION PROCEDURE %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories... If you said that the PAK had been installed, the IVP is run: %BLS32-I-IVP, Performing Installation Verification Procedure *************************** Successful Installation of VAX Bliss-32 V4.7-999 *************************** Installation of BLS32 V4.7 completed at hh:mm VMSINSTAL procedure done at hh:mm 3. If BLISS32 is a known shared image on your system, you will have to use the INSTALL utility to replace it at this point -- see section 2.3.3. 4-4