MU5 Autocode(ID:5962/mua001)Autocode for Machester MU5 computerAutocode for Machester MU5 computer Related languages
References: in The Computer Journal 15(1) February 1972 view details External link: Online copy Extract: Introduction At an early stage in the design of the MU5 software it was decided to introduce a compiler target language (CTL) into which the high level languages would be translated. For each high level language a translator would be provided to convert from the language to CTL while a single compiler converts from CTL to machine code. The objective was to simplify individual translators by forcing the CTL to as high a level as possible. For example, the CTL contains declarations with the characteristics of those found in high level languages so that name and property list management problems are passed to the CTL compiler. This scheme enables the mode of compilation, for example output in semi-compiled form or loading for immediate execution, to be determined within the CTL rather than within each translator. Subsequently, a further role for the CTL emerged. The MU5 translators could be used on a range of machines provided a CTL compiler could be written for each machine. This machine independence could extend over machines with significant structural differences provided the data and address formats were compatible. This idea is summarised in Fig. 1. It is similar to the UNCOL (Strong, Wegstein, Tritter, Olsztyn, Mock, and Steel, 1958) idea except that, whereas UNCOL attempted to span the significant differences between existing machines, the CTL has been designed to suit machines originating from MU5. There is, however, a more significant difference: the communication between the translators and the CTL compiler is two-way. Some of the CTL procedures return information to the translators. For example there is a procedure for interrogating property lists. It is this which allows the whole property and name list organisation to be contained within CTL. The CTL does not have to be encoded in character form by the translators then decoded by the CTL compiler. Instead there is a CTL procedure corresponding to each type of statement, so that the CTL is a body of procedures rather than a written language. The main input parameter of each procedure is a vector whose elements define the nature of the statement. In the case of an arithmetic assignment these elements comprise a sequence of operator operand pairs. Only a small increase in compile time results from using the CTL procedures to generate code, because they form part of a natural progression from source to object code. A loss of run time efficiency could arise from the translators losing the ability to control completely the code which is generated. This problem is largely irrelevant with MU5 because of the high level nature of the order code. For example, the addressable registers serve dedicated functions which correspond to identifiable features of the high level languages. Also the machine dynamically optimises the use of the fast operand store (Ibbett, 1971). If CTL were to be implemented on machines considerably different from MU5 in these respects then some theoretical inefficiency might result. In practice it is difficult to obtain compilers which compile optimum code, so that the inefficiency may be no worse than that already tolerated on many machines. In the overall software structure the CTL is the instruction set of the MU5 virtual machine (Morris, Detlefsen, Frank, and Sweeney, 1971). Hence compatibility in the notional MU5 range of machines is at the CTL rather than the order code level. There is an associated written form of CTL, MU5 Autocode, which is the lowest level of programming language and which is used for system programs. Extract: Design considerations Design considerations Two principal decisions have determined the overall characteristics of the CTL and the Autocode. The first of these was that the CTL and the Autocode should be structurally the same language. It is thus possible for the CTL compiler to generate the Autocode equivalent of a program in any source language. A number of minor advantages stem from this ranging from the debugging of compilers to the hand optimisation of important programs. In the light of past experience it was also considered advantageous for the compilers to be written in the same language as they generate. The second decision was that the CTL and the Autocode should be a high level representation of the MU5 machine code. For example, it will be seen that the declarations relate to physical data items in the machine rather than logical data types. Also the variables are typeless, as are operands in the machine, permitting arbitrary manipulation using any kind of arithmetic. Consequently, in MU5 Autocode information about data structures is embedded in the code rather than just in the declarations as in PL/1 or ALGOL 68. However, it is not clear that, on balance, any significant loss of clarity results from this, particularly since operand accessing in MU5 is very flexible. Furthermore, efficiency considerations will often dictate that such structures be carefully designed to fit the machine. Additional practical considerations reinforced this decision. Firstly, because the hardware and software of MU5 will be commissioned together, it was considered preferable for the language to reflect the hardware accurately. Secondly, the dependence of the rest of the software on the CTL and the Autocode necessitates a short time scale for their development. The Autocode representation is the best way of describing the structure of both this and the CTL. An example of a procedure for sorting an array in descending order using linear selection is given in Fig. 2. From this the basic language structure should be apparent. In the following sections the form of data, the operations available and the overall control structure are described. Extract: The Autocode computation statements The Autocode computation statements Each arithmetic computation to be performed requires an implicit or explicit specification of the type and size of arithmetic required. The Autocode provides many arithmetic modes but no particular one is considered to be the fundamental mode. It is assumed that only those modes justified by the primary use of a machine are provided in hardware, the rest being provided by software. The arithmetic modes are signed and unsigned integer, real and decimal of size 32, 64 or 128 bits and a Boolean mode. In MU5 32-bit signed and unsigned integer, 32- and 64-bit real, and Boolean modes are provided in hardware together with some special functions to aid the software implementation of other modes. The mode is specified at the start of each statement and is following mainly by operator operand pairs. Each of these pairs generally corresponds to a machine instruction; hence the code compiled is closely controlled. The operator precedence is strictly left to right, in contrast to most high-level languages. There are several reasons for this. Firstly, the calculations in systems programs are often of a logical rather than a mathematical nature, and use operators for which precedence rules are not well established. Secondly, it is easier to see that efficient code is being compiled when evaluation is left to right than when implicit stacking of partial results is taking place. Thirdly, since different languages have varying precedence rules an equal precedence convention is the most convenient for use in the target language. Precedence can be forced by the use of bracketed sub-expressions which explicitly demand the stacking of a partial result on the opening bracket, and the application of a reverse operation on the closing bracket. This is shown in the following example of a typical statement equivalent to the ALGOL E : = (A + B)/(C + D) R64, A + B/(C + D) = > E R64 is the 64-bit real mode of calculation; A, B, C, D and E are operands, and / + and = > are the divide, add and store operators respectively. In MU5 this statement would translate to : ACC = A ::set the floating-point accumulator to the value of A ACC + B :: add the value of B ACC*= C ::stack the partial result and load the value of C ACC + D ::add the value of D ACC (ZI STACK : :reverse divide by the stacked partial result ACC=> E ::store the result in E Extract: Conclusion Conclusion The Autocode and CTL have been implemented in a simulated MU5 system on an ICL 1905E. One translator, for Atlas Autocode, is already running in this system. The development of others for ALGOL, FORTRAN and PL/1 is well advanced. The MU5 implementation awaits the commissioning of the hardware after which the translators should be transferred without modification. A compiler for a subset of the Autocode which generates 1900 code is also available. This is being used to develop operating system modules which will also be transferred to MU5. The 1900 code generated is sufficiently good for these modules to be used as part of the 1905E operating system (Morris, Frank, Robinson, and Wiles, 1971). in The Computer Journal 15(2) 1972 view details DOI in SIGPLAN Notices 10(03) March 1975 Proceedings of the conference on Programming languages and compilers for parallel and vector machines, January 1975 view details in SIGPLAN Notices 10(03) March 1975 Proceedings of the conference on Programming languages and compilers for parallel and vector machines, January 1975 view details |