IMP80 Language Manual
KEY To use the Index, type "index," followed by the entry you require followed by '?'. E.g. index,record? Type C to get the full contents list. Abridged contents: PREFACE TO MANUAL /2 HISTORICAL INTRODUCTION /5 ELEMENTS OF THE LANGUAGE 1 TYPES, VARIABLES, CONSTANTS AND EXPRESSIONS 2 BLOCKS AND PROCEDURES 3 EXECUTABLE STATEMENTS 4 INPUT/OUTPUT FACILITIES 5 STORE MAPPING 6 STANDARD PROCEDURES 7 EXAMPLES (TO FOLLOW) 8 APPENDIX A: IMP80 SYNTAX 9 APPENDIX B: IMPLEMENTATION-SPECIFIC INFORMATION 10 APPENDIX C: EMAS - IMP80 CONVERSION 11 INDEX 12 .... Preface to manual follows ....
PREFACE This manual describes the programming language IMP80, which is a common subset of several extant versions of IMP. The reason for the existence of these different versions is explained in the "Historical Introduction" (below). It is intended that for the foreseeable future implementations of IMP will follow IMP80 as far as possible, and in particular will not depart from it for frivolous or cosmetic reasons; however, this does not preclude implementation-specific extensions. Separate sections of Appendix B will be provided for each major implementation of IMP80. These detail departures from or extensions to IMP80, and include relevant system-dependent information. Such system-dependent information is also included occasionally within the main body of the manual, where it was felt that to have excluded it would have been inconvenient or even misleading. Such material is clearly flagged as not describing IMP80 itself, and is always repeated in the relevant section(s) of Appendix B.
There are two implementations of IMP80 at the time of writing: EMAS IMP80, implemented on the ICL 2900 range by Peter Stephens, ERCC; and IMP77, implemented on several different machines by Peter Robertson, Lattice Logic Ltd., Edinburgh. This is primarily a reference manual, and it is hoped that the contents list and index are detailed enough to enable it to be used as such. In addition, however, it is felt that guidance on the use of language features should be given, as their utility might not be apparent from a statement of their syntax and semantics alone. The programming examples included for illustrative purposes are also intended to indicate good programming practice. Furthermore, Section 8 includes advice on writing IMP80 programs as well as some larger examples. A Backus-Naur Form (simplified) specification of the complete syntax of IMP80 is given in Appendix A. An explanation of the conventions used in the syntax definition is given at the end of Appendix A. This manual was written by Felicity Stephens and John Murison, apart from the Historical Introduction by Peter Stephens. Much of the text is based on earlier documents, in particular: "The Edinburgh IMP Language Manual" (second edition) edited by Roderick McLeod, Edinburgh Regional Computing Centre (1974), and "The IMP-77 Language" (third edition) by Peter Robertson, Department of Computer Science, University of Edinburgh (1980). Please report any suspected errors or omissions in this manual to the ERCC Advisory Service, James Clerk Maxwell Building, The King's Buildings, Mayfield Road, Edinburgh EH9 3JZ. John M. Murison Editor October 1981
HISTORICAL INTRODUCTION Evolution The Imp language is evolved from Atlas Autocode, which itself is a direct descendant of Algol 60. Although Algol 60 had only moderate success as a programming language - it was hardly used in the United States - no other language before or since has achieved more than a fraction of its influence on programming language design. At the same time as Algol was being devised and revised, in Manchester another event was taking place which was also to have wide influence. The University was building its fourth machine (the Atlas) - which true to tradition was at the very limit of the technology of the time. This machine was to introduce paging to the world; the idea being that memory management, provided by the operating system with hardware support, was cheaper and more efficient than allowing each programmer to overlay or shoehorn his program into the space available. After a slow start, this idea was to change the appearance of computing. Since Atlas was a revolutionary machine, Manchester had to write their own software, as they had done for the Manchester Mark 1 and Mercury. This led them to consider the attractions and disadvantages of Algol.
Algol's principal attraction is its block and stack structure: by collecting space together on a stack and re-using it for successive procedure calls, an Algol program causes much less paging than the same program written in (say) Fortran. The disadvantages of Algol are the lack of standard input/output and the difficulties that some features of the language present to the compiler writer. The tragedy of Algol was that so little was gained from the features which presented most of the problems. Almost nothing of real power was gained either from call by substitution or failure to specify formal procedures adequately, and little was gained by the enormous generality of the %for statements. Yet the problems these areas posed caused all early Algol compilers to produce comparatively low quality object code. All this and more was obvious to the Manchester team and although Algol was to be implemented on Atlas, the prime language was a new one - Atlas Autocode. This was a simplified Algol with changes to the block, loop and procedure structures to remove the worst problem areas. It contrived to deliver 90% of the power of Algol to the programmer while only requiring 25% as much effort from the compiler writer. (Further details can be obtained from The Computer Journal, Vol 8, pp 303-310 (1965/66)). In retrospect, the name was unfortunate since autocodes were normally low level languages, and "Atlas" indicated quite wrongly a degree of machine dependence. Edinburgh University started its computing with a data link to the Manchester Atlas and this happy accident began the long association between the University and the language. When Glasgow and later Edinburgh obtained KDF9 computers it was necessary to write a compiler for Atlas Autocode; this was carried out in a short time by Mr (now Professor) H. Whitfield and his associates. This compiler was in advance of its time in that it was written entirely in Atlas Autocode and developed on Atlas. It was transferred to KDF9 by the elegant technique of self-compilation. The compiler thus produced compared exceedingly well with the manufacturer's Algol compiler, both in compilation time and in object code efficiency. This project also confirmed that Atlas Autocode was free of implementation trouble spots and very suitable for large scale system programming.
In 1966 there began a large scale project with a joint University/Manufacturer team to write a time-sharing operating system for the ICL 4-75 computer. The project was based in Edinburgh and the final system would have to support Atlas Autocode among other languages. The recent success of the Atlas Autocode compiler project led to the decision to implement the time-sharing system (later called EMAS) in a high level language called IMP. IMP was to be a superset of Atlas Autocode, containing additional features for system programming. It was at this point that almost all the main language changes were made and the distinctive philosophy of IMP originated.
Philosophy and Style IMP was to be primarily a system programming language; in 1966 that was perceived to require: * efficient object code. System programs are liable to be executed millions of times. Thus features that could not be implemented efficiently should be omitted. * early compiler availability. The compiler should be available as soon as the hardware, otherwise programmers would program in something else. Consequently features that would or might cause implementation trouble spots must not creep into the language. * minimum run-time support. Some system programs like supervisors and loaders have to run in an environment almost devoid of support software. The language should be free of features requiring run-time support. (The Atlas Autocode fault statement conflicted with this aim and had to be banned from system programs, although retained in the language for user programs.)
* readability. System programs have a long life and require maintenance. It is more important that the program be easy to understand than quick to write. Optional keyword omission or abbreviations should be banned. (The language should be "verbose rather than obscure".) * access to bizarre hardware features. System programs require access to funny features - to blow the hooter or ring the gong on hardware failure, for example. However the language would not be compromised here. Instead machine coding would be allowed at any point in the program, with access to the IMP variables and arrays. Even with fifteen years of hindsight this list still seems very relevant, although the need for efficient object code was more pressing then than now. The real key to the long life of IMP is the last item in the list. By allowing machine code in extremis almost no machine dependent features were included except the underlying one of a byte address structure. Consequently IMP has been successful on a dozen or so machines, unlike the main competitors of the era (PL360, Burroughs Extended Algol).
In accordance with the language philosophy, the following changes were made to Atlas Autocode to produce IMP: * The internal character code was changed to ISO. * Logical operations were added to the language. * The additional declarators %byte %integer and %short %integer were introduced. * Structured data objects - %records - were introduced. * Text handling features were added specifically to aid writing of command interpreters. * Pointer variables and additional features were added to enable programmers to operate on storage areas outwith the compiler controlled stack.
This language was used in the writing of EMAS and it proved possible to write a high performance multi-access operating system almost entirely in IMP. (Those requiring further information should read The Computer Journal, Vol 17, pp 216-223 (1974).)
Recent Developments After the successful completion of EMAS, responsibility for maintenance of the system and the IMP compiler passed from the department of Computer Science to the Edinburgh Regional Computing Centre. Over the next ten years the language evolved very slowly - even a move of EMAS from ICL 4-75 to ICL 2900 hardware scarcely disturbed the stability of the language. However, the Computer Science department, in pursuing its diverse research interests, encountered a variety of machines and wrote IMP compilers for a substantial proportion of them. As befits an academic department these compilers contained novel features and gradually diverged from EMAS IMP and from each other. In 1980 a stock-taking was instituted, from which there gradually emerged the common core of features described in this manual. Most compilers will have some additional features but will support this common base, and it should be possible to write most programs in the common subset. Such programs should be readily portable in the Edinburgh environment. P.D. Stephens