



           F U N C T I O N A L         S P E C I F I C A T I O N


           OF THE


           M O D U L A      C O M P I L E R              ( PDP-11 / UNIX SYSTEMS )












                                 RELEASE   1

                                  June 1978






























                                I. D.  Cottam

       UNIVERSITY OF YORK      -      DEPARTMENT OF COMPUTER SCIENCE

       Heslington, York, Y01 5DD, England       Telephone 0904-59861






Functional Specification, York MODULA Compiler                           Page 2
June 1978, Rev.A.



                              TABLE OF CONTENTS


                  1.   INTRODUCTION


                  2.   OVERVIEW

                        2.1  MODULA - the language

                        2.2  The York Compiler


                  3.   LANGUAGE COMPARISON WITH MODULA REPORT

                        3.1  Language Restrictions

                        3.2  Language Extensions

                        3.3  Clarification of MODULA Report


                  4.   COMPILER ENVIRONMENT


                  5.   COMPATIBILITY WITH UNIX SOFTWARE


                  6.   OPERATIONAL AND PERFORMANCE CHARACTERISTICS

                        6.1  Compilation Speed

                        6.2  Memory Requirement

                        6.3  Timing Considerations


                  7.   FUNCTIONAL DESCRIPTION

                        7.1  Overview of Compiler Organisation

                        7.2  File Conventions

                        7.3  Input to Compilation

                        7.4  Output from Compilation

                        7.5  Running the Compiler

                        7.6  Run-time Options

                        7.7  Run-time Debugging Facilities

                        7.8  Run-Time Description







Functional Specification, York MODULA Compiler                           Page 3
June 1978, Rev.A.




                  8.   REFERENCES AND APPLICABLE DOCUMENTS


                                 APPENDICES



       Appendix  1  -  SYNTAX  (BNF Production Rules & Syntax Diagrams)

       Appendix  2  -  THE UNIX SHELL COMMAND FILE - mod

       Appendix  3  -  SAMPLE PROGRAMS

       Appendix  4  -  RESTRICTIONS OF RELEASE 1 COMPILER

       Appendix  5  -  RELEASE 2 MODULA COMPILER












































Functional Specification, York MODULA Compiler                           Page 4
June 1978, Rev.A.



       1_.  INTRODUCTION____________




       This document is the functional specification of  the   Univer-
       sity   of   York Release  1  PDP-11  MODULA  compiler.   It  is
       assumed  that the reader is familiar with the defining document
       for the programming language MODULA:

       "N.Wirth;  MODULA, A language for   modular   multiprogramming.
       Software  - Practice and Experience 7, No.1, 3, (1977)" [1].

       York MODULA conforms closely to standard MODULA as  defined  in
       [1].   Section  3  of  this specification describes the differ-
       ences between the two.  Since this specification makes numerous
       references  to  [1] it is recommended  that the  two  documents
       be  kept  in  the  same  binder.  As well as being the specifi-
       cation  against which the compiler is written  and  tested  [5]
       this document serves as a programmer's reference manual.

       The York MODULA compiler operates  under  the  control  of  the
       UNIX   operating  system  and  in conjunction with the standard
       UNIX PDP-11 assembly language processor "as".

       Additional manuals available (or  in  preparation)   from   the
       University   of  York   and  which  the  MODULA  user  may find
       useful are given in section 8 "References and Applicable  Docu-
       ments" - nos.  [5,6,7,8,9].
































Functional Specification, York MODULA Compiler                           Page 5
June 1978, Rev.A.



       2_.  OVERVIEW________




       2.1     MODULA - THE LANGUAGE


       MODULA [1,2,3] is a recent product of the group at  ETH  Zurich
       under  the direction  of  Professor N.  Wirth.  The language is
       intended primarily for programming dedicated computer  systems,
       such  as  those  found  in  process control applications, using
       mini- or micro-computers.

       MODULA is based on PASCAL  but,  in  addition  to  the  conven-
       tional   block structure  present  in  that language, it intro-
       duces a module structure.  A module is  a  set  of  procedures,
       data  types,  and  variables  where  the  names that  are  "im-
       ported"  and  "exported"  from  the module must  be  explicitly
       stated   in   the   module   heading.    MODULA   also   intro-
       duces   general multiprogramming  facilities  in  the  form  of
       processes,  interface modules for controlled access  to  shared
       variables,  and   signals   for   inter-process  communication.
       It  allows  the  specification  of  machine-specific peripheral
       references and operations within a form of the module structure
       known as  a device module.




       2.2     THE YORK COMPILER


       2.2.1   History



       The York MODULA Compiler was largely developed by Jeremy Holden
       during  1976 -  1977 while he was supported by a grant from the
       Science Research Council (SRC) of Great Britain.

       The original compiler ran under the DEC RSX-11D operating  sys-
       tem,   but  has been  modified  to  run  under  UNIX (a product
       of Bell Telephone Labs), the operating system currently in  use
       by  the  University's  Digital  Systems Laboratory.


       2.2.2   Compiler Features


       * The compiler is  capable  of  producing  code  for  a  PDP-11
       or   LSI-11  processor with or without the Extended Instruction
       Set (EIS).

       * Run-time  Systems  for  the  PDP-11  or   LSI-11,   with   or






Functional Specification, York MODULA Compiler                           Page 6
June 1978, Rev.A.



       without  EIS,  are available.  The EIS version  requires  about
       150  words  while  that  for non-EIS systems occupies about 200
       words.

       * High quality object code is produced by the compiler.   Tests
       suggest  that the  object  code  compares  favourably  with any
       other PDP-11 compiler not performing complex  global  optimisa-
       tion.

       * The user may request a line numbered listing  of  the  source
       file.    It   is  also  possible  to  list  the  assembly  code
       file should the user wish to inspect the compiled code.

       * Recursive procedures are allowed.

       * Several language extensions have been implemented.

       * Compiler switches  are  provided  to  control:   object  code
       production  (optimised   or  not,  and  with  or  without EIS);
       source listing;  and the use of certain language extensions.



       2.2.3   Language Restrictions


       * All names must be declared before use.

       * Recursive procedure declarations must state the maximum depth
       of recursion.

       * The standard procedures "off" and  "among"  have   not   been
       implemented.   Their  effects  can  be achieved using the other
       language constructs.

       * The VALUE part of a level 0 block has not  been  implemented.
       Its  effect can be achieved by using ordinary statements in the
       body of the block.



       2.2.4   Language Extensions


       * There are two kinds of extensions:  permanent and optional.

       Permanent extensions are simple in nature and  do  not  require
       the   user   to  "warn"   the  compiler  that  they  are  being
       used.

       * "Compile-time  expressions"  may  be  written  anywhere   the
       strict  language specifies a constant.

       * The additional comment brackets { } may be used.







Functional Specification, York MODULA Compiler                           Page 7
June 1978, Rev.A.



       * The standard procedure "halt" may be called with  an  integer
       parameter.  At  run-time  this  value  is  placed in register 0
       before the processor is halted.

       Optional extensions are  more  complicated  and  will  only  be
       recognised  when the compiler's extension switch is set on:

       * A CASE statement may have an ELSE part.

       * Array constants are allowed in the form of displays.

       e.g.  CONST row = (1,2,3)



       2.2.5   Operational Characteristics


       * The compiler is written in BCPL; it uses a four  pass  scheme
       with  inter-pass  communication performed via sequential binary
       files.

       * A memory area of 20K words is required for the  compiler  and
       workspace  .  With this amount of space, programs of about 2000
       lines may be compiled.

       * Compilation speed is approximately:

                              5 + n/12 seconds

       for an n line program running on a PDP-11/40 with an RP03 disk.






























Functional Specification, York MODULA Compiler                           Page 8
June 1978, Rev.A.



       3_.  LANGUAGE________ COMPARISON__________ WITH____ MODULA______ REPORT______




       The formal definition of standard MODULA is given in  [1].   In
       this   section the  differences between the York implementation
       of MODULA and the official definition  are  given.   Note  that
       machine   specific   features  need  not  be detailed  in  this
       document  since  those  defined in [1] are also for the PDP-11.

       This section is divided into  three  sub-sections.   The  first
       lists   (minor)  restrictions   imposed by the York implementa-
       tion.  Then, facilities not provided in standard   MODULA   but
       included  in  the  York  compiler  for  the programmer's   con-
       venience   are  described.   Finally  areas  of  [1]  not  com-
       pletely  clear,  undefined, or left to the  implementor's  dis-
       cretion  are discussed.




       3.1     LANGUAGE RESTRICTIONS


       3.1.1   Initialization Parts

       Initialization parts of  level  0  blocks   are   not   allowed
       by   the   York  compiler.  Thus the following parts of [1] are
       effectively deleted:

         .   Page 16, the BNF syntax rules for : initialization part,
             initial value, and repetition
         .   Page 17, the paragraph beginning  "An initialization part
             serves..."
         .   Page 33, (the syntax diagram for BLOCK), the sub-graph
             beginning VALUE


       Discussion:

       The effect  of  an  initialization  part  may  be  achieved  by
       assignment  statements.    The  semantic  consequences are that
       initialization parts are designed to be compile/load -time  ac-
       tions, whereas assignments are run-time actions.   The  use  of
       assignments is desirable, in any case, for  systems  which  may
       go   through  power-fail  restarts  and  require  certain  sys-
       tem variables to be re-initialized.



       3.1.2   Declaration before use

       The York   compiler   does   not   permit,   under   any   cir-
       cumstances,   applied occurrences to textually precede defining






Functional Specification, York MODULA Compiler                           Page 9
June 1978, Rev.A.



       occurrences.  e.g.  :

                   VAR  x :  newtype;
                   TYPE  newtype = ARRAY 1:3 OF char

       The first occurrence of "newtype"  will  be  flagged   by   the
       compiler  as  an undeclared identifier.

       Discussion:

       This restriction has two major consequences:

          .  The full generality of cross-referencing objects
             declared in different modules is lost
          .  Two non-nested procedures cannot call each other in a mutually
             recursive fashion

       The lifting of this restriction is included in the list of pos-
       sible Release  2  enhancements (Appendix 5).



       3.1.3   Standard Function Procedures


       The York compiler does not implement the procedures:

                .  among
                .  off

       defined on page 18 of [1].


       Discussion:

       The user may define these procedures, within a particular  pro-
       gram, if deemed necessary. e.g.:

                  PROCEDURE among (i:integer; b:bits): boolean;
                  BEGIN
                        among:=  b[i]
                  END among;

                  PROCEDURE off (b:bits):boolean;
                  BEGIN
                      off:= (b = [])
                  END off ;

                  or for the version of off with two parameters:

                  PROCEDURE  off (b1,b2: bits):boolean;
                  BEGIN
                       off:= ( (b1 AND b2) = [] )
                  END  off;







