Text preview for : Mesa_4.0_Compiler_Update_May78.pdf part of xerox Mesa 4.0 Compiler Update May78 xerox mesa 4.0_1978 Mesa_4_Documentation Mesa_4.0_Compiler_Update_May78.pdf
Back to : Mesa_4.0_Compiler_Update_ | Home
Inter-Office Memorandum
To Mesa Users Date May 31, 1978
From Ed Satterthwaite Location Palo Alto
Subject Mesa 4.0 Compiler Update Organization SOD/SO
XEROX
Filed on: [IRIS]DOC>COMPILER40.BRAVO
This memo describes changes to the Mesa language and compiler that have been made since
the last release (October 17, 1977). As usual, the list of compiler-related change requests
closed by Mesa 4.0 will appear separately as part of the Software Release Description.
The language accepted by the Mesa 4.0 compiler has several significant extensions and a few
minor changes. It features a process mechanism, enhanced arithmetic capabilities, long and
base-relative pointers, and more general block structure.
Because of changes in symbol table and BCD formats, all existing Mesa programs must be
recompiled. There are minor incompatibilities with Mesa 3.0 at the source level in the areas
of signed/unsigned arithmetic and the scope of OPEN in an iterative statement. These
incompatibilities should have negligible impact on existing programs. The syntax and
semantics of declaring (but not calling) machine-coded procedures have changed
substantially.
Page and section numbers in this update not otherwise qualified refer to the Mesa Language
Manual, Version 3.0. The BNF descriptions of new or revised syntax follow the
conventions introduced in that manual. For phrase classes used but not redefined here, see
its Appendix D. Revisions of phrase class definitions are cumulative; except as noted, the
appearance of "... " as an alternative indicates that an existing definition is being augmented.
A definition without "... " supersedes any definition of the same phrase class in the manual.
Arithmetic
Mesa 4.0 supports double-precision integer arithmetic (type LONG INTEGER) and provides
some help with floating-point computations (type REAL). In conjunction with these changes,
the rules governing combination of signed and unsigned values have been more carefully
defined (see the Appendix to this memo).
Syntax
PredefinedType ::= INTEGER I CARDINAL I LONG INTEGER I REAL I
BOOLEAN I CHARACTER I STRING I UNSPECIFIED WORD
Primary .. -
"- identifier [ Expression ] I LONG [ Expression ]
Mesa 4.0 Compiler Update 2
~
Signed and Unsigned Arithmetic
The rules governing the use of signed and unsigned representations in single-precision
arithmetic have been reformulated. In previous versions of Mesa, conditions under which
an operation was considered to overflow were not well defined. As a consequence, options
such as overflow detection and reliable range checking were precluded. Mesa 4.0 does not
offer these options, but it does remedy the defects in the language definition.
The precise rules governing signed/unsigned arithmetic are somewhat lengthy. They appear
in an appendix to this memo with some background information explaining the motivation
and philosophy. In their effect on the acceptance or rejection of source text, the new rules
differ little from those in previous versions of Mesa; the main change is that CARDINAL -
CARDINAL is now assumed to produce a result with unsigned (instead of unknown)
representation (see Section 2.5.1, pages 10-12). Thus the immediate practical effect of the
new rules is minor; however, programmers should read the appendix carefully so that their
code will work correctly even when it becomes possible to request overflow and range
checks.
The effects of the new rules with respect to subtraction are worth emphasizing. If
both operands have valid signed representations, the result is an INTEGER. If both
have only unsigned representations, the result is a CARDINAL and is considered to
overflow if the first operand is less than the second.
i: INTEGER; m, n: CARDINAL; s, t: [0 .. 10);
i .. m-n; -- should be used only if it is known that m >= n
i .. IF m >= n THEN m-n ELSE -(n-m); -- should be used otherwise
IF m-n > 0 ... comparison (and subtraction) are unsigned
IF m > n ... a better and safer test
IF s-t <0 ... comparison (and, subtraction) are signed
Range Assertions
The new rules mentioned above assume that there are implicit conversion functions mapping
CARDINAL to INTEGER and vice-versa. In both directions, the "conversion" amounts to an
assertion that the argument is an element of INTEGER n CARDINAL. The programmer can
make such a range assertion explicit. If S is an identifier of a subrange type and e is an
expression with compatible type T, the form See] has the same value as e and is
additionally an assertion that e IN [FIRST[SnT] .. LAST[SnT]] is TRUE.
Note that this is not equivalent to LOOPHoLE[e, S] but is an assertion about the range
of a value that already has an appropriate type.
In Mesa 4.0, such assertions must be verified by the programmer. There is not an option to
generate code that checks these assertions, whether implicit 0)' explicit. An assertion can be
used to control the assumed representation of a subexpression; otherwise, it is currently
treated as a comment by the compiler.
Examples
INTEGER[n], IndexType[i-j]
Mesa 4.0 Compiler Update
I
3
Long Integers
Mesa 4.0 supports double-precision integers. There is a new predeclared type LONG INTEGER,
values of which occupy two words (32 bits) of storage and range over [-2 31 .. 231 ). There is
no special denotation for LONG INTEGER constants. The type of any decimal or octal constant
in [2 16 .. 231 ) is LONG INTEGER; smaller constants are converted as required by context. The
arithmetic operators +, -, *, I, MOD, MIN, MAX, (unary) - and ABS have double-precision
extensions that perform the mapping
(LONG INTEGER)n ... LONG INTEGER;
furthermore, LONG INTEGERS are ordered, and the relational operators =, #, <, <=. >, >= and IN
have extensions that perform the mapping
(LONG INTEGER)n ... BOOLEAN.
Some fine points:
All LONG INTEGERS have a signed representation; the Mesa 4.0 language does not
provide LONG CARDINAL.
Addition, subtraction, and comparison of LONG INTEGERS is fast; multiplication and
division are done by software and are relatively slow.
In Mesa 4.0, it is not possible to declare a type that is a subrange of LONG INTEGER.
Mesa provides an automatic coercion from any single-precision numeric type (INTEGER,
CARDINAL, etc.) to LONG INTEGER. This coercion is called widening and is discussed in more
detail below. It is applied when necessary to match inherent and target types (e.g., in
assignments). Also, if any operand of an arithmetic or relational operator is a LONG INTEGER,
the double-precision operation is used. In most cases, widening of any shorter operands is
automatic. Thus single- and double-precision quantities can be mixed freely within
expressions to yield double-precision results.
The form LONG[e] explicitly forces the widening of any expression e with a single-precision
numeric type. There are no automatic conversions from LONG INTEGER to any single-
precision type (but see the Mesa 4.0 System Documentation for some standard procedures).
Widening of a single-precision constant is done at compile-time. Currently, no
other arithmetic or relational operations on LONG INTEGERS are performed at
compile-time, even if all operands are constant.
Widening of a single-precision expression is substantially more efficient if that
expression has an unsigned representation.
Examples
i: INTEGER;
ii: LONG INTEGER;
c2: LONG INTEGER = 2; -- a compile-time constant
c4: LONG INTEGER = c2*c2; -- not a compile-time constant
ii ... 0; ii'" ii+l; ii'" i; Ii'" (ii+i)/c2; all valid
Ii ... LONG[O]; ii'" (ii+LONG[i])/c2; also valid (and explicit)
i ... ii; ii'" LONG[c4]; invalid
Mesa 4.0 Compiler Update 4
Reals
A standard representation for floating-point values has not yet been chosen. Mesa 4.0
nevertheless provides some help with floating-point computation. It allows declaration and
assignment of REAL values; furthermore, REAL expressions constructed using the standard
infix operators (except MOD) are converted to sequences of procedure calls by the compiler.
A REAL value is assumed to occupy two words (32 bits) of storage. Beyond this, no
assumptions are made about the representation of REALS. Users of real arithmetic must
provide and install an appropriate set of procedures for performing the arithmetic
operations (see the Mesa 4.0 System Documentation also). The procedures must be
assignable to variables declared as follows:
FADD, FSUB, FMUL, FDIV: PROCEDURE [REAL, REAL] RETURNS [REAL];
FCOM P: PROCEDURE [REAL,