Preface It was 1975, and Colin Broughton and I were a couple of college buddies and hot shot programmers at the University of Saskatchewan (Canada). Colin discovered this amazing thing called Algol68. His initial interest was in the description: VW grammars were an intriguing invention. As he studied the Revised Report on Algol68, though, he became fascinated by the language itself. How could it be implemented? Could it be implemented at all? A visit to Saskatoon by Barry Mailloux, the “first et al editor of the report” as he called himself, caught my attention. While Colin became captivated by the challenges of parsing and compiling Algol68, I was drawn to the complexities of executing the resulting programs. We were young, ambitious, and a bit foolish, and decided we would implement a compiler and its run time system. Not just any compiler, a full language compiler. Flex arrays. Parallelism. Garbage collection. Transput. And not only that, we would make it a checkout compiler in the heritage of WATFIV, so it could be used for teaching. Being young, ambitious, and (mostly) unattached, we pulled off the improbable. Two years later we had a working version, and a year after that we commercialized it. Ultimately, 15 sites around the world, most of them universities, leased FLACC. Thousands of students learned their craft using Algol68 and FLACC. I still bump into a few now, some 25 years later. Part of this journey took us to the University of Alberta (Canada), where Barry was my Master’s supervisor. Colin and I finished up the implementation, and I wrote my thesis about how the run time system worked. It is that thesis that follows. I have reproduced it exactly here. It was after the thesis was published that we changed the name from FLASC to FLACC (student to checkout) for commercial purposes, and also extended it in several ways, including producing object modules. One note to the less-than-grizzled reader: in 1975, IBM was king and System/370 mainframes ruled. Unix and C had just escaped Bell Labs, and VAX was still on the drawing boards. There were no PCs. All serious systems programming was done in 370 Assembler, and everyone knew that a pointer was three bytes. These notions seem quaint now, but their pervasiveness at the time strongly influenced the FLACC design and implementation. I reproduce and republish this thesis in the hopes that it will provide some elucidation or at least entertainment to students of Algol68 or of compilation techniques. General permission is granted to copy in whole, or extract portions, provided it is without modification and with attribution. Chris Thomson Pleasanton, California, May, 2011 THE UNIVERSITY OF ALBERTA THE RUN-T~ME STRUCTUREOFAN ALGOL 68 STUDENT CHECKOUT COMPILER by CHRISTOPHER MARK THOMSON A THESIS SUBMITTED TO THE FACULTY OF GRADUATE STUDIES AND RESEARCH IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTEROF SCIENCE DEPARTMENT OF COMPUTING SCIENCE EDMONTON, ALBERTA FALL, 1976 THE UNIVERSITY OF ALBERTA FACULTY OF GRADUATE STUDIES AND RESEARCH The undersigned certify that they have read, and recommend to the Faculty of Graduate Studies and Research for acceptance, the thesis entitled THE RUN-TIME STRUCTURE OF AN ALGOL 68 STUDENT CHECKOUT COMPILER submitted by Christopher Mark Thomson in partial fulfillment of the requirements for th,e degree of Master of Science. f?::~-; ,~ ~V'"tG%.perv~~/!;sor} !1~ /.7~.). °1110~1..~' . •e_•••••e_••~~ e _••• • • • • e _ • ea. • • • DATE THE UN I V E R SITY o F ALBERTA NAME OF AUTHOR ~ Christopher Mark Thomson TITLE OF THESIS : The Run-Time structure of an ALGOL 68 Student Checkout Compiler DEGREE FOR WHICH THIS THESIS WAS PRESENTED: Master of Science YEARTHIS DEGREE WAS GRANTED: 1976 Permission is hereby granted to THE UNIVERSITY OF ALBERTA LIBRARY to reproduce single copies of this thesis and to lend or sell such copies for private, scholarly or scientific research purposes only. The author reserves other pUblication rights, and neither the thesis nor extensive extracts from it may be printed or otherwise reFroduced without the author's written permission. (S1"gned) •••••••C•• £~-<T)IT\.At ••••••••••• -----.--- _ PERMANENT ADDRESS: *904-8515-112 Street Edmonton, Alberta T6G lK7 ~/o<:~+- DATED ., ....._ .... 1976 Abstract A run-time structure suitable for implementing a checkout compiler for ALGOL 68 is described. First, a set of design objectives are given; then the structures and algorithms used at run time are described. Difficulties with tracing are discussed. An outline is given of how dumping might be done. Finally, some pragmatic considerations are presented. iv Acknowledgements I would like to express my appreciation to Colin Broughton, author of the compiler portion of the FLASC system. his whip wielding, coddling, and pointed questioning were monumental in keeping me on the straight- and-narrow throughout the project. I would also like to thank my supervisor, Barry Mailloux, for his support, and tolerance of my railing at aspects of the language which posed difficulties. Also, I would like to thank Jim Heifetz, who contributed many ideas in many long discussions. Table of Contents Chapter 1: Introduction.e. • 1 101 Design Goals •••••••••••••••••••••. •• 1 1.2 Aspects of the Language •• • • e ., • • • • • • • • • • • • • ~ • • • e .4 Chapter 2: Run-Time structure. e •••••• ,. .7 2.1 Type of Object Machine •• c • • ..7 2.2 Type of Object Code ••• .8 2.3 Memory Allocation ••••••• .....,. 10 2.4 Storage structures •• .8.•••••• •. ... 12 Def Bits ••••••••••••••• 12 Refs •••••..••.......... • • • • • • e •• to • 13 Rows ••••••••• .., ., . ...... •••••• .,• 0 • 14 structures ••••••••••• . 16 Miscellaneous Objects ..•• •• • •••• 0 •.•••• 17 Tasks and Ranges. •••••• e'., • • • e • • e G••••••• 1 8 Mode Templates ••••••• .- ........... • e., •• e •••• 21 2.5 Algorithms ••••••••••••••••••••••• ~. ... ••.23 Denotations.............. e •••• ...23 D.er.·eferencing ••••••••••• .••• 024 Assignment and Ascription ••• .... ., ... ••••• 25 Slicing ••~ ••••••••• ..26 Multiple Selection ••• .e 29 Selection •••••••••••• ..., . ••••••• 30 Rowing and Enroving •• .• .. • •• 31 Declaration, Generation, and Skip. ~•• 32- Block Entry and Exit •••• ..... • ••. 34 Calls and Returns •••• • e ., ••• ••.. 35 Loops •••••••••••• .... ... •••• 36 Choice Clauses ••• • .••• 37 Paralle.lism••• .•••38 GotOSe •••e•••• •••• •• • • •• ••• e • ct •• ... • •• 40 2.6 The Garbage Collector. .... Chapter 3: Error Checking ••••••••••••••••• ..& ..46 3.1 Types of Errors ••••••••••• e ••••• ••••• e • •••• lJ.6 3.2 Some Error-Checking TeChniques •• ... ..• •••• 51 Chapter 4: Tracing and Dumping ••• •••59 4.1 Tracing................ •••• •• e_ •••60 4.2 Dumping ••••••••••••••••••••••••• •••63 Chapter 5: SOIDe Pragmatic Considerations ••..•••..._ ....•• 66 References ••••••••••••••••••••••••••••••••••••••••••..••• 69 vi ~ - - -- - - --- --- -- ------ - .--. - W~··"--""""~"--'~~...1:w~~~""",,"'· __ .c..5.>~ _~ - -- • Chapter 1 Introduction 1~ Design Goal§ ALGOL 68 is, in many ways, a suitable language for teaching Computing Science. The language has well-defined syntax and semantics, and em~loys many of the concepts of Computing Science. It is also a "growth" language, in that a student can continue to use it as he becomes more sophisticated. This is not to say, however, that it is complete: there is still a need for other languages. However, there is no doubt that a student-oriented compiler system for ALGOL 68 is necessary to its acceptance as a tool for instruction. In this thesis, such a system is described. The thesis concerns itself primarily with the design of the run- time system, or object-machine interpreter. The primary emphasis is on error checking, tracing and dumping, and how they are accomplished. The design described herein has been implemented (as a separate project) on an IBM /370 as the 1 2 FLASC system (Full Language ALGOL 68 Studant Compiler, ( 4, 10]). Many definitions have been given fort-he term "student compiler" [1. 3, 5, 6, 7], each differing slightly_ Our design goals reflect what we mean by this term: 1.Fast compilation In a student "cafeteria" programming environment, the emphasis is on compilation: programs are compiled repeatedly until they appear to be correct, then are thrown awaYe For this reason, efficiency of execution is a strictly secondary consideration. 2. Extensive run-time error checking It is essential that checks be made ·for uninitialized values, sUbscripts out of range, scope violations, arithmetic overflows, and similar errors. All of t~ese checks must be made at run time, since it cannot be guarant€ed that a compile-time check will suffice in general. 3. Tracing and dumping It is important that the user be able to trace the flow of his program, as well as the values of key variables. Symbolic dumps are also ot great use in discovering what has actually occurred in a 3 program run. 4. Lucid error messages Nothing is less informative than a "something went wrcng somewhere" message. Care must be taken to ensure that error messages both locate and describe the error in a clear, comprehensible manner. It is often advisable to give typical causes and solutions. 5. Indestructability The system must be secure, in that the user must be restricted to his work space. 6. Cost limitation There must be provisions for imposing time and output limits on student runs. 7. Memory residency The use of overlays and utility datasets tends both to increase cost and to degrade real-time performance. 8. No object modules The compiler/run-time