Inter-Office MemorandumToCedar InterestDateJanuary 17, 1982FromEric Schmidt, Butler LampsonLocationPalo AltoSubjectCedar System Modelling Reference ManualOrganizationCSLXEROX Filed on: [Indigo]Documentation>ModelRefMan*.Bravo and .PressOutline1. Introduction2. Operational Overview3. Simple Use of the Modeller4. Advanced Use of the Modeller5. Modelling Language6. Implementation Details7. Use from the Cedar Executive8. How to Get Started9. Example of Model10. Other Modelling Tools: DesignModel11. References12 Appendices:A. Criteria for ReplacementB. Current LimitationsC. Semi-Formal Syntax and SemanticsIntroductionThe Cedar system modelling facilities are a complete system for maintaining and manipulating bothsmall and large collections of Cedar modules. The Cedar programmer writes Cedar system models,which describe systems in terms of their interfaces (DEFINITIONS modules) and their implementations(PROGRAM modules). In these models, the programmer 1) specifies how his modules interconnect, 2)instructs the modeller how to compile his system, and 3) identifies files by unique version numbers.When the user first starts the modeller on a particular model, the modeller insures that those filesreferenced by the model are on the disk.The modeller keeps track of source and object files and tries to automate part of the usual edit-compile- debug- edit- cycle. As the programmer makes changes, the modeller records which files havechanged. When instructed by the programmer, the modeller will compile all the files the programmerhas changed, and any that depend on files changed, and then will load and start the compiled objectfiles. In many cases using the modeller for these tasks will be faster than using the Binder andconventional Loader since the modeller can replace old versions of modules with newer ones "on thefly" without re-loading all modules in a system.This memo describes a preliminary version of the modeller. Current limitations are described inAppendix B. Please send comments on the implementation to Schmidt.PA, and comments on thedesign to Schmidt.PA and Lampson.PA.]gpi c8q]rX -q7Br ]q]r-q7Br Yq]r'-q 7BrSsr MD Jt Gr F$ D C A @ > =  ; :& 8 6 5x32p# /Dt ,r)8 *.#u r )5q r# 'qr+. & S $>& #( =$ %O c ;( (9 B 0 900 7# 1$J@WCedar System Modelling Reference Manual2Operational OverviewSystem models are represented as text files that conform to a syntax described in section 5. Roughly,they correspond to "decorated" .Config files containing more information than can be expressed inC/Mesa.Programmers must create a model to begin with. Some simple models can be generated by hand, butothers may be very complicated. Section 11 describes a conversion aid called DesignModel that willgenerate models from .Bcd files.Given that a system model (or set of them) has been generated by hand or generated by DesignModel,a modeller can be run on this model. While being run relative to a model, the modeller follows editsto files and provides automatic compilation and loading facilities, including the ability to replacemodules in an already loaded and running system. The modeller presents itself as a Tajo window(tool), whose topmost subwindow contains useful pushbuttons and fields for fill-in. The next twosections describe the functions of each pushbutton (and associated files), roughly in the order of theiruse. Under certain conditions, the modeller can replace a loaded module by a new version in an already-loaded and running system. This facility, called module replacement, can avoid the uneccesary re-loading of other modules in a system and provides fast turnaround for small program changes. Since the modeller may only model one nested set of models at a time, more that one modeller maybe run concurrently as long as they model disjoint sets of models. Complete information about thisand module replacement is found in section 4. Details about the implementation of certain loading and parameterization problems (present in thesystem for historical reasons) are discussed in section 6, along with information about an internal database.The modeller window can be controlled from a command file as well as from pushbuttons. This isdiscussed in section 7.This memo concludes with a list of limitations in the current, unfinished version of the modeller andan extended example. References (e.g. [FastTurnaround1]) are listed at the end of this document.Simple Use of the ModellerStartModelling!When started, the modeller will display a Tajo tool window as shown in Figure 1. Before any of itsfeatures can be used, the modeller must be given a model file (hereafter called the current model). Thename of the current model is entered following FileName: on the first line of the window. Push theStartModelling! button to begin modelling the current model.StartModelling! will force the modeller to initialize itself and prepare to track changes to files in themodel. To do this, it will read in the current model and analyze the model as follows:1) Each file involved in the model is described by a remote host and directory where the filemay be found, and a unique identifying number. (Currently the file's creation date.) If the currentmodel refers to a source file that is not on the local disk the modeller retrieves this source fileto the local disk. If a copy is on the local disk already, StartModelling! does not retrieve the remote versioneven if the create dates of the local copy and the date in the model do not agree. It will also retrieve a similarlynamed .Bcd file from the same directory, if one is not on the disk..2) It scans all the sources and fills in any defaults left unspecified in the current model.3) It checks the parameters to the source files for accuracy. fr'G bt ^r=) ]nO [ YI XD V T33/ Re Q+Q O>! N#S LY K H U G?2ur ES CcS AX @[. >3. <71 : 8E 7 4X 3CG 0t ,u (r=& 'iTu r %/ur' $aur, " ur%4 W.%8 "q&r&Rq+vrq$AS"CrI1= @V!KCedar System Modelling Reference Manual3Notice Operation After the StartModelling! command completes, the modeller is ready to track changes to files listed inthe current model. The Tajo editor (by default) will be connected automatically to the modeller sothat, whenever a Store or Save command is given to the editor, the modeller will be notified. If thefile is listed as part of the current model, the modeller will perform a notice operation on the newerversion of the file by adjusting its internal tables accordingly. To do this, the modeller will analyze thenew version to see if any of its DEFINITIONS, etc. have changed. At this point the model file on thelocal disk refer to older versions of these files. (The changes to the model may be too extensive forthe modeller, and the model may need to be hand edited.)CompileWithOutRepl! After changes have been made the modeller will compile modules that have been edited and then willcompile any files that depend on those that were edited, and so on until all files that need to becompiled or recompiled have been. (Should there be compilation errors, further edits should be made,and CompileWithOutRepl! should be pushed again.)The modeller will ask before confirmation before compiling a module. Typing 'y' or CR in answer tothe question will proceed with the compilation, typing 'n' will skip this compilation and proceed toothers, and typing 'q' will quit the compilation phase immediately.The modeller will "guess" a plausible .Bcd filename for each source file mentioned in the model andlook for such a file. If it finds one, it checks the .Bcd to make sure it came from the source file themodeller has, and was compiled with the same compiler switches and TYPEs in its DIRECTORYstatement. Eventually this information will be kept in a Cedar database.Before compiling anything the modeller will store a new version of the model on the local disk. Thisnew model will refer to the latest versions of files that have been noticed by the modeller.LoadAll! The modeller is able to run object files produced by the compiler. This must be done in two steps (1)loading the .Bcd files into memory, and (2) STARTing the CONTROL modules. When LoadAll! ispushed, the .Bcd modules for the files listed in the current model are loaded and all referencesbetween modules are resolved.StartAll! Once loaded, any CONTROL modules (in the current model, see below) may be STARTed by pushingthe StartAll! button. StartAll! can be pushed once per completed LoadAll!, and starts only thosemodules loaded by the last LoadAll!UnLoadAll! The loaded modules may be unloaded and resources reclaimed by pushing UnLoadAll!. Once this hasbeen done, any reference to the formerly loaded programs will almost certainly result in anAddressFault or StackError, since the global frames and code segment spaces have been invalidated. fr'G bu _r ur($ ^Bc \G [:Iur Y b X2!q r2 VQ U*8 Q+u MrC L{L JU Isur G:) EY DC AJ @7G! >#qrq =/rq?r :e 9T\ 5Uu 2)rW 0qrqrur /! U - )u &srqr2qr $ur u r!u r #ju k @r=u r   Q 8,6 @ ?O!Cedar System Modelling Reference Manual4StopModelling! Pushing StopModelling! terminates the modelling on the current model. The modeller will offer towrite out a new version of the model it is current on if recent edits have notified the modeller of newversions of files in the model. StopModelling! should be preceded byUnLoadAll!. If UnLoadAll! isnot given, the loaded bcds remain loaded, and may not be unloaded after the StopModelling! button ispushed. StopModelling! may be followed by StartModelling! on another model.Other Modeller PushButtonsAttachEditor:CompileWithRepl!LoadWithRepl!MakeModel!SetWorkingModel!These are described in the next section, "Advanced Uses of the Modeller."Permanent! CompileWithOutRepl! does not copy changed files out to the remote servers, so some of the filenamesin the current model will refer to local, not remote, files. When you want those files transferred, pushthe Permanent! button to store the new versions on the remote server(s).Temporary! To force the modeller to save the model you've been current on, but not to transfer files to remoteservers, push the Temporary! button. This command acts like a checkpoint command and will producea new version of the model, annotated to show any new versions of files only on the local disk. This isprimarily intended for protection against crashes of Cedar or the modeller.Notice! If you need to include new files that were not created under the modeller's control, such as newversions of system files, you may explicitely invoke the Notice processing by inserting the name of thefile to be noticed after FileName: on the Notice! line, and pushing Notice!. (If an extension isomitted, ".Mesa" is assumed.) The modeller will process this explicit Notice operation just like itprocesses those generated by the editor.NoticeAll! NoticeAll! can be used to let the modeller look for any new versions of files referred to in the modeland do an automatic notice operation on them. This should be used with care, in case standard system files havebeen edited by mistake. fr'G bu ^ru r/ur ]n \ [u ru ru r Zf-u r Xururur T Qu r P4u N M, K H|rI D}u ARrG ?"G >Ju r9 :Ku 7r[ 5u rE 4>#q 2K .u +ir U )9ur  (`ururur &Gur %X( !Yu . rU $ qA I &?LCedar System Modelling Reference Manual5Type (w/o defaults)!, Type (w/defaults)! The modeller keeps an internal description of the current model, which may differ from the model fileif notice operations have been performed. Pushing either Type...! button will print the internal copy ofthe model.Confirm: {TRUE, FALSE} CompileWithOutRepl! (or CompileWithRepl!) normally pauses to ask the user to confirm thecompilation of a file. This gives the user control over the modeller. If FALSE is selected, then the modellerwill compile files without pausing for confirmation.Deactivate! Deactivate! will make the modeller tool inactive and remove the tool window from the display.In a typical session, you'd start with the StartModelling! command, make a few edits, and then givethe CompileWithOutRepl! command to generate the new model and compile everything. You couldthen go ahead and make more changes, push CompileWithOutRepl! again, and so forth. Whenever thefiles are worth saving on remote file servers, you'll push the Permanent! button. Finally, pushStopModelling! to shut down the modeller.You should not invoke the Compiler or Binder directly during this session. If you do, you'll need toStartModelling! again since you may interfere with the modeller's cache of information.The modeller could compile programs in the background, but this could result in a great deal of erroneous re-compilation ifyou were changing sets of interdependent modules.Advanced Use of the modellerModule Replacement (CompileWithRepl!, LoadWithRepl!) Programmers may want to make a minor change to an already loaded and running system. When themodeller is used in replacement mode, modules may be replaced without losing any global state andwithout unnecessary reloading, subject to certain restrictions. (See [FastTurnaround1] and[FastTurnaround2] for more information.)For example, suppose TreeImpl.Bcd has been loaded as a part of Parser.Model, and the model hasbeen started. Suppose TreeImpl.Mesa (the source for TreeImpl.Bcd) has an erroneous statement"X_1;" that should be "X_2;", and X is declared local to some procedure in TreeImpl.Mesa. Tomake change this statement without reloading the entire system, the programmer would proceed asfollows:1) The programmer edits TreeImpl, alters the assignment statement, and saves the new version.The modeller then notices the new version. 2) The user then pushes CompileWithRepl!, which is identical to CompileWithOutRepl!, exceptthe compiler is invoked with instructions to check that TreeImpl.Bcd is replaceable. Thecompiler is given information about the old version of TreeImpl.Bcd to make this check. If there is no olderversion, CompileWithRepl! and CompilerWithOutRepl! are equivalent.. 3) If the compiler reports that the module is replaceable, the user may push LoadWithRepl! toreplace old code for TreeImpl with the new code containing the corrected "X_2;" instruction.TreeImpl will not be STARTed a second time and initialization of global variables in TreeImplwill not be repeated. fr'G bu* ^rV ]nur& [ Wu vuvu Trur0 S<q.rqr Q4 Mu J r8 Eur) D7urE Bur" A.?u r ?ur <%@ :urG 7q?< 61 3t /u6 ,rL *a ){TEU '( %%9 $)4 "Z !E 7Lq*r[urur2$qSVrqvqvqrwGu r?oqr#  ?Zg;Cedar System Modelling Reference Manual6In general, the modeller and compiler will try to replace any module which is compiled and loaded inreplacement mode (i.e., with CompileWithRepl! and LoadWithRepl!) Refer to Appendix A, "Criterionfor Replacement," for a summary of (current) limitations of module replacement.The old .Bcd file remains loaded until there is a successful compilation in replacement mode, and thenew version is replaceable. The modeller may need to rename the old .Bcd: If there are errorscompiling the new version and no new .Bcd is produced, the old .Bcd is not renamed by the modeller.If the compilation succeeds then the old .Bcd will be renamed, regardless of replaceability (byappending a digit, e.g. TreeImpl1.Bcd). Therefore, pushing LoadWithRepl! will load the new .Bcd if itis replaceable, and UnLoadAll! followed by LoadAll! will always load the new .Bcd, along with all theother modules in the current model.Nested Models Models may refer to other models (for syntax, see Language section). These nested models define atree of models with the model given to StartModelling! as its root. The editor notice operation,Notice!, and NoticeAll! buttons apply to all files in all the models in this tree. Other commands (suchas Compile...!, Load...!, and Type..!) are model-specific, and use the current working model, which maybe set by inserting the model file name after FileName: on the SetWorkingModel! line and pushingSetWorkingModel! The default working model is the root model and the working model can be resetto the root model by entering the null string after FileName: and pushing SetWorkingModel!MakeModel!MakeModel! takes a model you supply and tries to produce on the local disk a set of .Bcd files readyto be loaded and run. MakeModel! will do whatever is necessary to make the model. If there is a.Bcd already available for the model, it will simply retrieve the .Bcd file. If it has to recompile anyfiles, it will do the minimum necessary. MakeModel! is similar to a sequence of StartModelling! andCompileWithoutRepl! with one exception: If the model describes a file on a remote server with adifferent create time than the create date of the file on the local disk, the remote version is retrieved,deleting the other version on the local disk. No confirmation is requested. Use carefully. MakeModel! maybe followed by other modeller commands, e.g. LoadAll! or StopModelling!AttachEditor: {TRUE, FALSE}When it is started, the modeller arranges to be called when the user saves or stores a file using theTajo editor. More than one modeller may be started, in which case (for implementation reasons) onlyone can be attached to the editor at a time. If for this, or any other reason, you do not want theeditor to notify the modeller of such changes, select FALSE for this field in the modeller window.The Modelling LanguagePhilosophy:The reader should be familiar with these definitions before proceeding:moduleOne per file, there are two kinds: definitions and implementation.interface:Informally used for definitions modules.module name: Each module has one or more module names. fr'G bV `ururur _O \H [:@ YC X2L V(u r U*u rurur& S# Ou L{rD J'ur  Isuru r6 Gu rurur8 Fku rur Dur C Cc4uru ?d <8 r5% :u r/ 90 \ 7u rur 6(urE 4P 3 -q,ru r 1-uru -vuvu *rre (40 'i&= %6qr "t u rG durB u r( u rU) B @YRCedar System Modelling Reference Manual7interface type: An specific version of a definitions module defining the names and types of procedures, etc.declared in the definitions module. An interface type does not specify any values for theobjects it define, so no association between procedure declarations in definitions modules andtheir code is possible. Standing alone, a .Bcd for a definitions file is an interface type.interface instance or record: A record containing values of items declared in an interface type, such as pointers to the codefor procedures, etc. Some implementation module has to provide these values.imports and exports: An interface instance is created by an implementation module EXPORTing the interface. Theprocedures, etc. exported by the implementor can be used when another module IMPORTs theinterface. (Actually, it imports the interface record.)To understand the Modelling language, the reader must first understand some features of the Mesalanguage. Most Mesa modules (Definitions and Program) have a DIRECTORY statement which definesat compile time which Definitions modules will be available for declarations, etc. If the client of aDefinitions module listed in the DIRECTORY statement wants to invoke a procedure defined in theDefinitions module it must also IMPORT an instance of that Definitions module. (It actually imports aninterface record, which usually contains pointers to procedure bodies in other modules.) Theseinstances must in turn be EXPORTed by some other, implementing, Program module. Thecorrespondence between exporters and importers is usually set up by the Binder, not the Compiler. Inwhat follows, we merge the information about which interfaces to use (i.e. which Definitions files touse) and which instances of those interfaces to use (i.e. which instances to import). We will think of aDefinitions file as defining a TYPE, much in the same way as a RECORD declaration. In the Modellinglanguage you can declare a variable Foo of type TYPE (i.e. an interface type), and then declare avariable FooImpl of type Foo (FooImpl is an interface record). We can give FooImpl a value from amodule that exports Foo.The modelling language is similar to Mesa and replaces the Binder's C/Mesa language. An applicativelanguage, it has no assignment operator, so bindings are similar to procedure calls.Small Model Example:StreamT: TYPE Stream == @[Indigo]StreamDefs.Mesa!223456;FileAndStream: PROC[StreamInst: StreamT] RETURNS[CommonInst, FileInstance] [Common: TYPE == @[Indigo]CommonDefs.Mesa!654322;CommonInst: Common == @[Indigo]CommonImpl.Mesa!224536[Common];FileT: TYPE File == @[Indigo]FileDefs.Mesa[Common];FileInstance: FileT == @[Indigo]FileImpl.Mesa[FileT, StreamT, StreamInst]]The Language:A model is a list of expressions. One of the expressions should be the declaration of a procedure(PROC) which contains the implementing modules. Any other expressions are treated as global andserve to define commonly needed interfaces. This procedure takes parameters and returns results.These parameters are usually instances of the Pilot runtime environment, but may also be strings (e.g.compiler switches and host names, etc.) This procedure can return any value passed in or declared inthe body of the procedure. The language obeys normal scoping rules and PROCs can be nested insideother PROCs, etc. There should be one outermost procedure, however. Just like C/Mesa's nestedconfigurations.In the example model, each line is an expression that defines a variable in the modelling language.The outermost (and only) PROC in the example is named "FileAndStream." fr'G bu r`I_$6]L\D XurW^#<UM RurQ+=qrO=qrN#8 J#W H6qr G15 E!qr% Dqr> B4+ A "qr# ?S >P <?* :qrqr  9w0qr- 7U 6o 4$@ 2T .u +irqr2 )qrqr(`qr+&E%Xqr/#P"P Qu &r V qr4& Y )= K Hqr  qr1 q  r ^O qr)T @\xeCedar System Modelling Reference Manual8TYPE declarations:Each variable in the modelling language has a type. Types can be conventional, e.g. a variable mayhave type STRING or PROC, as in Cedar, or specific to modelling, e.g. a variable may have type "TYPEMod", where Mod is a module name. In the modelling language, a variable of type TYPE Mod can begiven a value (by "==") that is a definitions module with "Mod" as a module name.In the example, StreamT: TYPE Stream == @[Indigo]StreamDefs.Mesa!223456;defines a variable "StreamT", whose type is "TYPE Stream" and whose value is the definitions fileStreamDefs.Mesa. "StreamT" obeys normal scoping rules and is subsequently used in the model toprovide this interface to every module that needs it. The host and directory after the @-sign give ahint as to the file's location, and the decimal number following the '!' is the files create-date whichserves to uniquely identify it. The file location is a hint since ANY file with the same unique-id isacceptible, although in practice the modeller will only look on the local disk and the location listed inthe model for this file. (It is conceivable these creation dates may not be unique, but they're the most-unique identifiers we have at the moment. We are working on a better scheme.)When the variable name and module name are equal, the name after TYPE can be omitted.Common: TYPE == @[Indigo]CommonDefs.Mesa!654322;defines a variable "Common" in the model whose type is "TYPE Common", and whose value is thatversion of CommonDefs.Mesa. It is important to remember that Common is not a variable of typeTYPE, it is a variable of type "TYPE Common", a more restrictive set of values. (In the modellinglangauge, no variable can have type "TYPE", they all have type "TYPE Mod" for various module names"Mod.")Instance declarations:An instance expression defines one or more instances of interfaces, which the program modules importand export. These expressions take parameters which define 1) which interface types to use whencompiling, and 2) which interface records to pass to the module as its IMPORTS (i.e. what the Binderdoes now.) For example, a module CommonImpl.Mesa that exports an instance of the interfaceCommon, imports nothing, and had one DIRECTORY entry which was an interface named "Common"could be expressed asCommonInst: Common == @[Indigo]CommonImpl.Mesa!224536[Common];This expression defines CommonInst, a variable in the modelling language, to be of type Common.The value of this variable is an interface instance (or interface record), exported by the file"CommonImpl.Mesa," which itself has one DIRECTORY statement entry for Common.Program modules also have to import instances of various interfaces. The required instances can bespecified as parameters to the program module just as the TYPEs are. For example, a program modulein the file FileImpl.Mesa, which imported an instance of Stream and exported an instance of File,would have as parameters both TYPEs (i.e. both Definitions files to use) and also an instance of Stream,named StreamInst in the example. SoFileT: TYPE File == @[Indigo]FileDefs.Mesa[Common];FileInstance: FileT == @[Indigo]FileImpl.Mesa[FileT, StreamT, StreamInst]defines an instance of an interface of type FileT, exported by FileImpl.Mesa.In the example, StreamInst is not given a value in the model. However, it is declared in the parameterlist for FileAndStream and will be given a value (from outside this model, e.g. the Pilot load state)when the model is loaded. fr'G bvu ^r_ ]n qrqr > [Bqr ZfQ W;Tqr2 R-qr $ QN OO MK L{Cqr JC& IsA) GN EAqrC@qr+ @"qr! ?d T =qrqrqr <\qrqr : 6u 4rUqr 2 qr= 1y?qr /1* .q%qr ,*E (=.1 &E %5(qr "#qr. !Y&qr% A Qqrqr $uqr/P M B>) C" : @W^Cedar System Modelling Reference Manual9Parameters:The order of parameters is not significant. Modules may take two kinds of parameters: TYPE andinstance variables. The modeller matches up values on the parameter list (actuals) with thecorresponding formal, according to these rules:In a Mesa file, a Directory statement likeDIRECTORYStream;is an abbreviation forDIRECTORYStream: TYPE Stream;where the Stream on the left is the name of the interface in the Mesa source file, and it can bematched with any Definitions file (on the local disk) with module name "Stream" (indicated by"Stream" after TYPE). More generally,DIRECTORYDefs: TYPE Mod;requires that whichever Definitions file is matched with Defs have module name "Mod." (See[Compiler1] for more documentation on the TYPE construct in Directory statements.) When analysinga source file with such a Directory statement, the modeller matches any parameter with type "TYPEMod" to the corresponding entry "Defs" in the Directory statement. (In the example, any parameter withtype TYPE Stream will match Stream in the Directory statement.). The FROM clause allowed in Directory statements is ignored. Therefore.DIRECTORYStream: FROM "somefile.bcd";is treated by the modeller as if it wereDIRECTORYStream: TYPE Stream;In Mesa files, an IMPORTS statement likeIMPORTS Stream =is an abbreviation forIMPORTS Stream: Stream =The general case is IMPORTS Name: Defs, where Name is the name used to reference procedures, etc.defined in the Definitions file connected to "Defs", defined in the modules Directory statement. Inthe modelling language, "IMPORTS Name: Defs" is matched to any modeller variable with whichevertype was matched to "Defs." That is, the interface instance variable has the same type as that matchedwith the Directory entry for "Defs."Keyword Notation:When two parameters have the same type (e.g. two definitions files with the same module name or twointerface records from the same interface) keyword notation must be used to disambiguate thereferences. For Directory entriesDIRECTORYDefs1: TYPE Mod,Defs2: TYPE Mod;the model will have to specify which type variable to match with Defs1 and Defs2 using keywordnotation, such as fr'G bu ^rVqr ]nI  [/ Y*W;qUr S_QqOrqr M,V K Q J#qrGqFHrqr C8$ Bl*qr$ @ Pq ?drCq# =@r ;qr?90q7rqr 5U(2q1yrqr /!qr,qr *r(qr %qrE $>E "qr4 !6W $ u [r&= ;! S"qrqr:qr @ ^ ?Z"Cedar System Modelling Reference Manual10== @ParserImpl.Mesa[Defs1: File1, Defs2: File2];in the parameter list after the file listed in the model, where File1 and File2 have type "TYPE Mod."For Imports,IMPORTS Instance1: Defs, Instance2: Defs =the model will have to specify which interface to match in the parameter list, e.g. == @ScannerImpl.Mesa[Defs: Stream, Instance1: Actual1, Instance2: Actual2];in the model, where Actual1 and Actual2 have the type matched with Defs (in the example, this isStream).LET clauses:Some modules may export more than one interface record. For these cases, the LET statement declaresmultiple variables exported by one module. For example, if YImpl.Mesa exported Y and Z, we couldwriteLET [YImpl: Y, ZImpl: Z] == @YImpl.Mesa[X, Y, Z, ZImpl];to define an instance of Y as YImpl and Z as ZImpl. The elements in the LET clause may be writtenin any order. (In the modelling language the file following the @-sign can also be a model, in whichcase the LET declares variables that the model following the @-sign RETURNs).Definitions modules with more than one module name may declare two variables, each with a differentTYPE, using a LET statement. For example, if Defs.Mesa looks likeMod1, Mod2: DEFINITIONS = { ... }.then in the modelLET[X1: TYPE Mod1, X2: TYPE Mod2] == @Defs.Mesa;will define two variable with the TYPEs for each of the module names Mod1 and Mod2 in "defs.mesa".Of course, if the variable names are equal to the module names then the module names after TYPEmay be omitted, e.g.LET[Mod1: TYPE, Mod2: TYPE] == @Defs.Mesa;CONTROL modules and compiler parameters:After files listed in the model are loaded, the user may want some of them started. (These modules arecalled CONTROL modules in C/Mesa.) Any (program) module which must be started by the modellerloader should define a dummy variable, of type CONTROL (it doesn't matter what the variable's name isas long as it is unique). For example:LET[Odd: CONTROL, XImpl: X] == @XImpl.Mesa[X];declares both XImpl, an instance variable of type X, and that this module should be STARTed whenthe user instructs the modeller to start the loaded system.Compiler parameters (such as bounds-checking) can also be specified (as a string parameter to theprogram module after the @-sign). Switches don't matter for Definitions files. If not specified, the compilerdefaults are used. We consider this a kludge and are working on a better system. fr'G?b0 _Tqr ]n [qr# XTVgK T5+ R Nvu Kar>qr IC HYFqr5 C =qr B%K @qr8qr >JK  !r@ b X D ZK qr 1.u Rr \ v8q /?QCedar System Modelling Reference Manual13Defaulting ParametersSome or all of the parameters to a file (after @) can be omitted. If the formal appears as DIRECTORYStream;in a Mesa source file, the formal is matched up with a variable declared as "Stream: TYPE Stream==" in the model. More generally, if the formal appears asDIRECTORYVar: TYPE Stream;the formal is matched up with a variable declared as "Var: TYPE Stream ==" in the model. Similarly for interface records,IMPORTS Streamin a Mesa source file is matched up with "StreamImpl: Stream ==" in the model, and IMPORTS Instance: Streamis matched up with "Instance: Stream ==" in the model. fr'G? bu _r;]q\1r Y?qr XU;V!qTrqr Rh(qr PMqr KaSI qr F6 Fk@!dCedar System Modelling Reference Manual14Implementation DetailsImplicit DIRECTORY EntriesThe Cedar and Mesa 6 compilers may produce object files for DEFINITIONS modules that haveincomplete information about types in their symbol segments. The missing information is available inother .Bcd files, which are called hidden directory entries since a client of a definitions module mustalso have these definitions modules present on the local disk to compile his program. Such hiddendependencies do not appear in the parameter list of any @ file in a model. However, when compilinga module that needs to reference such .Bcds, the modeller will print an error message if it cannot findan entry that satisfies the reference to the hidden .Bcd in the model.Implicit IMPORTS EntriesIn Cedar and Mesa 6, definitions modules may import instances of other interfaces (chiefly for INLINEprocedure use, see [Compiler2] for more information.) The .Bcd produced for a Mesa program thatimports an interface may also need to import another interface. The additional import is called ahidden import when loaded by the modeller. As with hidded directory entries, these hidden imports donot appear as parameters to the client. When loading the .Bcd for such a client, the modeller willselect any interface record that matches the version stamp of the hidden import to resolve thereference. If no such interface is available, the modeller will give a warning message (and thereferences will remain unresolved.) The Modeller DatabaseA database of information about source and object files is maintained by the modeller. This databaseis 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 thecontents 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 willspeed 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 notbe able to map the database file to the correct address. Should this happen, re-booting Cedar andrunning the modeller immediately thereafter should make re-use of the database possible.Use of the Modeller from the Cedar ExecutiveThe modeller pushbuttons described above can be "pushed" from a command file by executingcommands registered with the Cedar Executive. (Each command is preceded by the letter "X" tomake 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! fp'G? bq ^rsr [p7t p ZCe X#rp W;+7 U30 T3G RF Orsr LXpKt JpL IPV Gr prp: FHc D=! C@ R A% >r ;ep14 9G 8]/8 6F 5U33 3? 1y'< /E .qX (q, $p/* #j-0 !tp$)$r sr p$rp$rp$rsrp $rp$r wp $r p $rop$r  (?XICedar System Modelling Reference Manual15> XPermanent.~Permanent!> XProgramStart.~StartAll!> XSetWorkingModel.~SetWorkingModel!> XStartModelling.~StartModelling!> XStopModelling.~StopModelling!> XTemporary.~Temporary!> XType.~Type!> XUnLoad.~UnLoad!Getting StartedTo retrieve the latest version of the modeller, type> BringOver /p [Indigo]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 OptionsYou may want to edit your User.CM to add a section [Modeller] to your User.CM with someparameters the modeller reads when it is loaded. DefaultModel: followed by a model file name setsthe initial model file name for the StartModelling! file name field, AttachEditor: followed by TRUE orFALSE 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 themodeller is started. These keywords are defaulted as if the User.CM section looked like:[Modeller]AttachEditor: TRUEDefaultModel:Wizard: FALSEAn 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 thatreduce 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). Allthe rest are definitions files.-- File: BringOver.Model, last edit January 15, 1981Environment: 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]; fp'G?b $r `p$r_p$r]p$r\p$r Zp $r Yp$rWp $r TVq Q+p4M7 JG D}%C BI ?r pO )@\Cedar System Modelling Reference Manual16Exec: 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", fp'G? bu) `? _2 ]A \F Z8 Y( WJ U7 TyF R6 QqD O/ Ni, L1 Ka5 IRHY F@ EQ{N C BI* @7 ?AI =F <8:907 6(43 10.-+*('%|+#"s k! c , [" ; Ty1 R; Qq< OC Ni; L% Ka> I? HYD F< EQ% CB BIB @@ ?AE =G <8 :3 90E 7)* 6(< 4? 3 A 1A 0 .7 -+-+ *I (A 'J %|. # "s tptp: tpO latp V d * 1 S \V Pt TpDtp Atp q& ^@Z"Cedar System Modelling Reference Manual18We can omit all the argument lists following @-signs, since the modeller can supply for eachparameter an actual with the same name. (We could not default the parameters if a module importedmore than one instance of an interface.) We can also omit the compiler switches unless they differfrom the Cedar/Mesa compiler defaults. -- File: BringOver.Model, last edit January 15, 1981Environment: 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[]; fp'G? b\ `(: _\ ]& \ Xu4 W^2 U* TV* R. QN, O* NF& L& K>* I$ H6& F* E-2 C& B%( @& ?( =, <, :2 9 * 70 6/ 4, 21 1y5 /2 .q, ,B +i* ), (`0 &8 %X1,#0"P%, MH+A, @; 8 , 0" 3 (1 *  * , & 0 L?\Cedar System Modelling Reference Manual19ComParseImpl: 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 toX: 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 variablesbeing 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[]; fp'G? bu: `+ _. ]4 \7 Z; Y0 W6 UC Ty7 R+-Qq O Ni K>q& HpFD A>tp ;e789 5 1,7 0_tp -3 *u4 ( ' %| # "s  k  c  [  S  K  C  ;  3z ?^Cedar System Modelling Reference Manual20:@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 "withoutqualification". This way the standard versions of, say, Pilot definitions files are represented compactlyin 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 implementorsTypesOnly: [:@Environment!2495152852;:@MiscAlpha!2513637024;:@Mopcodes!2513636996;:@System!2512510255[];:@Ascii!2513637266;:@Format!2512400637[];:@SDDefs!2513637152;:@oiscptypes.Bcd!2517762425; fp'G? bu ` _ ] \ Z Y W" U Ty R Qq OKNi>L4Ka:I HY F EQ C BI @ ?A = <8 : 90 7 6( 4 3 6 1 0 .= - +$1 * &qvq #ptp- "-P t8 }pR Ru< 1 J B:2  * ?](Cedar System Modelling Reference Manual21:@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 implementorsRunTime: [:@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 implementorsOPEN @TypesOnlyFile.Model!123;-- now open the variable defined in TypesOnlyFile.ModelOPEN TypesOnly;-- this defines a variable, RunTime, composed of TYPES with implementorsOPEN @RunTimeFile.Model!456;Model: PROC [RunTimeImpl: RunTime] RETURNS [] [-- open the variable defined in RunTimeFile.ModelOPEN RunTime;-- open the parameter to this modelOPEN RunTimeImpl;:@comparse!2525717737;:@cwf!2525492185;:@PilotSegments!2518448715[];:@PilotStreams!2516815806[];:@dfsubr!2525730916[];:@FTPDefs!2512420505;:@ftpsubr!2525724306[];:@subr!2525723589[]; fp'G?bu`_] \ W^: U. TV RQNONFLK>IH6FE-CB%@?=<":9 7642 .q4 +iM ) (`7 & #H "P H/ 1 @ # 8 0  (       L9}\Cedar System Modelling Reference Manual22:@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 AidIf you have a .Config file for a Cedar system and would like to convert to modelling, and this .Configdoes not need the parameterization facilities of the Mesa Binder, then DesignModel will take that listof implementation modules and produce a fully-qualified model for you to start with.To the Cedar Executive, type> DesignModel Impl1 Impl2 ... ImplNwhere 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 yourmodules import, export, or otherwise reference. Any module that exports nothing is presumed to be aCONTROL module. (Obviously this can omit some modules that should be CONTROL modules). Whenpossible it will put in the file server or directory for the file you want, using the RemoteFileName propertythat 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 ... ImplNwill write the new model on ParserPack.Model.References[Compiler1]Ed Satterthwaite, "Mesa 6.0 Compiler Update," section on "Directories," filed on[Iris]Doc>Compiler60.Press (and *.Bravo).[Compiler2]Ed Satterthwaite, "Mesa 6.0 Compiler Update," section on "Implicitly Imported Interfaces,"filed on [Iris]Doc>Compiler60.Press (and *.Bravo).[FastTurnaround1]Mark Brown, "Fast Turnaround in Cedar," CSL Notebook entry, filed on [Indigo]Entries>80CSLN-0017.Press (and .Bravo).[FastTurnaround2]Paul Rovner, "Fast Turn-Around for Cedar, Phase 1," CSL Notebook entry, filed on[Indigo]Entries>81CSLN-0022.Press (and .Bravo). fp'G? bu ` _ ] \ Z Y6 W U Ty= R Qq$1 O Lq IpU H Y FT Cc@7# = (0)' ;P :d 8tp>tp 6Jt" 5xpE 2LT 07+-7 *r- 'Fq $p "9:9!/  cI8 0 G0 8x= 2 1@YCedar System Modelling Reference Manual23[FileSystem]David Gifford, "On the Coexistence of System Modelling and Directories," CSL Notebookentry, filed on [Indigo]Entries>81CSLN-0060.Press (and .Bravo).[RTModel] Paul Rovner, "The Cedar Runtime Model," CSL Notebook entry, filed on [Indigo]Entries>81CSLN-0034.Press (and .Bravo).[SystemModels] Butler Lampson, "System Modelling," May 13, 1980, filed on[Indigo]Modelling>ModelsNow.Press (and .Bx).[ThesisProposal]Eric Schmidt, "Controlling Large Software Development in a Distributed Environment," CSLNotebook entry, filed on [Indigo]Entries>81CSLN-0028.Press (and .Bravo).Appendix ACriterion 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 thenew 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 eachof the original variables must be defined with the same name, type, and location in the globalframe of the new module. This means that the addition of extra global frame variables is likely toprevent replacement of the module since the compiler rearranges global frame locations accordingto usage. If more than one variable's location has been changed, the compiler only gives a warning message for thefirst 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 followedby 'L', e.g. "foo"L, in the module, and no string literals may be present in the start code of themodule.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 oldmodule.6) There cannot be any local frames (e.g. local procedures) in use by another process at the timewhen replacement is attempted.7) The module is not replaceable if it was copied using the Mesa language construct NEW (i.e. has acopied 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 themodeller.9) The number of global frame indices required by the new version cannot be greater that thenumber used by the old module. (A Mesa module uses one GFI for each group of 32 entry points. Roughlyspeaking, 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. fp'G? b `#3_M [ Zf;X0 UT37R7 OM*/L{M FHq BIr ?pV ;X 9M 8< 55* 4:7' 2F 12F /tK .*p +[tp *N9- ( V 'F $tp, "C ! E 7 Stp [G 8)  (? t:  X pL  >@ZCedar System Modelling Reference Manual2411) Variant records and any MACHINE DEPENDENT variables have "painted" types. Any modulethat 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 BCurrent Limitations and Bugso 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 asparameterization of the model. The "Exports" concept of DF files should be implemented in themodeller 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, ratherthan 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 ofthe 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 bemore 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 CSemi-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.) fp'G? btp! `P ]nr p"rpr [ptptp Xq Ur RhwpE O=wp= Lwp2- JZ I ,tp Ewptp& Bwp@$ ?wpP >- :wpV 7wpY 4wpR 1UwpT .*J *wp tp< 'wp.8 $wp05 #$9 wpM t] Iwp* wpC q r pO T @[;Cedar System Modelling Reference Manual25Grammar, 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 callid: call declares id; the call specifies type (and perhaps value). All other cases are short forvarious uses of this.If id is omitted ( : call), the call must specify a value as a unitId, and its principal part is takenas 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 tothe group by type equality. This is short for individual declaration of the ids, with the properpart 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 mustbe a group).call ::=primary | primary group | primary == call |call PLUS call | call THEN call |SELECT call FROM [ {call1 => exp2}; ] -- exp2 whose call1=callproc[] binds the group to the proc params, evaluates the proc body, and binds this value to theproc result; see : 4.== only when the primary is a type and the call a compatible valueprimary ::=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: idid: * id: TYPE, idImpl: idid * id, idImplOPEN id* OPEN id, OPEN idImpl:@NameName: TYPE == @Name.mesa, where Name.mesa is a Definitions module. :@NameImplNameImpl: Name == @NameImpl.mesa, where Name is exported byNameImpl.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 fp'G? br% ^pO \1tZFGYXxW;HUPTN QpA P4Aqpqvqvq@Nt:'@M@LXf@K@I*st@HL@GbV @F$9@D>@C BpA$@@~qvxq vq@>tptp>mt>p>mt>pt>mp>t >mp>t@=/C@;wt@:nB 9 p Aqp(@7tpqptptptp 6A 4q A&@3 tst3@19 0q A . A +p (rA %pA $>Atp "A !6tpAtptp Atp8 . A(8] @ ~8, S-tptptp 5 Jx 8 1?YCedar System Modelling Reference Manual26Sometimes the type may be omitted, and the type inferred from the valuename: valueThe most common values are filenames preceded by @. These values are calls, in which the primaryis a procedure (e.g. Foo[], where Foo is a variable of type PROC ... and has been defined previously) ora 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 derivedprocedure type as follows:When the file preceded by an @ is a Definitions module, "DIRECTORY X: TYPE X1" in the file adds aparameter to the proc type of "X: TYPE X1". ("DIRECTORY X;" is is a parameter "X: TYPE X" to theproc 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 modulename. Thus @file.mesa where file.Mesa isDIRECTORY 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 exactlyas 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 valueYImpl: Y in the model where Y is the name of the corresponding TYPE (e.g. Y: TYPE Y1 in theparameter 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 itsarguments and produces a (list of) value(s). If the procedure type is from a Definitions file, this valuehas type TYPE Mod, and is represented as the 48-bit version stamp of the .Bcd produced when theDefinitions file was compiled with the given parameters. If the procedure type is from aimplementation file, the .Mesa file is compiled and loaded (if necessary) yielding a 48-bit versionstamp for the module's TYPE, a POINTER TO FRAME for the module instance, and a set of pointers tointerface records, one for each exported interface.As a convenience, the compilation and loading phases are separated out. The compilation phasecomputes the values of all the TYPE's (by running the compiler to produce valid .Bcd's). The loadingphase takes these .Bcd's and loads them to produce the other variables (interface records and pointersto frames). fp'G? bG^ [Frp r ZCp3tp# X Utptptptp Rha P Mt ptp L5"tptptp J tp tp 1 I->tp  G)D}t ptpB tp ?<tptptptp tp 9wO 7#tp8 6otp*tp" 47tp tp 3g 0;] .,+tptp*tptptp &#tptp tptp !? !< }M tp3 u8! >% m tptp2 3 X :tpB f 2  @Z PCedar System Modelling Reference Manual27These execution phases are the only form of execution presently available. Presently, values with proctype that do not fit with "compiling" and "loading" are not allowed. More precisely, the result typesfor @-values that end in ".Mesa" or ".Config" cannot be procedure types, they must be interface typesand 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 compiledand .Config files can be bound. Pushing the MakePackage! button (after StartModelling!) produces afile "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 andcan 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, themodeller acts as a simple loader. Pushing StartModelling! and LoadAll! will load the system describedby the .modelBcd file. UnLoadAll! will unload it and StopModelling! will terminate the modellersession. 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" .modelBcdfile for the inner model is available, the modeller will skip analysis of the .model file and use theresults (e.g. exports) of the nested model directly. A .modelBcd file is "suitable" if it was derived fromthe same version of the .model file listed in the outer model and if it was given the same parameterswhen it was created.For example, -- Outer.ModelX: TYPE Y == @Inner.Model!223454["hello"];and-- Inner.ModelInner: 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 beidentical to that returned by Inner.Model when the .modelBcd file was created by pushingMakePackage!.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 followthese rules:1) Each package to be released will be described by a (set of) .Model files and a (set of) .modelBcdfile(s). Each file listed in the model (preceded by @) will be parameterized by host and directorynames as follows:... == @[host]file.mesa!33245;becomes fp'G? b+< `D" _M ]"tp Zfr W;p9 TD Rr prp QrprpC Ob MI J? G r p rp' F$rprp Dr pr p C= ?a >m Y <74 ;eG 9 6 4^ 2tp# 0.* ,tptptptp *N4- (23 'F2& %r p "r kp9 @b  F  I ]) 2 @Z Cedar System Modelling Reference Manual28host: STRING == IF Released THEN "releaseHost" ELSE "workHost";directory: STRING == IF Released THEN "releaseDirectory" ELSE "workDirectory";... == @[host^]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^]file.mesa!22222;2) The ReleaseTool will copy files from the working to the release directory. .Model and .modelBcdfiles will also be copied but not altered in any way. Each .model file will be checked for accuracy infile names and versions, parameterization, etc.3) The OPEN and LET statements may be used to get access to variables defined in other package'smodels. 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 .Models3. Who constructs the .modelBcd files with Released = TRUE? fp'G?btptp tptp ` tptp tptp_+ [/tptp X04 W;5T5 P"A O`,; M/ Jtptp B I-O Fxp B41 @~[ >&6tp =?*, TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN HELVETICA  TIMESROMANMATH  TIMESROMAN  % . 8 AHO X_bjqx ) 7jw%E%PE"=R#B"9NP "9I !Adededdf@d"dqd|dqddfLd jddddnMSddddddifPfK􌽗ddddϼnMSNfKMTddj/ModelRefMan.Pressschmidt12-Mar-82 12:46:11 PST: