.ll70
.lt77
.in7
.nf
.sp4
    T E S T      P L A N


    OF THE


    M O D U L A     C O M P I L E R         ( PDP-11 / UNIX SYSTEMS )
.fi
.sp12
.ce4
RELEASE   1
.sp
June 1978
.sp30
.ce
I. D.  Cottam
.sp
UNIVERSITY OF YORK      -       DEPARTMENT OF COMPUTER SCIENCE
.sp
Heslington, York, Y01 5DD, England        Telephone 0904-59861
.bp
.ce
TABLE OF CONTENTS
.sp4
.in+5
1. INTRODUCTION
.sp
2. SOFTWARE OVERVIEW
.sp
3. TEST PHILOSOPHY
.sp
   3.1 Objectives
   3.2 Test Configuration
   3.3 Test Vehicles
.sp
4. RESTRICTIONS AND LIMITATIONS
.sp
5. REFERENCES AND APPLICABLE DOCUMENTS
.in-5
.ce
.sp4
APPENDICES
.sp2
.in+5
I   :   SEQUENTIAL MODULA TEST PROGRAMS AND PROCEDURES
.sp
II  :   (CONCURRENT) MODULA TEST PROGRAMS AND PROCEDURES
.sp
III :   MODULA PROGRAMS OF GENERAL INTEREST
.in-5
.nr V1 0
.bp
.CH "INTRODUCTION"
This document is the test plan for the Release 1 MODULA compiling 
system produced by the Department of Computer Science at the 
University of York. The compiler is tested against references 1 
and 2:

"MODULA Compiler, Release 1, Functional Specification; May 1978;
University of York, Department of Computer Science."

&

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


It is the intention that the tests specified herein serve two major
purposes. Firstly, the tests provide the University of York with a
yardstick by which a decision may be taken on whether a version of
the MODULA compiling system has reached a level of reliability such
that it is suitable for release to other institutions. Secondly,
receiving installations may run these tests, following the receipt
of a MODULA release package, in order to verify the success of the
transport operation.
.CH "SOFTWARE OVERVIEW"
.SE "MODULA - the language"
MODULA [2,3,4] 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.
.sp
MODULA is based on PASCAL  but,  in  addition  to  the  conventional  block
structure  present  in  that language, it introduces a module structure.  A
module is a set of procedures, data types, and variables  where  the  names
that  are  "imported"  and  "exported"  from  the module must be explicitly
stated  in  the   module   heading.    MODULA   also   introduces   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.
.SE "The York Compiler"
.SS "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.
.sp
The original compiler ran under the DEC RSX-11D operating system,  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.
.SS "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).
.sp
* Run-time Systems for the PDP-11 or  LSI-11,  with  or  without  EIS,  are
available.  The EIS version requires about 150 words while that for non-EIS
systems occupies about 200 words.
.sp
* 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 optimisation.
.sp
* 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.
.sp
* Recursive procedures are allowed.  The  maximum  depth  of  recursion  is
specified in the procedure heading.
.sp
* Several language extensions have been implemented.
.sp
* 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.
.SS "Languge Restrictions"
* All names must be declared before use.
.sp
* The standard procedures 'off' and  'among'  have  not  been  implemented.
Other language constructions allow their effect to be duplicated.
.sp
* The VALUE part of a level 0 block has not been implemented.
.SS "Language Extensions"
* Extensions are available at two levels.
.sp
Permanent extensions are simple in nature and do not require  the  user
to 'warn'
the  compiler  that  they  are  being  used.   Besides  the already
mentioned recursion depth indicator the following permanent extensions  are
implemented:
.sp
* 'Compile-time expressions' may be written anywhere  the  strict  language
specifies a constant.
.sp
* The additional comment brackets { } may be used.
.sp
* 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.
.sp
Optional extensions are more complicated and will only be  recognised  when
the compiler's extension switch is set on.
.sp
* A CASE statement may have an ELSE part.
.sp
* Array constant displays are allowed.
.sp
e.g.  CONST row = (1,2,3)
.SS "Operational Characteristics"
* Written in BCPL the compiler uses a  four  pass  scheme  with  inter-pass
communication performed via sequential binary files.
.sp
* 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.
.sp
* Compilation speed is of the order of:
           5 + n/12 seconds
for an n line program running on a PDP-11/40 with an RP03 disk.
.CH "TEST PHILOSOPHY"
.SE "Objectives"
* All language features defined by [2] (modified by information
contained in section 3 of [1] 'Language Comparison with MODULA
Report') to be checked for correctness.
.sp
* All specific compiler features to be checked for conformity to
the Functional Specification [1].
.sp
* No modifications to be made to the compiler during testing.
.sp
* Two sets of test programs to be employed for each pass of the
compiler. One set to produce the errors detected by the pass; the
other to contain every valid construct processed by the pass.
Every statement in the compiler to be executed at least once.
.sp
* A final objective of this test set organisation is to aid in
the debugging of future releases of the compiler. Since the
intermediate (or final) code output by a pass may be listed
(see reference [7]), a simple comparison can be made between the
results of a new 'experimental' compiler and the, tested, released
version.
.SE "Test Configuration"
The test configuration used by the University of York consis