Heading:
Cedar System Modelling Reference Manual
Page Numbers: Yes X: 527 Y: 10.5" First Page: 14
Implementation Details
Implicit DIRECTORY Entries
The Cedar and Mesa 6 compilers may produce object files for DEFINITIONS modules that have incomplete information about types in their symbol segments. The missing information is available in other .Bcd files, which are called hidden directory entries since a client of a definitions module must also have these definitions modules present on the local disk to compile his program. Such hidden dependencies do not appear in the parameter list of any @ file in a model. However, when compiling a module that needs to reference such .Bcds, the modeller will print an error message if it cannot find an entry that satisfies the reference to the hidden .Bcd in the model.
Implicit IMPORTS Entries
In Cedar and Mesa 6, definitions modules may import instances of other interfaces (chiefly for INLINE procedure use, see [Compiler2] for more information.) The .Bcd produced for a Mesa program that imports an interface may also need to import another interface. The additional import is called a hidden import when loaded by the modeller. As with hidded directory entries, these hidden imports do not appear as parameters to the client. When loading the .Bcd for such a client, the modeller will select any interface record that matches the version stamp of the hidden import to resolve the reference. If no such interface is available, the modeller will give a warning message (and the references will remain unresolved.)
The Modeller Database
A database of information about source and object files is maintained by the modeller. This database is stored in a file on the local disk, managed in the user’s virtual memory. Since analyzing commonly-used files every time the modeller is loaded is expensive, the modeller will ask if you want to use the contents of the old database or to erase that data and start with an empty database. The database "cannot" have erroneous data in it, so unless it is full, typing "y" or CR to the re-use question will speed up subsequent modeller usage and will not cause problems.
The space used by the database occupies a fixed location in virtual memory, so the modeller may not be able to map the database file to the correct address. Should this happen, re-booting Cedar and running the modeller immediately thereafter should make re-use of the database possible.
Use of the Modeller from the Cedar Executive
The modeller pushbuttons described above can be "pushed" from a command file by executing commands registered with the Cedar Executive. (Each command is preceded by the letter "X" to make typing "X" followed by TAB to the Executive useful.)
Cedar Executive Command Corresponding PushButton or Enumeration
> XAttachEditor.~AttachEditor: {TRUE}
> XCompileWORepl.~CompileWithOutRepl!
> XCompileWRepl.~CompileWithRepl!
> XDetachEditor.~AttachEditor: {FALSE}
> XLoadAll.~LoadAll!
> XLoadWithRepl.~LoadWithRepl!
> XMakeModel.~MakeModel!
> XNotice.~Notice!
> XNAll.~NoticeAll!
> XPermanent.~Permanent!
> XProgramStart.~StartAll!
> XSetWorkingModel.~SetWorkingModel!
> XStartModelling.~StartModelling!
> XStopModelling.~StopModelling!
> XTemporary.~Temporary!
> XType.~Type!
> XUnLoad.~UnLoad!
Getting Started
To retrieve the latest version of the modeller, type
> BringOver /p [Indigo]<CedarLang>Modeller>Modeller.DF;
To start the modeller, type
> Model;
to the executive. If an old database is on the local disk, the modeller will ask if you want to use it. Typing y or CR will use the old database, n will start with an empty one.
User.CM Options
You may want to edit your User.CM to add a section [Modeller] to your User.CM with some parameters the modeller reads when it is loaded. DefaultModel: followed by a model file name sets the initial model file name for the StartModelling! file name field, AttachEditor: followed by TRUE or FALSE determines the initial value of the field with the same name in the model window, and Wizard: followed by TRUE or FALSE determines whether debugging subwindows will be created when the modeller is started. These keywords are defaulted as if the User.CM section looked like:
[Modeller]
AttachEditor: TRUE
DefaultModel:
Wizard: FALSE
An Example (No Defaults)
This model, which was generated automatically by DesignModel, describes the BringOver program. We’ll give you the model without defaults first, and then introduce the various defaulting rules that reduce the complexity to that of a simple CONFIGURATION module.
There are seven implementation modules and one configuration within this model (ComParseImpl, CWFImpl, SubrImpl, DFSubrImpl, FTPSubrImpl, BringOverImpl, PilotSSImpl, and FTPUser). All the rest are definitions files.
-- File: BringOver.Model, last edit January 15, 1981
Environment: TYPE == @Environment.mesa!2495152852;
Stream: TYPE == @Stream.mesa!2512514215[Environment];
String: TYPE == @String.mesa!2505079728[Environment];
MiscAlpha: TYPE == @MiscAlpha.mesa!2513637024;
Mopcodes: TYPE == @Mopcodes.mesa!2513636996;
System: TYPE == @System.mesa!2512510255[MiscAlpha, Mopcodes];
Time: TYPE == @Time.mesa!2511811906[System];
Ascii: TYPE == @Ascii.mesa!2513637266;
Format: TYPE == @Format.mesa!2512400637[String, Time, System];
TTY: TYPE == @TTY.mesa!2514228782[Ascii, Format, Stream, String, Time, System];
Exec: TYPE == @Exec.mesa!2522073848[TTY];
Inline: TYPE == @Inline.mesa!2495146094[Environment, Mopcodes];
Transaction: TYPE == @Transaction.mesa!2508440429;
File: TYPE == @File.mesa!2508166537[Inline, System, Transaction];
Space: TYPE == @Space.mesa!2511801733[Environment, File, Transaction];
Heap: TYPE == @Heap.mesa!2512678088[Space, Environment];
SDDefs: TYPE == @SDDefs.mesa!2513637152;
Runtime: TYPE == @Runtime.mesa!2514412201[File, Mopcodes, SDDefs, System];
Storage: TYPE == @Storage.mesa!2510096576[Environment];
FileStream: TYPE == @FileStream.mesa!2511989735[File, Stream, System];
Volume: TYPE == @Volume.mesa!2512677128[File, System];
Directory: TYPE == @Directory.mesa!2517693769[File, System, Volume];
OISCPTypes: TYPE == @oiscptypes.Bcd!2517762425;
PupTypes: TYPE == @PupTypes.mesa!2505871727;
DriverTypes: TYPE == @drivertypes.Bcd!2517762434;
SpecialSystem: TYPE == @specialsystem.Bcd!2517762334;
BufferDefs: TYPE == @BufferDefs.mesa!2517697345[OISCPTypes, PupTypes, DriverTypes,
SpecialSystem];
PupDefs: TYPE == @PupDefs.mesa!2512420106[BufferDefs, PupTypes];
AddressTranslation: TYPE == @AddressTranslation.mesa!2514904448[SpecialSystem, System];
Process: TYPE == @Process.mesa!2517520325;
ByteBlt: TYPE == @ByteBlt.mesa!2495146082[Environment];
PupStream: TYPE == @PupStream.mesa!2505266177[Stream, PupDefs, PupTypes];
NetworkStream: TYPE == @NetworkStream.mesa!2517522491[Stream, System];
Model: PROC [ExecImpl: Exec,
StringImpl: String,
TimeImpl: Time,
TTYImpl: TTY,
HeapImpl: Heap,
InlineImpl: Inline,
RuntimeImpl: Runtime,
StorageImpl: Storage,
FileStreamImpl: FileStream,
FileImpl: File,
SpaceImpl: Space,
StreamImpl: Stream,
TransactionImpl: Transaction,
DirectoryImpl: Directory,
PupDefsImpl: PupDefs,
AddressTranslationImpl: AddressTranslation,
ProcessImpl: Process,
ByteBltImpl: ByteBlt,
PupStreamImpl: PupStream,
NetworkStreamImpl: NetworkStream,
VolumeImpl: Volume]
RETURNS [] [
ComParse: TYPE == @comparse.mesa!2525717737;
CWF: TYPE == @cwf.mesa!2525492185;
Segments: TYPE == @PilotSegments.mesa!2518448715[Environment, File, Space, Time, System];
Streams: TYPE == @PilotStreams.mesa!2516815806[FileStream,
Segments, Stream, Time, File, System, Environment];
DFSubr: TYPE == @dfsubr.mesa!2525730916[Segments, Streams, File, Stream];
FTPDefs: TYPE == @FTPDefs.mesa!2512420505;
FTPSubr: TYPE == @ftpsubr.mesa!2525724306[FTPDefs, Streams, TTY, Stream];
Subr: TYPE == @subr.mesa!2525723589[Mopcodes, Process, Streams, TTY, Stream];
TimeExtra: TYPE == @TimeExtra.mesa!2505158646[System];
ComParseImpl: ComParse == @comparseimpl.mesa!2525717709["-ab-jn",
Exec, Storage, String, TTY, ComParse, Ascii, Streams,
Segments, ExecImpl, StorageImpl, StringImpl, TTYImpl];
CWFImpl: CWF == @cwfimpl.mesa!2525492790["-ab-jn", Inline,
String, Time, CWF, System, Ascii, InlineImpl, StringImpl, TimeImpl];
SubrImpl: Subr == @subrimpl.mesa!2525724383["-ab-jn", CWF,
Heap, Inline, Runtime, Storage, Streams, String,
TTY, FileStream, Subr, Segments, Process, Stream,
System, Ascii, Environment, File, CWFImpl, HeapImpl,
InlineImpl, RuntimeImpl, StorageImpl, StreamsImpl,
StringImpl, TTYImpl, FileStreamImpl];
DFSubrImpl: DFSubr == @dfsubrimpl.mesa!2525730911["-ab-jn",
CWF, Segments, Streams, String, Subr, TimeExtra,
DFSubr, Time, Ascii, Stream, File, System, Environment,
CWFImpl, SegmentsImpl, StreamsImpl, StringImpl,
SubrImpl, TimeExtraImpl];
FTPSubrImpl: FTPSubr == @ftpsubrimpl.mesa!2525725186["-ab-jn",
CWF, FTPDefs, Segments, Streams, String, Subr, TTY,
FileStream, FTPSubr, File, Stream, CWFImpl, FTPDefsImpl,
SegmentsImpl, StreamsImpl, StringImpl, SubrImpl,
TTYImpl, FileStreamImpl];
BringOverImpl: CONTROL == @bringoverimpl.mesa!2525724202["-ab-jn",
ComParse, CWF, DFSubr, Exec, FTPDefs, FTPSubr, String,
Subr, Time, TimeExtra, TTY, Streams, System, Stream,
ComParseImpl, CWFImpl, DFSubrImpl, ExecImpl, FTPDefsImpl,
FTPSubrImpl, StringImpl, SubrImpl, TimeImpl, TimeExtraImpl,
TTYImpl];
FileTypes: TYPE == @FileTypes.mesa!2522009713[File]
DCSFileTypes: TYPE == @DCSFileTypes.mesa!2475178361[File, FileTypes];
LET [SegmentsImpl: Segments, StreamsImpl: Streams] == @PilotSSImpl.mesa!2520555588[
"-a-b-j-n", File, FileStream, Inline, Segments, Space,
Storage, Stream, Time, Transaction, Streams, Environment,
DCSFileTypes, System, FileImpl, FileStreamImpl, InlineImpl,
SegmentsImpl, SpaceImpl, StorageImpl, StreamImpl, TimeImpl,
TransactionImpl];
FTPPrivateDefs: TYPE == @FTPPrivateDefs.Bcd!2517775557;
LET [TimeExtraImpl: TimeExtra, FTPDefsImpl: FTPDefs, FTPPrivateDefsImpl: FTPPrivateDefs]
== @FTPUser.config!2513699370[
PupDefsImpl, DirectoryImpl, AddressTranslationImpl, FileStreamImpl,
ProcessImpl, StreamImpl, StringImpl, StorageImpl, TimeImpl,
ByteBltImpl, StreamImpl, PupStreamImpl, FileImpl, NetworkStreamImpl,
SpaceImpl, VolumeImpl, TransactionImpl];
].
The top group of TYPE’s are Pilot System definitions files. The model is named "Model" and begins "Model: PROC[", after which are listed parameters which must be passed in (in this case by the Pilot Loader). In this simple case those parameters are simply instances of interfaces of the required TYPE. The body of the model lists, one per line, either definitions files local to the model (i.e. definitions files from the programmer) or implementations of these definitions files. The host and directory information has been omitted in this example, but must be present for the modeller to retrieve and store files. The decimal number after the ’!’ is the create date of the .Mesa or .Bcd file. Notice each of these implementors has a string parameter; these are the compiler switches. Compiler switches don’t matter for definitions files. Also notice one implementor (BringOverImpl) exports an interface "CONTROL"; by convention, such an implementor is a module the modeller will START on command.
An Example (Parameter Lists Defaulted)
We can omit all the argument lists following @-signs, since the modeller can supply for each parameter an actual with the same name. (We could not default the parameters if a module imported more than one instance of an interface.) We can also omit the compiler switches unless they differ from the Cedar/Mesa compiler defaults.
-- File: BringOver.Model, last edit January 15, 1981
Environment: TYPE == @Environment.mesa!2495152852;
Stream: TYPE == @Stream.mesa!2512514215[];
String: TYPE == @String.mesa!2505079728[];
MiscAlpha: TYPE == @MiscAlpha.mesa!2513637024;
Mopcodes: TYPE == @Mopcodes.mesa!2513636996;
System: TYPE == @System.mesa!2512510255[];
Time: TYPE == @Time.mesa!2511811906[];
Ascii: TYPE == @Ascii.mesa!2513637266;
Format: TYPE == @Format.mesa!2512400637[];
TTY: TYPE == @TTY.mesa!2514228782[];
Exec: TYPE == @Exec.mesa!2522073848[];
Inline: TYPE == @Inline.mesa!2495146094[];
Transaction: TYPE == @Transaction.mesa!2508440429;
File: TYPE == @File.mesa!2508166537[];
Space: TYPE == @Space.mesa!2511801733[];
Heap: TYPE == @Heap.mesa!2512678088[];
SDDefs: TYPE == @SDDefs.mesa!2513637152;
Runtime: TYPE == @Runtime.mesa!2514412201[];
Storage: TYPE == @Storage.mesa!2510096576[];
FileStream: TYPE == @FileStream.mesa!2511989735[];
Volume: TYPE == @Volume.mesa!2512677128[];
Directory: TYPE == @Directory.mesa!2517693769[];
OISCPTypes: TYPE == @oiscptypes.Bcd!2517762425;
PupTypes: TYPE == @PupTypes.mesa!2505871727;
DriverTypes: TYPE == @drivertypes.Bcd!2517762434;
SpecialSystem: TYPE == @specialsystem.Bcd!2517762334;
BufferDefs: TYPE == @BufferDefs.mesa!2517697345[];
PupDefs: TYPE == @PupDefs.mesa!2512420106[];
AddressTranslation: TYPE == @AddressTranslation.mesa!2514904448[];
Process: TYPE == @Process.mesa!2517520325;
ByteBlt: TYPE == @ByteBlt.mesa!2495146082[];
PupStream: TYPE == @PupStream.mesa!2505266177[];
NetworkStream: TYPE == @NetworkStream.mesa!2517522491[];
Model: PROC [ExecImpl: Exec, StringImpl: String, TimeImpl: Time, TTYImpl: TTY,
HeapImpl: Heap, InlineImpl: Inline, RuntimeImpl: Runtime, StorageImpl: Storage,
FileStreamImpl: FileStream, FileImpl: File, SpaceImpl: Space, StreamImpl: Stream,
TransactionImpl: Transaction, DirectoryImpl: Directory, PupDefsImpl: PupDefs,
AddressTranslationImpl: AddressTranslation, ProcessImpl: Process, ByteBltImpl: ByteBlt,
PupStreamImpl: PupStream, NetworkStreamImpl: NetworkStream,
VolumeImpl: Volume]
RETURNS [] [
ComParse: TYPE == @comparse.mesa!2525717737;
CWF: TYPE == @cwf.mesa!2525492185;
Segments: TYPE == @PilotSegments.mesa!2518448715[];
Streams: TYPE == @PilotStreams.mesa!2516815806[];
DFSubr: TYPE == @dfsubr.mesa!2525730916[];
FTPDefs: TYPE == @FTPDefs.mesa!2512420505;
FTPSubr: TYPE == @ftpsubr.mesa!2525724306[];
Subr: TYPE == @subr.mesa!2525723589[];
TimeExtra: TYPE == @TimeExtra.mesa!2505158646[];
ComParseImpl: ComParse == @comparseimpl.mesa!2525717709[];
CWFImpl: CWF == @cwfimpl.mesa!2525492790[];
SubrImpl: Subr == @subrimpl.mesa!2525724383[];
DFSubrImpl: DFSubr == @dfsubrimpl.mesa!2525730911[];
FTPSubrImpl: FTPSubr == @ftpsubrimpl.mesa!2525725186[];
BringOverImpl: CONTROL == @bringoverimpl.mesa!2525724202[];
FileTypes: TYPE == @FileTypes.mesa!2522009713[];
DCSFileTypes: TYPE == @DCSFileTypes.mesa!2475178361[];
LET [SegmentsImpl: Segments, StreamsImpl: Streams] == @PilotSSImpl.mesa!2520555588[];
FTPPrivateDefs: TYPE == @FTPPrivateDefs.Bcd!2517775557;
LET [TimeExtraImpl: TimeExtra, FTPDefsImpl: FTPDefs, FTPPrivateDefsImpl: FTPPrivateDefs]
== @FTPUser.config!2513699370[];
]
An Example (More Extensive Defaulting)
The default extension .Mesa can be omitted from the file names. Also,
:@X!123[];
is equivalent to
X: TYPE X = @X.Mesa!123[];
if X.Mesa is a Definitions module and is equivalent to
XImpl: X = @X.Mesa!123[];
if X.Mesa is a Program module.
Also "*: X" stands for "XImpl: X". (This is useful in the model’s parameter list and for variables being defined in LET clauses.)
Then the model compresses into:
-- File: BringOver.Model, last edit January 15, 1981
:@Environment!2495152852;
:@Stream!2512514215[];
:@String!2505079728[];
:@MiscAlpha!2513637024;
:@Mopcodes!2513636996;
:@System!2512510255[];
:@Time!2511811906[];
:@Ascii!2513637266;
:@Format!2512400637[];
:@TTY!2514228782[];
:@Exec!2522073848[];
:@Inline!2495146094[];
:@Transaction!2508440429;
:@File!2508166537[];
:@Space!2511801733[];
:@Heap!2512678088[];
:@SDDefs!2513637152;
:@Runtime!2514412201[];
:@Storage!2510096576[];
:@FileStream!2511989735[];
:@Volume!2512677128[];
:@Directory!2517693769[];
:@oiscptypes.Bcd!2517762425;
:@PupTypes!2505871727;
:@drivertypes.Bcd!2517762434;
:@specialsystem.Bcd!2517762334;
:@BufferDefs!2517697345[];
:@PupDefs!2512420106[];
:@AddressTranslation!2514904448[];
:@Process!2517520325;
:@ByteBlt!2495146082[];
:@PupStream!2505266177[];
:@NetworkStream!2517522491[];
Model: PROC [* : Exec, * : String, * : Time, * : TTY, * : Heap, * : Inline,
* : Runtime, * : Storage, * : FileStream, * : File, * : Space,
* : Stream, * : Transaction, * : Directory, * : PupDefs, * : AddressTranslation,
* :Process, * : ByteBlt, * : PupStream, * : NetworkStream,
* : Volume] RETURNS [] [
:@comparse!2525717737;
:@cwf!2525492185;
:@PilotSegments!2518448715[];
:@PilotStreams!2516815806[];
:@dfsubr!2525730916[];
:@FTPDefs!2512420505;
:@ftpsubr!2525724306[];
:@subr!2525723589[];
:@TimeExtra!2505158646[];
:@comparseimpl!2525717709[];
:@cwfimpl!2525492790[];
:@subrimpl!2525724383[];
:@dfsubrimpl!2525730911[];
:@ftpsubrimpl!2525725186[];
BringOverImpl: CONTROL == @bringoverimpl!2525724202[];
:@FileTypes!2522009713[];
:@DCSFileTypes!2475178361[];
LET [* : Segments, * : Streams] == @PilotSSImpl!2520555588[];
:@FTPPrivateDefs.Bcd!2517775557;
LET [* : TimeExtra, * : FTPDefs, * : FTPPrivateDefs] == @FTPUser.config!2513699370[];
]
An Example (Using the OPEN facility)
We also have an OPEN clause that forces the contents of a list of variables visible "without qualification". This way the standard versions of, say, Pilot definitions files are represented compactly in a separate file. We shall provide a default list for Cedar systems files.
Consider three files, TypesOnlyFile.Model, RunTimeFile.Model, and BringOver.Model:
-- File: TypesOnlyFile.Model!123, last edit January 15, 1981
-- these are Defs files that have no implementors
TypesOnly: [
:@Environment!2495152852;
:@MiscAlpha!2513637024;
:@Mopcodes!2513636996;
:@System!2512510255[];
:@Ascii!2513637266;
:@Format!2512400637[];
:@SDDefs!2513637152;
:@oiscptypes.Bcd!2517762425;
:@PupTypes!2505871727;
:@drivertypes.Bcd!2517762434;
:@specialsystem.Bcd!2517762334;
:@BufferDefs!2517697345[];
];
-- File: RunTimeFile.Model!456, last edit January 15, 1981
-- these are Defs files that have implementors
RunTime: [
:@Exec!2522073848[];
:@String!2505079728[];
:@Time!2511811906[];
:@TTY!2514228782[];
:@Heap!2512678088[];
:@Inline!2495146094[];
:@Runtime!2514412201[];
:@Storage!2510096576[];
:@FileStream!2511989735[];
:@File!2508166537[];
:@Space!2511801733[];
:@Stream!2512514215[];
:@Transaction!2508440429;
:@Directory!2517693769[];
:@PupDefs!2512420106[];
:@AddressTranslation!2514904448[];
:@Process!2517520325;
:@ByteBlt!2495146082[];
:@PupStream!2505266177[];
:@NetworkStream!2517522491[];
:@Volume!2512677128[];
];
-- File: BringOver.Model, last edit January 15, 1981
-- this defines a variable, TypesOnly, composed of TYPES with no implementors
OPEN @TypesOnlyFile.Model!123;
-- now open the variable defined in TypesOnlyFile.Model
OPEN TypesOnly;
-- this defines a variable, RunTime, composed of TYPES with implementors
OPEN @RunTimeFile.Model!456;
Model: PROC [RunTimeImpl: RunTime] RETURNS [] [
-- open the variable defined in RunTimeFile.Model
OPEN RunTime;
-- open the parameter to this model
OPEN RunTimeImpl;
:@comparse!2525717737;
:@cwf!2525492185;
:@PilotSegments!2518448715[];
:@PilotStreams!2516815806[];
:@dfsubr!2525730916[];
:@FTPDefs!2512420505;
:@ftpsubr!2525724306[];
:@subr!2525723589[];
:@TimeExtra!2505158646[];
:@comparseimpl!2525717709[];
:@cwfimpl!2525492790[];
:@subrimpl!2525724383[];
:@dfsubrimpl!2525730911[];
:@ftpsubrimpl!2525725186[];
BringOverImpl: CONTROL == @bringoverimpl!2525724202[];
:@FileTypes!2522009713[];
:@DCSFileTypes!2475178361[];
LET [* : Segments, * : Streams] == @PilotSSImpl!2520555588[];
:@FTPPrivateDefs.Bcd!2517775557;
LET [* : TimeExtra, * : FTPDefs, * : FTPPrivateDefs] == @FTPUser.config!2513699370[];
].
DesignModel Conversion Aid
If you have a .Config file for a Cedar system and would like to convert to modelling, and this .Config does not need the parameterization facilities of the Mesa Binder, then DesignModel will take that list of implementation modules and produce a fully-qualified model for you to start with.
To the Cedar Executive, type
> DesignModel Impl1 Impl2 ... ImplN
where Impl1.Bcd, Impl2.Bcd ... ImplN.Bcd are the implementation modules of your system. DesignModel will then analyze each .Bcd and build a model. It will also analyze each .Bcd your modules import, export, or otherwise reference. Any module that exports nothing is presumed to be a CONTROL module. (Obviously this can omit some modules that should be CONTROL modules). When possible it will put in the file server or directory for the file you want, using the RemoteFileName property that BringOver adds, if not, you’ll have to edit them in. It always supplies the create dates, however.
DesignModel produces a model on the file "NewModel.Model". It takes one option: the /m switch, which is followed by a file in which to write the model (rather than NewModel.Model.) For example
> DesignModel /m ParserPack.Model Impl1 Impl2 ... ImplN
will write the new model on ParserPack.Model.
References
[Compiler1]
Ed Satterthwaite, "Mesa 6.0 Compiler Update," section on "Directories," filed on [Iris]<Mesa>Doc>Compiler60.Press (and *.Bravo).
[Compiler2]
Ed Satterthwaite, "Mesa 6.0 Compiler Update," section on "Implicitly Imported Interfaces," filed on [Iris]<Mesa>Doc>Compiler60.Press (and *.Bravo).
[FastTurnaround1]
Mark Brown, "Fast Turnaround in Cedar," CSL Notebook entry, filed on [Indigo]<CSL-Notebook>Entries>80CSLN-0017.Press (and .Bravo).
[FastTurnaround2]
Paul Rovner, "Fast Turn-Around for Cedar, Phase 1," CSL Notebook entry, filed on [Indigo]<CSL-Notebook>Entries>81CSLN-0022.Press (and .Bravo).
[FileSystem]
David Gifford, "On the Coexistence of System Modelling and Directories," CSL Notebook entry, filed on [Indigo]<CSL-Notebook>Entries>81CSLN-0060.Press (and .Bravo).
[RTModel]
Paul Rovner, "The Cedar Runtime Model," CSL Notebook entry, filed on [Indigo]<CSL-Notebook>Entries>81CSLN-0034.Press (and .Bravo).
[SystemModels]
Butler Lampson, "System Modelling," May 13, 1980, filed on [Indigo]<CedarDocs>Modelling>ModelsNow.Press (and .Bx).
[ThesisProposal]
Eric Schmidt, "Controlling Large Software Development in a Distributed Environment," CSL Notebook entry, filed on [Indigo]<CSL-Notebook>Entries>81CSLN-0028.Press (and .Bravo).
Appendix A
Criterion for Replacement
(This is a summary. Refer to [FastTurnaround2] for motivation for these restrictions.)
These conditions must hold for an already-loaded module to be replaced by a new version:
1) Every top-level procedure defined in the old version must have the same name and type in the new version. Additional top-level procedures may be added.
2) The global frame of the new module can increase in size by a small number of words, but each of the original variables must be defined with the same name, type, and location in the global frame of the new module. This means that the addition of extra global frame variables is likely to prevent replacement of the module since the compiler rearranges global frame locations according to usage. If more than one variable’s location has been changed, the compiler only gives a warning message for the first one.
3) Neither of the versions can have any string literals, e.g. "foo", or string bodies, e.g. ’STRING ← [30]’, in the global frame. This means that every string literal used in a procedure must be followed by ’L’, e.g. "foo"L, in the module, and no string literals may be present in the start code of the module.
4) PUBLIC types cannot be changed in the new version. Additional types may be added.
5) The number of atoms and rope literals in the new module must be the same as in the old module.
6) There cannot be any local frames (e.g. local procedures) in use by another process at the time when replacement is attempted.
7) The module is not replaceable if it was copied using the Mesa language construct NEW (i.e. has a copied global frame) or is part of a packaged .Bcd (or, equivalently, has a shared global frame.)
8) The module is not replaceable if it is part of a .Bcd produced by the Binder and loaded by the modeller.
9) The number of global frame indices required by the new version cannot be greater that the number used by the old module. (A Mesa module uses one GFI for each group of 32 entry points. Roughly speaking, each public or private procedure, signal, or error counts as one entry point.)
10) Modules that are directly imported by other modules are not replaceable.
11) Variant records and any MACHINE DEPENDENT variables have "painted" types. Any module that declares a variable in its global frame with such types is not replaceable.
Pushing LoadWithRepl! will only load modules compiled by CompileWithRepl! that are replaceable. The new modules will NOT be STARTed.
Appendix B
Current Limitations and Bugs
o The Tioga editor is not connected to the modeller; Notice operations must be done manually.
o The ModelsNow MergeModel algorithm has not been implemented.
o The DF Files/ ReleaseTool concept of release and working directories should be implemented as parameterization of the model. The "Exports" concept of DF files should be implemented in the modeller by pre-computing information about RETURNs of nested models.
o Pre- and post-processing using PGS, MakeBoot, etc. should be supported.
o Dependency on non-program files (such as .cm and .Bravo files) should be expressible in the model.
o The modeller should use Cedar for its internal data structures. It should use Cedar Viewers, rather than Tajo Windows, to interact with the user.
o When the model the modeller is modelling is edited, the modeller should do something.
o The Cedar compiler should give warnings stating the reason a module was not replaceable.
o Multiple module names for Mesa files are not handled correctly. (One is picked).
o The RTModel interface should be implemented. (See [RTModel] for more information.)
(The following will be fixed by a new parser and internal representation.)
o Only one PROC may appear in a .Model file. No syntactic nesting within a single file is allowed.
o Syntax errors may result in PointerFaults as entries in the internal data structures are incomplete.
o The X:Y keyword notation in parameter lists is not implemented. As a result, multiple instances of the same interface cannot be imported by the same module.
o Serious scoping problems exist when default parameters are filled in. The static scoping needs to be more explicit. This would also solve the speed problems associated with filling in defaults.
o The parser is very slow for large models.
o Comments are stripped from the model; new models have no comments.
Appendix C
Semi-Formal Syntax and Semantics
(The following is a summary of the formal semantics in [SystemModels]. Some of the [SystemModels] is quoted verbatim. It is not necessary to understand this for routine use of the modeller.)
Grammar, summary of defaulting rules:
This is the complete grammar. More information can be found in [SystemModels].
Notation for the grammar:
Parentheses are for grouping. Operator precedence is | (lowest), ?, }.
Item | item means choose one.
?item means zero or one items.
{item}sep means one or more items separated by sep (which may be empty).
Terminals are punctuation other than (){}?| and --, or quoted, or in SMALL CAPS.
Subscripts, and from -- to end of rule are comments, not part of the grammar.
exp ::={part}; | {part},
part ::=?id : call | call | *: id | id: * | id* | LET group ?( == call) | OPEN call
id: call declares id; the call specifies type (and perhaps value). All other cases are short for various uses of this.
If id is omitted ( : call), the call must specify a value as a unitId, and its principal part is taken as the missing id.
If id: is omitted, the part is said to be unnamed.
LET group declares each id in the group; the names in the call are ignored, and it is bound to the group by type equality. This is short for individual declaration of the ids, with the proper part of the call, selected with ., for the value of each.
OPEN call is equivalent to LET group==call, where group is the type of the call (which must be a group).
call ::=primary | primary group | primary == call |
call PLUS call | call THEN call |
SELECT call FROM [ {call1 => exp2}; ] -- exp2 whose call1=call
proc[] binds the group to the proc params, evaluates the proc body, and binds this value to the proc result; see : 4.
== only when the primary is a type and the call a compatible value
primary ::=literal | id | unitId | "(" call ")" | primary . id | group |
TYPE ?id | STRING | PROC group ?(RETURNS group)
group ::=[ ?exp ]
unitId ::=@ ?~ location {?* uiPart}. ?(! {digit})
* marks principal part; if it is absent, the last part is principal.
~ marks file as being temporarily only on the local disk.
location ::=?( [ uiPart ] ) ?{uiPart}>
uiPart ::=id | id ↑
Summary of defaulting rules:
Abbr.is short for
*: id idImpl: id
id: * id: TYPE, idImpl: id
id * id, idImpl
OPEN id* OPEN id, OPEN idImpl
:@NameName: TYPE == @Name.mesa, where Name.mesa is a Definitions module.
:@NameImplNameImpl: Name == @NameImpl.mesa, where Name is exported by NameImpl.
If actuals for all parameters are omitted, variables are supplied with the same name as the formals.
A variable in the modelling language may have type STRING,, TYPE id, PROC ..., or have a list type (i.e. an expression involving a list of the other types.)
A model is a nested set of expressions. An expression is a list of parts,
name: type == value
Sometimes the type may be omitted, and the type inferred from the value
name: value
The most common values are filenames preceded by @. These values are calls, in which the primary is a procedure (e.g. Foo[], where Foo is a variable of type PROC ... and has been defined previously) or a type, e.g.
(PROC[X: TYPE] RETURNS [V: TYPE])[]
where the procedure type is declared in the file listed after the @. This file defines a derived procedure type as follows:
When the file preceded by an @ is a Definitions module, "DIRECTORY X: TYPE X1" in the file adds a parameter to the proc type of "X: TYPE X1". ("DIRECTORY X;" is is a parameter "X: TYPE X" to the proc type. FROM clauses in DIRECTORY statements and imports to Definitions modules are ignored.) Such a Definitions file defines one or more variables of type TYPE Mod, where Mod is the module name. Thus @file.mesa where file.Mesa is
DIRECTORY X: TYPE X1;
Mod1, Mod2: DEFINITIONS IMPORTS X = {
produces an implied proc type of
(PROC[X: TYPE X1] RETURNS[Mod1: TYPE Mod1, Mod2: TYPE Mod2])
When the files preceded by an @ is an implementation module, its directory entries are treated exactly as in the definitions module case. "IMPORTS Y: X" corresponds to a parameter Y: X in the proc type. ("IMPORTS X" becomes XImpl: X in the proc type.) "EXPORTS Y" is treated as a returned value YImpl: Y in the model where Y is the name of the corresponding TYPE (e.g. Y: TYPE Y1 in the parameter list.)
Finally, an implementation module defines a type for its global frame and an instance of that type. Thus @FileImpl.Mesa, where FileImpl.Mesa is
DIRECTORY X: TYPE X1;
Mod: PROGRAM IMPORTS Y: X EXPORTS X = {
becomes
(PROC[X: TYPE X1, Y: X] RETURNS[Mod: TYPE Mod, ModImpl: Mod, XImpl: X])
These derived procedure types can be applied to argument lists to yield values when the model is "executed." Execution is defined as follows: The modeller applies the procedure type to its arguments and produces a (list of) value(s). If the procedure type is from a Definitions file, this value has type TYPE Mod, and is represented as the 48-bit version stamp of the .Bcd produced when the Definitions file was compiled with the given parameters. If the procedure type is from a implementation file, the .Mesa file is compiled and loaded (if necessary) yielding a 48-bit version stamp for the module’s TYPE, a POINTER TO FRAME for the module instance, and a set of pointers to interface records, one for each exported interface.
As a convenience, the compilation and loading phases are separated out. The compilation phase computes the values of all the TYPE’s (by running the compiler to produce valid .Bcd’s). The loading phase takes these .Bcd’s and loads them to produce the other variables (interface records and pointers to frames).
These execution phases are the only form of execution presently available. Presently, values with proc type that do not fit with "compiling" and "loading" are not allowed. More precisely, the result types for @-values that end in ".Mesa" or ".Config" cannot be procedure types, they must be interface types and instances and lists thereof. This will eventually be relaxed.
Storing Analyzed Models
(Nothing described in this section has been implemented.)
Models may be pre-analyzed and "packaged" for later use just as Mesa source files can be compiled and .Config files can be bound. Pushing the MakePackage! button (after StartModelling!) produces a file "name.modelBcd", where name is the name of the current model (without its extension ".Model"). This .modelBcd file contains an encoded representation of the information in the current model and can be stored on remote file servers and used later by other Cedar users.
The .modelBcd file can save time and effort in one of two ways:
1) If the ModelFileName: field of the StartModelling! pushbutton has a .modelBcd file in it, the modeller acts as a simple loader. Pushing StartModelling! and LoadAll! will load the system described by the .modelBcd file. UnLoadAll! will unload it and StopModelling! will terminate the modeller session. Onl thoes four commands will work with such a file.
2) If a model file refers to another model file (e.g. using "@file.model") and a "suitable" .modelBcd file for the inner model is available, the modeller will skip analysis of the .model file and use the results (e.g. exports) of the nested model directly. A .modelBcd file is "suitable" if it was derived from the same version of the .model file listed in the outer model and if it was given the same parameters when it was created.
For example,
-- Outer.Model
X: TYPE Y == @Inner.Model!223454["hello"];
and
-- Inner.Model
Inner: PROC[str: STRING] RETURNS[TYPE Y] [ .. ]
then if file "Inner.modelBcd" file can be found that came from version 223454 of Inner.Model and, when created, was parameterized with "hello", then the value assigned to X in the outer model will be identical to that returned by Inner.Model when the .modelBcd file was created by pushing MakePackage!.
Release Procedures
(Nothing described in this section has been implemented.)
Models will be a part of the Cedar release process. Cedar implementors will be required to follow these rules:
1) Each package to be released will be described by a (set of) .Model files and a (set of) .modelBcd file(s). Each file listed in the model (preceded by @) will be parameterized by host and directory names as follows:
... == @[host]<directory>file.mesa!33245;
becomes
host: STRING == IF Released THEN "releaseHost" ELSE "workHost";
directory: STRING == IF Released THEN "releaseDirectory" ELSE "workDirectory";
... == @[host↑]<directory↑>file.mesa!33245;
where Released is a parameter to the outermost PROC of type BOOL.
Those files that are not part of the package are described as above, except the keyword "(Imported)" appears between the @ and the [ before the host, e.g.
... == @(Imported)[host↑]<directory↑>file.mesa!22222;
2) The ReleaseTool will copy files from the working to the release directory. .Model and .modelBcd files will also be copied but not altered in any way. Each .model file will be checked for accuracy in file names and versions, parameterization, etc.
3) The OPEN and LET statements may be used to get access to variables defined in other package’s models. Models for commonly used Pilot and Cedar interfaces will be available.
Omissions:
1. The client will have to know both the working and release positions of a package he is working on.
2. The ~= and > functionality of DF files cannot be provided without re-writing the .Models
3. Who constructs the .modelBcd files with Released = TRUE?