Heading:
Mesa 6.0m Change Summary
Page Numbers: Yes X: 527 Y: 10.5"
Copyright c Xerox Corporation 1980
Inter-Office Memorandum
ToMesa UsersDateSeptember 26, 1980
FromDick SweetLocationPalo Alto
SubjectMesa 6.0m Change SummaryOrganizationSDD/SS/Mesa
XEROX
Filed on: [Igor]<AlphaMesa>Doc>Summary60m.bravo
This memo outlines changes made in Mesa since the last alpha update (Mesa 6.0u, July 11, 1980). These changes will shortly be incorporated into the Mesa 6.0 Change Summary to correctly reflect the differences between Mesa 5.0 and Mesa 6.0. This document also includes a list of ARs fixed since 6.0u.
Language
The language has been extended in the following areas:
Monitor Locks and Condition Variables in Records
When constructing a record, any fields not mentioned (and not having defaults) are not guaranteed to have known values after the construction. In particular, they are not guaranteed to have their previous values. This poses a problem in types containing "hidden" fields such as the queues of processes in MONITORLOCKs and CONDITIONs, and with a few other types (see the attached memo from Ed Satterthwaite). To protect users from inadvertantly overwriting these fields, the Mesa 6 compiler does not allow updating of variables of these types, or of any composite type containing a field of these types. This does not mean that MONITORED RECORDs are read-only; they can be assigned to field by field. However, it is illegal to write a constructor for an entire MONITORED RECORD except at the point of declaration (or allocation, by the NEW operator).
Sequences
A sequence is an indexable collection of objects, all of which have the same type. In this respect, a sequence resembles an array; however, the length of a sequence is not specified at compile time. Consider some examples of "faked" sequences from Mesa 5.
. . .
ARec1:
TYPE = RECORD [
common: . . .
count: CARDINAL, -- number of elements
body: ARRAY [0..0) OF INTEGER];
. . .
ARec2: TYPE = RECORD [
common: . . .
body: ARRAY [0..0) OF INTEGER];
ar1: POINTER TO ARec1;
ar2: POINTER TO ARec2;
The record ARec1 contains a count of the number of INTEGERs in body. The number of elements in an ARec2 is not contained in the record; it is kept elsewhere, say in a global variable, or computed from the values of common fields. Note that these "variable length" arrays occur only at the end of records (they obviously couldn’t occur in the middle). Also, since you aren’t telling the compiler how many elements are present in a given ARec*, it doesn’t make sense to declare one; you obtain storage from your favorite allocator and access the elements using a pointer.
In Mesa 6, these constructs are built into the language. A SEQUENCE occurs as the last field of a record. It optionally has a count of elements associated with the indexable portion. The following Mesa 6 declarations are roughly equivalent to the Mesa 5 ones above:
. . .
SRec1: TYPE = RECORD [
common: . . .
body: SEQUENCE count: CARDINAL OF INTEGER];
. . .
SRec2: TYPE = RECORD [
common: . . .
body: SEQUENCE COMPUTED CARDINAL OF INTEGER];
sr1: POINTER TO SRec1;
sr2: POINTER TO SRec2;
Variables of type SRec* must also be dynamically allocated at runtime, since they are of variable length. However, the NEW operator of Mesa 6 knows how to deal with sequences. Let z be an MDSZone, n a CARDINAL. The following are legal statements:
(1)sr1z.NEW [SRec1[n]];-- sets sr1.count to n
(2)sr2z.NEW[SRec2[n]];
(3)sr1z.NEW[SRec1[n] ← [common: . . ., body: NULL]];
In statement (1), sufficient space is allocated to contain the common part of an SRec1 plus n elements (INTEGERs) in the sequence part. Additionally, the number of elements, count, is initialized to the value n. Thereafter, the value of count is readonly. The only way to set the length field of a sequence is by the NEW operator. In statement (2), space is allocated for an SRec2 with n elements, but there is no count field to initialize. Of course, in any of these statements, n could be replaced by any constant or expression of type CARDINAL. In statement (3), the common fields are also set by an initializing constructor. Note that the "array" part of the sequence is voided in the constructor. In Mesa 6, there is no provision for writing a constructor for the variable length portion of a SEQUENCE. One must write explicit code to initialize it.
To access an element of the sequence, one attaches an indexing expression to the pointer to the record containing the sequence. This is analogous to the treatment of type STRING (which is essentially a sequence of the Mesa 6 variety).
isr1[j];
sr2[j] ← i;
If one compiles a module with bounds checking enabled (/b to the compiler), code will be generated when accessing sr1[j] to assure that j IN [0..sr1.count).
Alternatively, one may write:
isr1.body[j];
sr2.body[j] ← i;
analogous to saying s.text[i] for a STRING.
The attached memo from Ed Satterthwaite discusses the use and declaration of SEQUENCEs in considerable detail.
Formatter
The Formatter is a program for transforming Mesa source files into a standard format. It uses the Compiler’s scanner and parser to determine nesting, and hence can be used only on syntactically correct programs. Attached is the Appendix from the Mesa 6 Users Handbook (in progress) that explains the use of the Formatter. The /c switch (compile output) is not yet implemented.
Binder
The binder now allows the association between file names and module or configuration names to be given on the command line, in much the same way as the compiler does. For example, the command line
>Binder.bcd Tajo[TestPilot: UnpackagedTestPilot]
will bind Tajo.config using the previously bound configuration TestPilot that is stored in the file named UnpackagedTestPilot.bcd. One can best think of the the text inside the brackets as inserting or augmenting a DIRECTORY statement at the beginning of the configuration.
System
All of the system interfaces have been recompiled for 6.0m. This means that all modules must be recompiled/rebound to use the new Mesa.image. No source changes are necessary (except for users of FTPDefs, as previously announced; see below).
To track development in other systems, minor revisions have been made in the Development Software interfaces Format, Inline, Runtime, System, and Time.
RunMesa
RunMesa has been upgraded to included Alto microcode for Pup checksums, IEEE floating point, and HBlt (Griffin). This microcode is loaded with the XMesa overflow microcode on Altos with the 2K ROM (with version 41 microdoce) or 3K RAM option. Users who have been loading microcode for these functions need no longer do so. This change affects Alto IIs only. One must still load software routines to use floating point on a Dolphin.
Debugger
In addition to many bug fixes, the following changes and additions have been made:
Source Menus
Attach
The Attach menu command has been added to the Source Ops source menu; it causes the Debugger to ignore the creation date of the current source file when setting breakpoints or positioning to a source line. Because the source-object correspondence may no longer be correct, this command should be used with caution. If, after invoking this command, the Debugger sets breakpoints in strange places, chances are that the source file does not match the object in the system you are debugging.
Commands
ReSet context [confirm]
This command now requires two keystrokes, to avoid conflict with the ReMote debuggee command (not yet implemented on the Alto).
Program-not-started Indication
When the debugger refers to a program module, it usually gives the address of its global frame, e.g (G: nnnnnB). If the module has not been started, the debugger now prints a tilde (~) after the B. If a module has not been started, the user should not believe and should not modify the global variables of that module.
Command Central
The options window has changed format and allows inclusion of default switch settings.
Performance Monitor
The Performance Monitor has been upgraded to Mesa 6.0. It is the same as in Mesa 5.0 except that debugger breakpoint numbers are used for NodeIDs. Upgraded documentation will be forthcoming.
Xfer Counter
The Xfer Counter has been upgraded to Mesa 6.0. A new mode of operation has been added to gather information on the flow of control between groups of modules. Documentation for the Xfer Counter is attached.
Pup
PupDefs
UseAltoChecksumMicrocode: PROCEDURE has been added to speed up processing if you are running on an Alto II with the 2K ROM or 3K RAM option. The overflow microcode loaded into the RAM by RunMesa.run includes the necessary additions. (Beware if you load your own microcode.)
Subtle implementation changes
GetPupAddress will no longer return an address for a dying net. EnumeratePupAddresses will now pass the client-supplied procedure addresses on dead or dying nets, but only after processing all the addresses on nets that are reachable. (It used to skip addresses on unreachable nets.)
The byte stream internals have been reworked to eliminate several unpleasant delays while opening and closing connections. It is now possible to open a connection, send a thousand words, and close the connection in less than a second. (Since Close UnNews three module instances, it will take longer if you have a lot of active global frames.) A byproduct of this cleanup is that SendNow will send an empty aData packet to request an acknowledgment even if the previous SendBlock happened to end on a convenient packet boundary.
Bug fixes
The following change requests are closed by this release:
5005 Delays when creating byte stream
5093
NameLookup vs dying nets
5098 Change priority of interrupt routine in
EthernetDriver(s)
Ftp
FTPDefs
The arguments to the (client supplied) procedure passed to FTPInventoryDumpFile have been extended to allow proper processing of create dates. It is now compatable with the procedure passed to FTPEnumerateFiles.
Bug fixes
The following change requests are closed by this release:
3987 StringBoundsFault from TimeExtras.PacketTimeFromString
4444
FTPInventorryDumpFile needs create date
4763 Troubles if forget to call
IdentifyNextRejectedRecipient
5152
TimeExtras.PacketTimeFromString zone screwup
5198 Config with server and user things
Distribution:
Mesa Users
Mesa Group
SDSupport