Service Manuals, User Guides, Schematic Diagrams or docs for : xerox mesa 4.0_1978 Mesa_4_Documentation Mesa_4.0_Compiler_Update_May78

<< Back | Home

Most service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.




Image preview - the first page of the document
Mesa_4.0_Compiler_Update_May78


>> Download Mesa_4.0_Compiler_Update_May78 documenatation <<

Text preview - extract from the document
               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,



◦ Jabse Service Manual Search 2024 ◦ Jabse PravopisonTap.bg ◦ Other service manual resources online : FixyaeServiceinfo