Service Manuals, User Guides, Schematic Diagrams or docs for : xerox sdd memos_1977 19771017_Mesa_3.0_Compiler_Update_Mesa_Language_Changes
<< Back | HomeMost 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
>> Download 19771017_Mesa_3.0_Compiler_Update_Mesa_Language_Changes documenatation <<
Text preview - extract from the document
Inter-Office Memorandum
To Mesa Users Date October 17, 1977
From Ed Satterthwaite Location Palo Alto
Subject Mesa 3.0 Compiler Update Organization CSL
Mesa Language Changes
XEROX
Filed on: [MAXC]MESACOMPILER30.8RAVO
This release of the Mesa compiler introduces several changes of interest or importance to all
Mesa programmers. A number of changes in the language have been made. Some of these
will calise programs acceptable to previolls compilers to be rejected unless those programs
are modified. The reasons for maki ng sllch changes are the following:
To support new ways of describing configurations and binding them together.
To add new facilities to the language.
To prepare for certain language extensions that are now fairly well understood and
for which preliminary designs exist.
Language Changes Related to the Binder
Overview
The following overview might be helpful in understanding the changes related to the new
binder. See the release summary for further references.
The binder produces a configuration, which is a collection of module instances. Each
module instance is represented by a global frame. Resolution of intermodular references is
based upon copying descriptor and pointer values from well-defined interfaces into these
global frames. More precisely, the binder produces configuration descriptions, which must
be "relocated" by the loader to produce an actual configuration.
There are two kinds of modules: DEFINITIONS and PROGRAM. The text of either kind implicitly
defines a type. In the case of a program module X, this is a frame type, denoted by
FRAME[X]. Values of this type are created in the (frame) heap, either by loading or by the
NEW operation. They cannot be embedded within larger aggregates but are referenced
indirectly through pointers. In the case of a DEFINITIONS module, the sequence of declarations
implicitly defines an interface type. There is no explicit name for this type, but it is much
like a record type with a field for each item in the interface. Instances of interface types,
called interface records, can appear only as components of global frames, where they are
anonymous.
A program can export an interface, in which case a (partially) initialized interface record is
created by the compiler. The initializing values represent procedures, signals, etc., declared
within the program. (These values are "relocated" and made instance-specific each time the
program is instantiated.) A program can also import an interface to gain access to externally
defined procedures and the like. In this case, the interface record is left uninitialized by the
Mesa 3.0 Compiler Update 2
compiler. One job of the binder is to merge exported instances of each particular interface
type and to assign the result to imported interfaces of the same type. The binder's
Configuration Description Language is used to specify and control these assignments.
A program also exports itself (as a pointer to its global frame) and can import instances of
other programs (again, with access through frame pointers). In this case, the binder's job is
to locate and assign the required (relocatable) frame pointers.
Note
The preceding discllssion is conceptually accurate but should not be taken literally.
The actual implementation of interfaces is somewhat more complicated and much
more space-efficient than implied here. Exported interface records are part of each
object file but have no existence during execution; furthermore, only those fields of
imported records that are actually referenced occupy space in the global frame.
Since the interface records do not exist as such during execution, they are sometimes
called virtual inter/ace records.
Because the binder is a preprocessor, any code required to compute and assign the values of
initialized variables cannot be run during binding. For uniformity, the language definition
has been changed so that the effect of the NEW operator is limited to creating an instance of
a global frame. The frame must be sTARTed to pass any required parameters and to
initialize any nonconstant variables. The binder and loader perform the equivalent of a NEW
but not a START.
Defining Interfaces
An interface type is defined by a DEFINITIONS module. The form of such a module has not
changed. It contains two sorts of declarations:
(1) Constant definitions (including type definitions)
(2) Interface element definitions (procedures, signals, etc).
By convention, items of the first sort have identical values in all instances of the interface
and can be referenced by specifying just the interface type. The fields of an interface
record contain values of the second sort and correspond to the so-called "externals" found in
previous versions of Mesa.
One new type of interface element is available. The type constructor
ProgramTC ::= PROGRAM ParameterList ReturnsClause
defines a type that can be used to declare a program variable. As part of an interface
record, the value of a program variable is a pointer to a global frame of a like-named
program. The declaration of a program variable specifies only input/output types; it does
not provide access to the internal structure of a particular global frame. Uses of program
variables are discussed below.
Defining Program Modules
A module gains access to another by including the (compiled) definitions file. As before,
the DIRECTORY construct makes the connection between the Mesa identifier denoting the
module and the name of the object file. Note, however, that identifiers introduced in the
DIRECTORY now must match the module identifiers appearing in the original source.
Mesa 3.0 Compiler Update 3
Imported and exported items are "declared" in the heading of a PROGRAM module using the
following syntax (cf. Appendix D, Mesa Language Manual):
ModuleHead ::= DEFINITIONS ShareList
I PROGRAM ParameterList ReturnsClause
ImportList ExportList ShareList
ImportList .. - empty I IMPORTS ModuleList
ExportList .. - empty I EXPORTS IdList
ShareList .. - empty I SHARES IdList
ModuleList .. - Moduleltem I ModuleList , Moduleltem
Moduleltem .. - identifier I identifier : identifier
The symbol DATA can be used in place of PROGRAM, but there is no longer a
distinction between PROGRAM and DATA modules. Note also that the previous concept
of IMPLEMENTING has been replaced by EXPORTS, and SHARES replaces SHARING.
Exporting Interfaces
The value of each identifier in the EXPORTS list must be an interface type, i.e., a DEFINITIONS
module named in the directory.
Procedures, signals, and errors are exported if they are public, have constant initialization
and are named in some exported interface. In addition, the program itself (in the form of
its global frame) is exported as part of an interface if its identifier appears there with an
appropriate PROGRAM type. (The global frame can also be exported independently of any
interface; see below.) The compiler checks that the type of each exported item is assignment
compatible with the type of the corresponding interface item. An item can be exported
through more than one interface.
It is permissible for a module to both import and export an interface; this is the normal case
when a number of modules cooperate to provide a single interface.
If a module exports Defs and defines a public identifier id, then Defs.id is bound
directly (by the compiler) to the local definition, e.g., local procedure calls are used.
Exporting an interface does not automatically provide access to its private components.
Specifying SHARES (formerly SHARING) allows such access to any module but does not
automatically imply EXPORTS.
Importing Interfaces
After a module has been loaded, its imported interface records contain the linkages to other
modules in the configuration. References to such linkages take the usual forms. The
identifier of an interface item (Item) can be qualified by the name of the interface record
(Defs.ltem[ ... ]); alternatively, an interface record can be oPENed and the corresponding
identifiers used without qualification (Item[ ... ]).
Arbitrary identifiers (preceding It:" in the IMPORTS list) can be associated with imported
interface records so that several instances of the same interface type (perhaps bound
differently) can be distinguished. If the identifier of an imported interface record is
omitted, the name of the interface type is used by default, i.e., id is equivalent to id:id in an
IMPORTS list (see the discussion of DEFINITIONS FROM, however), The identifier following the
colon must be defined in the directory. It can name an interface type, i.e., a DEFINITIONS
module. Alternatively, it can name a PROGRAM module; this case is discussed later.
It is important to distinguish between interface types (declared in the DIRECTORY list) and
interface records (declared in the IMPORTS list). Assume the fonowing program skeleton:
Mesa 3.0 Compiler Update 4
DIRECTORY Defsl: FROM "defsI", Defs2: FROM "defs2";
Prog: PROGRAM IMPORTS Interfacel: Defsl, Defs2 =
BEGIN ◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo