11 - Defense Technical Information Center Quarterly Technical Report #1 EUCLID Compiler Project Report Summary The purpose of the project is to produce a compiler for the language
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
This research was sponsored by theDefense Advanced Research ProjectsAgency under ARPA Order No. 3475Contract No. MDA 903-78-C-0037Monitored by Steve WalkerEffective Date of Contract 1 Oct 1977Contract Expiry Date 31 Mar 1979
A portion of this project is beingsponsored by the Canadian Departmentof National Defence , Chief of Researchand Development
The views and conclusions in this document are those of the
author and his associates and should not be in terpreted as
necessarily representing the official policies , either
expressed or implied, of the Defense Advanced Research
Projects Agency or the United States Government.
David BonyunI.P. Sharp Associates LimitedSuite 600 _______-- - -
-‘ 265 Can ing Aven ue I T}UZ c~ 1.
OTTAWA , Canada K1S 2E 1 :d.
78 11 21 Ø4 !~
— ~~~~~~~~
- V V
UNCLASSIFIEDSECURITY CLASSIFICATION OF THIS PAGE (When Del. Entered)
D~~~~
r1QT rt rtfi I U ~~kIT A TI(flJ D A r~ READ INSTRUCTIoNsr~ u ijj’~~i ~~~~~~um II’~ I ~~ I ~~~~ BEFORE COMPLETING FORM
I. REPORT NUMBER 2. GOVT ACCESSION NO. 3. RECIPIENT’S CATALOG NUMBER
~~~ T ITLE (en d Subtitl.) 5. TYPE OF REPORT & PERIOD COVERED
Compiler for PDP-11 1 Quarterly Technica).
A !“~ D ~~~p~~I el ~ ~~~~~~~~~~~~~~~~ MUM BER
\fj ~/IPSA—38l9—~~ l”7. AUTHOR(.) eeNTnfLGT ~~fl 6flArI T L,,~MS~~~(.)
R.C. Holt, University of Toronto 1~~~MD~~~~ 3-78-C~~,Ø37~ 4ff ~ 4
9. PERFORMING ORGANIZATION NAM E AND ADDRESS $0. PROGRAM ELEM~~~~ .~~MG4~~~ T , TA6$C.AREA & WORK UNIT NUMBERS
I.P. Sharp Associates Limited600-265 Can ing AvenueOTTAWA ,_ Ontario ,_ Canada__K1S_ 2El
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
II. CONTROLLING OFFICE NAME AND ADDRESS ~
4*~~~~~~~~~~T G~~TI
Information Processing Techniques ( )21 Apr~~~~~ 7~~,/Office ~ ~DARP A ARLINGTON . VA 22209 29
$4. MONITORING AGENCY. N.~ ME & A DORESSOI diU.r. nt Item Controlling Office) $5. SECURITY CLASS. (ol mi. r.port)
~~~~ i~~j V i ~~ ~~~~~~~~~~- . ISa. DECLASSI FICAT ION/ DOWNGRADINGI L. I i SCHEDULE
1 I ~~~~ I 111) ft _ _ _IS. ~~4~~R,~~uT eKe TeMrnCl- (..Iih t, R..~,.,t) —
—
17. DISTRIBUTION STATEM ENT (.1 A. ab.(ii~Iint.r •d Sn Block 20. II dlII.reni from Rip ozf) /Qu art i~r1y tec~tntca1 rept. no. 1~
1. Oct 77—~1 Mar 7’~,
$9. SUPPLEMENTARY NOTES
Part of this project is funded by the Canadian Departmentof National De fence
19. KEY WOROS (Conhlnu. on rov.r.e .Id. lIn.c.aI ~ry end identify by block number)
EUCLI D, compiler , computer security
~O.\A 9ST RACT (Continue on r.v.r.. aid. if neceaa.,y end identity by block numb.?)
>~ The work towards a EUCLI D compiler for the PDP-1l is proceedingsatisfactorily although it has changed somewhat as the resultof e f for t put into stabilizing the language .~~~~
DD , j AN 73 1413 EDITION or I NOV 65 IS OBSOL ETE UNCLASSIFIED.4~ Q I e7 4~~C9~~ITY CLASSIFICATION OF THIS PAGE (Wt,.n D•te
This period has been occupied in preparing for the construction
of a Translator ~or the full EUCLID language . The central
aspect of this work has been the production of a Small EUCLI D
Transliterator , which will be one of the primary tools for
building the Translator. The following has been accomplished
during this period.
1. Design and documentation of the Small EUCLID language ,which is a subset of full EUCLID. The full EUCLIDTranslator will be written in Small EUCLID.
2. Maintenance of the Scanner , which makes up part ofthe Transliterator and later part of the Translator.
3. Design and implementation of the Parser skeleton ,which makes up part of the Transliterator and laterpart of the Translator.
4. Design, implementation , bootstrapping and distributionof the Trans].jterator , which maps Small EUCLIDprograms into C programs, so they can be run under theUNIX operating system.
5. Design and implementation of a preliminary I/O supportsystem under UNIX.
6. Extensive interaction with the EUCLID Language Designcommittee via the ARPANET and at a meeting inCalifornia. These interactions have been necessarybecause various aspects of the language have continuedto evolve.
During this period, many of the basic design decisions for the
Translator have been made , although detailed design remains to
be done. The implementation team has organized itself into an
efficiently functioning unit. The EUCLID language has shown
9
L ~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ . . ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _ V ~~~~~
— V V V . ._ ~~~~~ . - ~~ . .~~~~ ... ~~~~~~~ . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ uu~~~
itself to be somewhat more complex and less stable than
originally hoped for.
Not as much was accomplished during this period as was hoped
for. While this may cause slight deferment of the completion
of the project, there seems to be no fundamental difficulty in
V carrying out the project in approximately the manner
The numbering of issue s in the report matches those in 78- 3 and
78-4 from Wortnian, with a few extra items appended to the end.
I have put them in order of discussion , rather than in numeric
order.
STRINGS
We propose changing the report to use the CSRG-designed string
type in place of the current type . We will change the example
to use them also, except that we may use the current string
type in an example to illustrate how other string-like types
can be defined.
VARIABLES THAT START WITH VI
These are now illegal.
EXPORTED TYPES THAT IMPORT VAR~IABLES
If a (module) type , Inner , inside another module type , Outer ,
imports a VAR, then Inner cannot be exported from Outer.
MAN IFESTNESS OF FORMALS
See RESTRICTIONS ON FORMAL PARAME TERS OF TYPES in this report.
DANGLING POINTERS
1. Add the optional attribute CHECKABLE to a collection typedefini t ion.
2. Add the standard component re fCoun t to dynami c variablesin CHECKABLE or COUNTE D collections.
20
•~~~~~~~ V V~~~ V V -~~ ~~~~~~~~~ V ~~~~~~~~
_______________ -V V~~ V_ ~~~~~~~~~~~~~~~~~~~~~~~
VV -V _~ V
3. The appropriate legality assertion for C.Free(v) isv. re fCount=l .
4. It is illegal to use C.Free in a checked scope unless Cis CHECKABLE .
Notes: (a) A CHECKABLE collection pays the referencecounting overhead in all scopes , whe ther CHECKEDor UNCHECKED.
(b) The implementation for a CHECKABLE, uncountedcollection , CUC implements a var p as a pointerto a two-component record (allocated from thesystem zone , not from CUC ) with another levelof pointer to the value as one component , and areference count as the other.
RETURN VALUES
They will remain as currently defined in the Report.
RESTRICTIONS ON FORMAL PARAMETE RS OF TYPES
The following rule, proposed by Butler Lampson , was accepted:
“If you import a parameteri zed type , you mus t also import the
identifiers used in its formal parameter list , exclusive of
its formal parameter identifiers.”
SYNTAX FOR DECLARING TYPE CONVERTERS
The syntax proposed by the implementation team was accepted;
an identifier so-declared obeys normal scope rules.
COMPONENTS FOR EXPRESSIONS
The type of an INTEGER expression is INTEGER. The standard
components f i rs t, last , and size are not defined for type
INTEGER. A ‘value ’ can only be a variable , a constant , or a
function call (not a generalized expression) .
21
- - ~~~ V~~~~~~ V -V V — — — VT~~~~~~~~~~~~ —~~~~~~~~ -~~~—~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
V -~~~~~~
PERVASIVE IMPLIES POTENTIALLY RECURSIVE
Toronto restriction accepted; i .e . , PERVASIVE does not imply
automatic importation of type/routine name into its own scope .
ORDER OF FINALIZATION
The order of initialization for an array A is in increased
order from A.IndexType.first through A.IndexType . last; for a
record , the components are initialized in the order ( lef t-to-
right) in which they were written in the record definition .
For both initialization and finalization, a contained variable
is initialized/finalized resp . by in i t ia l iz ing/ f inal iz ing its
component parts. Finalization is done for arrays and records
in the reverse order of initialization. This is consistent
with the order of finalization for the variables and constants
in a given scope , since it is treated as a nested set of micro
scopes, each beginning at a new declaration (thus , the
finalization for the variables looks more like the inside-out
of the rule than the rule of components at the same level)
COUNTED COLLECTIONS
Yes , lots of counting for assignment (145) ; yes, variant record
af fects counting (153) , bindings are treated like pointer
assignment; deallocating pointers into counted collections
requires decrementing reference counts. There is a problem
with module assignment (“ ml := m2” smashes ml but no FINALLY
will be done for it , and two copies of the original value of
m2 will later be finalized) , so assignment of modules with