Functional Specification, York MODULA Compiler                          Page 10
June 1978, Rev.A.





       3.1.4   Constants of type  bits


       In the York implementation, bitlistelements are integers as op-
       posed to constants.  Thus,  the  BNF  rule  for  bitlistelement
       given  on  page  10  of  [1] is effectively changed to:

       bitlistelement = integer [":" integer ].

       The syntax diagram for unsigned constant given on  page  28  of
       [1]   is  also effectively modified to match the new BNF.  York
       MODULA syntax diagrams may be found in Appendix 1.

       Discussion:

       This restriction has no practical consequences and is made sim-
       ply  to   allow the compiler to treat bitconstants as primitive
       lexical items.




       3.2     LANGUAGE EXTENSIONS


       The York compiler implements  several  extensions  to  standard
       MODULA.    These  are  of  two  kinds:  permanent and optional.
       Permanent extensions are simple in  nature  and  are   uncondi-
       tionally   available  to  the  user.   Optional extensions  are
       somewhat more substantial, although  still  in  the  spirit  of
       MODULA;   these require a compiler switch to be set if they are
       to be  used.  (Details are given in section  7.5  "Running  the
       Compiler").


       3.2.1   Permanent Extensions



       3.2.1.1 Additional Comment Brackets


       In [1] comments are defined to be bracketed by (* and *).

       The York compiler allows the character "{"  to  be  used  as  a
       synonym  for  the character  pair  "(*" and, likewise, "}" as a
       synonym for "*)".  Note the use of the word "synonym" - no  at-
       tempt is made by the compiler to  match "(*"  with  "*)"  ,  or
       "{"  with  "}".  As in [1] comments may be nested.  Presumably,
       nested comments  are  intended  to  allow  sections  of  MODULA
       program  to be  "commented  out".   However,  the  user  should
       beware  attempting  to  comment  out a section  of  program  in
       which  a  string  (or  character constant)  S  appears where  S






Functional Specification, York MODULA Compiler                          Page 11
June 1978, Rev.A.



       contains one or more of the comment brackets.



       3.2.1.2 The Standard Procedure - halt


       The standard procedure "halt" is defined in [1] to  be  parame-
       terless.    An  extension  in  the  York compiler allows an op-
       tional integer parameter.  At run-time the  integer  expression
       (or  the  constant  1  by default) is evaluated and  placed  in
       register 0 immediately before  a  PDP-11  HALT  instruction  is
       obeyed.   This  facility  is designed as a, somewhat primitive,
       debugging aid; allowing  identifiable  breakpoints   or   error
       stops  to  be included in a program.



       3.2.1.3 Compile - time Expressions


       With the exceptions already mentioned in 3.1.1 and 3.1.4, wher-
       ever standard MODULA  permits  a constant, York MODULA allows a
       more general construct to  be  written.   This  new   construct
       is   called   a  compiletimeexpression,  and is   subset of the
       syntax for expression.

       compiletimeexpression = ctsimpleexpression [relation
                                       ctsimpleexpression].
       ctsimpleexpression = ["+"|"-"] ctterm  { addoperator  ctterm}.
       ctterm =  ctfactor  {muloperator ctfactor}.
       ctfactor =  unsignedconstant | "NOT" ctfactor | "(" compiletime-
                    expression")" |
                 ("char"|"CHAR"|"integer"|"INTEGER") "(" compiletime-
                    expression")".

       The constructs relation, addoperator, and muloperator  are  de-
       fined  on  page  13   of   [1]   in the    BNF    syntax    for
       expression.     The   syntax   diagram   for compiletimeexpres-
       sion is given in Appendix 1.

       Discussion:

       Constants in standard MODULA are extremely  simple  constructs.
       Informally, they consist of either:

                *  an integer (possibly signed)
                *  a  character or string
                *  a  bits, char, boolean, or some user-defined
                   enumeration type denotation

       The restriction of constants to the above can be extremely irk-
       some   to   the programmer in three particular contexts.  These
       are:







Functional Specification, York MODULA Compiler                          Page 12
June 1978, Rev.A.



                (i)   CONST declarations
                (ii)  Array bounds
                (iii) CASE statement labels

       To avoid having to write, for example:

                CONST arraylength = 81;
                      arraylengthless1 = 80;
                 VAR  row : ARRAY 0 : arraylengthless1 OF char;

       the York implementation allows,  so-called,  "compile-time  ex-
       pressions"  in  contexts  (i),  (ii) and (iii). So that one may
       re-write the previous piece of MODULA text as:

                 CONST arraylength = 81;
                 VAR   row : ARRAY 0 : arraylength - 1 OF char;



       3.2.2   Optional Extensions


       3.2.2.1 Array Constants


       An array constant is a bracketed  list  of  one  or  more  com-
       piletimeexpressions (see  3.2.1.3)  separated  by  commas.  All
       the compiletimeexpressions in a given array constant must be of
       the  same  type.  Multi-dimensional array constants are permit-
       ted.

       Array constants may be used in the following contexts:

                   (i) CONST declarations
                  (ii) The right hand side of an assignment
                 (iii) Actual procedure parameters

       In context (i) the constant identifier on the  left  hand  side
       (LHS)   of   the  constant  declaration  has a lower bound of 1
       and an upper bound equal to the  number of  components  in  the
       array  constant.  Array constants in context (ii) must have the
       same  number of  components  as  the  variable  on the  LHS  of
       the  assignment.   The  lower bound(s) of the LHS variable need
       not be unity.  Naturally, component types must   be  identical.
       The index type(s) of the LHS variable must be integer.  In con-
       text (iii) note that destinct  parenthesis  are  required   for
       each  of the actual parameter list and any array constant given
       as a parameter.

       When the optional language  extensions  are  enabled,  the  de-
       finitions   of  ctfactor and factor are effectively modified as
       follows:

       ctfactor = unsignedconstant |"NOT" ctfactor |"(" compiletimeexpression
                  {","compiletimeexpression}")"|






Functional Specification, York MODULA Compiler                          Page 13
June 1978, Rev.A.



         ("char"|"CHAR"|"integer"|"INTEGER") "(" compiletimeexpression ")".

       factor = unsignedconstant | variable | functioncall |"("expression")"|
                   "NOT" factor|  "("compiletimeexpression {"," compiletime-
                             expression}")".

       Discussion:

       To illustrate this new construct:

            VAR    row  :  ARRAY  1:3 OF integer;
                        |
                        |
                   row[1]  :=  1 ;
                   row[2]  :=  2 ;
                   row[3]  :=  3 ;

       may be more conveniently written :

            VAR    row  :  ARRAY  1:3 OF integer;
                        |
                        |
                   row  :=   ( 1,2,3 ) ;

       This extension also facilitates the definition of simple  read-
       only (CONST) tables  (ARRAYs) :

          CONST  days = ('MON',  'TUE', 'WED', 'THU', 'FRI', 'SAT', 'SUN')

       Note also that the syntax allows array constants of any  dimen-
       sionality to be expressed:

            VAR    matrix  :  ARRAY  1:2,  1:3  OF integer  ;
                           |
                           |
                    matrix   :=   (  (1,2,3) , (1,2,3) ) :


       3.2.2.2 CASE Statement ELSE Part


       This optional language extension allows case statements  to  be
       written   with  an   optional  ELSE  part.   The  definition of
       case statements given in [1] (pages 14  &  15)  is  effectively
       changed to:

       "Case statements specify the selective execution of  a   state-
       ment   sequence  depending   on  the  value  of  an expression.
       First the case expression is evaluated, then the statement  se-
       quence  with label equal  to  the  resulting value  is  execut-
       ed.   If  no label exists  which  equals  the  resulting  value
       then, if an elsepart is present, the statement sequence follow-
       ing "ELSE" is executed.  The type of the case  expression  must
       not be structured."







Functional Specification, York MODULA Compiler                          Page 14
June 1978, Rev.A.



           casestatement = "CASE" expression "OF" case {";" case}
                             ["ELSE" statementsequence] "END".
           case = [caselabels ":" "BEGIN" statementsequence "END" ].
           caselabels = compiletimeexpression {"," compiletimeexpression}.

























































Functional Specification, York MODULA Compiler                          Page 15
June 1978, Rev.A.





       3.3     CLARIFICATION OF MODULA REPORT



       3.3.1   Internal Inconsistencies


       This section discusses the  discrepancies  between  the  syntax
       charts  and   BNF production  rules  in  [1],and, gives the in-
       terpretation chosen by the York implementation.   The  complete
       syntax of (York) Modula is listed in Appendix 1.


       3.3.1.1 Constants of type bits


       The bits constant for all bits false [] is not allowed  by  the
       syntax   chart  for   Unsigned  Constant.   The  York  compiler
       follows the BNF (and Wirth's examples) and permits [].


       3.3.1.2 Initialization Parts


       (Although initialization  parts  are  not  implemented  by  the
       Release   1  compiler  they  are mentioned here for the sake of
       completeness.)

       The semicolon separator  is  missing  from  the   BNF   produc-
       tion   rule   for  initializationpart.    Further,  the general
       syntax is less than ideal since it does  not  conform  to   the
       LL(1)   condition.    That   is,   a  so-called repetition  has
       the same structure as particular instances of constants of type
       bits.


       3.3.1.3 Uselist in Process Declarations


       In the BNF production rule for processdeclaration  the  uselist
       is  mandatory,  whereas   it  is  optional in the corresponding
       syntax chart (and in Wirth's examples).  The York compiler  al-
       lows the uselist to be left out.


       3.3.1.4 Uselist in Module Declarations


       The syntax charts and BNF differ as  to  whether  or   not  the
       list  of  identifiers  in   a  module's  USE identlist  may  be
       empty.  The York compiler permits module, procedure,  and  pro-
       cess  USE  identlists  to be empty.  The semantics are in 3.3.6
       below.






Functional Specification, York MODULA Compiler                          Page 16
June 1978, Rev.A.




       3.3.2   Recursion


       The official definition  of  MODULA   states   that   recursive
       procedures   are allowed  but  that  the  maximum  depth of re-
       cursion must be specified as a compiler  directive.   The  York
       implementation  makes  a  small   language change instead.


       On  page  16  of  [1]  the  BNF  production  for   procedurede-
       claration   is effectively changed to:

           proceduredeclaration = "PROCEDURE" ident ["("formalparameters")"]
                         [":"ident] ["["integer"]"] ";" [uselist] block ident.

       where the integer in square brackets defines the maximum recur-
       sion  depth.  The syntax chart for "BLOCK" on page 33 of [1] is
       effectively modified to reflect the above BNF (see Appendix 1).



       3.3.3   Type Equivalence


       In [1] no algorithm is given  to  define  whether  or  not  two
       types  are equivalent.   "Structural Type Equivalence" , as de-
       fined in  [14], is the rule adopted in the York compiler.  i.e.

       "Two variables are considered to be of the same  type  whenever
       they   have  components of the same type structured in the same
       way".

       More formally:

       Two variables, V1 and V2, are of the same type iff:
            (1)  They are declared in the same variable declaration sequence.
                   e.g.  VAR  V1,V2: ARRAY 1:6 OF char ;
       or  (ii)  The type identifier of V1  has been declared equal to the
                 type identifier of V2 in a type declaration (or vice versa).
                   e.g.  TYPE mychar = char ;
                         VAR   V1 : char ;
                               V2 : mychar ;
       or (iii) They both have structured types, and the
                appropriate one of the following rules holds:
            . Enumerated types
              Equal numbers of elements, with names equal, and in the
              same order
            . Record types
              Equal numbers of fields, with names equal, in the same order
              and with cooresponding field types equivalent
            . Array types
              Equal dimensionality and index ranges, with index and
              component types equivalent
         e.g.  VAR  V1 : RECORD F1, F2 : boolean END;






Functional Specification, York MODULA Compiler                          Page 17
June 1978, Rev.A.



                    V2 : RECORD F1, F2 : boolean END;
       Discussion :

       According to this definition the compiler should accept:

                  VAR  k:  (male,female);
                       l:  (male,female);

       but, for unique identification of a constant's type,  must  re-
       ject:

                  VAR  k:  (male,female);
                       l:  (female,male);

       A restriction of the Release 1 York Compiler is  that  both  of
       the   above  forms  of  declaration  will result in a rejection
       of the declaration of l;  and   the   second   occurrences   of
       male   and   female  flagged  as  duplicate declarations.   For
       a  full discussion of this problem in PASCAL compilers the  in-
       terested reader is directed to  [14].


       3.3.4   Module Boundary Visibility Rules

       When a module exports objects (i.e. their identifiers) some  of
       their  attributes  are hidden. This section attempts to clarify
       the paragraphs beginning "if a type is defined ..." on page  18
       of [1].

       If a type is defined local to a module and its  identifier  oc-
       curs  in  the define- list of the module , then only the type's
       identity, but none of its structural details becomes known out-
       side the module. If it is a record type, the field names remain
       unknown, if it is an array type index ranges and elements  type
       remain  unknown  outside.  Hence,  variables declared of a type
       that was exported in this way from a module can be used only by
       procedures  declared  within and exported from the same module.
       This implies that if a module defines a type it also has to in-
       clude the definition of all operators belonging to this type.

       If a variable is defined local to a module and  its  identifier
       occurs  in  the define-list of the module, then it appears as a
       read-only variable outside the module. If the  variable's  type
       is declared global to the module then structural information is
       known outside the module otherwise it is not;  the  comment  in
       the previous paragraph applies.

       If a procedure is defined local to a module and its  identifier
       occurs  in  the define-list of the module, then if the types of
       the formal parameters or result type are declared local to  the
       module  then  their  identifiers should also be included in the
       define-list.

       If a constant is defined local to a module and  its  identifier
       occurs in the define-list of the module, then if the constant's






Functional Specification, York MODULA Compiler                          Page 18
June 1978, Rev.A.



       type is declared global to the module then structural  informa-
       tion  is known outside the module otherwise it is not; the pre-
       vious comment concerning manipulating exported variables   with
       exported procedures applies equally to constants.

       3.3.5   Results of Undefined Actions


       The following language insecurities are not checked for by  the
       Release 1 York compiler either at compile-time or run-time:

             (i) Range violation during array indexing.
            (ii) Case expression out of range.
           (iii) Integer overflow or underflow.
            (iv) Recursive procedures exceeding their declared maximum
                 depth.
             (v) The use of uninitialised variables.
            (vi) The machine dependent parts of device modules.

       In the case of (ii) the  elsepart  (see  3.2.2.2),  if  one  is
       present,  is  executed;  otherwise  control  passes to the next
       statement in sequence. In all the other cases one of  the  fol-
       lowing is likely to occur:

         .  Execution continues with some variable(s) having erroneous value
         .  The processor will trap on an addressing error or reserved
            instruction error causing an entry to the Nucleus where a
            HALT instruction is obeyed.

       Clearly, in the Release 1 compiler the onus is entirely on  the
       programmer to include suitable checks wherever appropiate.



       3.3.6   Empty USE identlists


       The MODULA Report [1] does not explicitly  state  the   meaning
       of   an   empty identlist in the uselist of a procedure or pro-
       cess declaration.  Either  all  globals   are   accessible   or
       none.    The   strong   implication,   and   the interpretation
       made  by the York compiler, is that when  there  is  a  uselist
       even  with  an  empty  identlist then the procedure or  process
       concerned  may refer  only to  locals,  formal  parameters  and
       standard objects (see [1] page 16).



       3.3.7   Parameterless Function Procedures


       The syntax of standard MODULA  dictates  that   function   pro-
       cedures   have   at least  one  parameter.  However, several of
       the example programs in [1]  use  parameterless  function  pro-
       cedures.    The   York  compiler  takes  a  liberal interpreta-






Functional Specification, York MODULA Compiler                          Page 19
June 1978, Rev.A.



       tion   of   this   feature  and  permits  parameterless   func-
       tion procedures.

       Thus the syntax of  functioncall  given  on  page  13  of   [1]
       effectively becomes:

                     functioncall  =  ident  [ parameterlist ].

       The modified syntax diagram is given in Appendix 1.




















































Functional Specification, York MODULA Compiler                          Page 20
June 1978, Rev.A.



       4_.  COMPILER________ ENVIRONMENT___________




       The York PDP-11 MODULA Compiler runs under the  UNIX  Operating
       System.   Thus, the  minimum  configuration  required  to  com-
       pile  MODULA programs is that required for operation  of  UNIX.
       Details of UNIX and configurations can  be found in :

                 *  Documents for  Use with the UNIX Time-Sharing System,
                    sixth edition, [10];

                 *  UNIX  Programmer's Manual,
                    sixth edition, dated May 1975, [11].

       At York the compiler is normally run in 20K words  of   memory.
       This   gives  sufficient  workspace for a program of about 2000
       lines to be compiled.  The compiler uses up  to  6  disk  files
       during compilation (see 7.2).

       UNIX programs used in conjunction with the compiler are:

              (i)  The Editor     -     ed
             (ii)  The Assembler  -     as

       Other University of York programs used  in   conjunction   with
       the  compiler are:

              (i)  The Run-time Nucleus  -  modnucl.s
             (ii)  Utility to convert UNIX load format to GT40
                   load format - utg
            (iii)  Utility to convert UNIX load format to standard DEC PDP-11
                   load format -  utl.

       Installation and configuration  of  the  compiler  and  support
       software  onto  a running UNIX system is described in  [6].
























Functional Specification, York MODULA Compiler                          Page 21
June 1978, Rev.A.



       5_.  COMPATIBILITY_____________ WITH____ UNIX____ SOFTWARE________



       All University of York supplied software is at  release/version
       level 01.00.

       UNIX software  is  that  defined  by  edition  6  of  the  UNIX
       Programmer's  Manual.   In particular, the editor and assembler
       versions are dated:

                 (i)  ed  -  1 /15 /73.
                (ii)  as  -  1 /15 /73.

       Run-time systems (object program + Nucleus) may  be   produced,
       via  utility programs, which are compatible with either:

                 (i)  Standard  UNIX load (ld) format (default)
                (ii)  DEC  GT40 Graphical Display load format
                      (via utility - utg )
               (iii)  Standard DEC PDP-11  load format
                      (via utility - utl)

       Details of the use of "utg" and "utl" may be found in  Appendix
       2.   They  are  written  in  the  language  "C"  (version dated
       5/15/74).

       The MODULA compiler is written in BCPL[12].  The BCPL  compiler
       is  a  version  produced  at the University of York. The binary
       BCPL files are supplied with the MODULA system to enable  users
       to  make  corrections and changes at the source level. The BCPL
       software is not supported.





























Functional Specification, York MODULA Compiler                          Page 22
June 1978, Rev.A.



       6_.  OPERATIONAL___________ AND___ PERFORMANCE___________ CHARACTERISTICS_______________





       6.1     COMPILATION SPEED


       Compilation speed has  been  measured  on  the  University   of
       York's   DEC PDP-11/40  (RPO3 disk,core memory,one user logged-
       in) by means of the UNIX "time" command at:

       5 + n/12 seconds

       where n is the number of source lines.




       6.2     MEMORY REQUIREMENT


       In general, the larger the amount of  workspace  available   to
       the   compiler  the larger the source program which may be com-
       piled;  although pathological cases can be constructed in which
       a  fairly  short  program  uses  a  large number  of long iden-
       tifiers.  In practice, programs of 2000 lines  have  been  com-
       piled  with  the compiler running in a memory allocation of 20K
       words.




       6.3     TIMING CONSIDERATIONS


       Wirth in [4] states that an extra requirement is placed on  im-
       plementations  of   real-time  programming languages.  That is,
       they should provide compiled statement execution  time  bounds.
       Of  particular  importance   are  the  times for   send,   wait
       and   process   switching  operations.   Such  process adminis-
       tration  is  performed  by  the Nucleus and, therefore,  timing
       figures are  relatively  easy  to  calculate   and  state  once
       and  for  all.   However, sequential statement sequences, which
       are subject to  optimisation,  cannot  have   their   execution
       bounds   simply   stated   in  tabular form.  The best solution
       would be to have the  compiler  print  such  figures   on   the
       listing  file.    Where   loops   occur with dynamic bounds the
       compiler could give the time taken for one iteration.  This fa-
       cility is not included in the Release 1  compiler.  It is list-
       ed in Appendix 5 as one of the possible features of Release 2.









Functional Specification, York MODULA Compiler                          Page 23
June 1978, Rev.A.



       Critical Nucleus routine timings follow:

       (N.B  Times  are  calculated   from   Appendix   C   of   [13].
       C.2,PDP-11/35  &   11/40.   Memory   types  MM11-S, MF11-L, and
       MM11-L are assumed with direct use  of  the  special  processor
       MSYNA  signal  and with  memory  within  the  CPU  mounting as-
       sembly.  The memory management KT11-D option is also assumed).

         doio   -     17.38 microseconds (to return to interrupted process)
                      14.97 microseconds (to restart device process
  