AS Intercode(ID:2806/asi003)Port of Intercode to run at Armstrong SiddleyRelated languages
References: Intercode is an interpretive routine for the Ferran Mark I* computer, providing for 11 three-address pseud instructions and 100 floating point numbers. It is useful fo training programmers and for short computing problems C. C. Gotlieb, Toronto, Ont Rev. No. 4573, Math. Rev. 21, 7 (July-August 1960 Extract: Introduction AMOS is installed in a research and development establishment where it is expected to satisfy the computing requirements of many different groups. All the computing problems which have arisen in practlce can be put into one of two distinct classes. There are large problems, most of which involve the solution of partial differential equations and often require new computing techniques, and small routine problems involving no more than substituting numbers into formulae. AMOS has proved extremely satisfactory for the large problems, for the following reasons. It is not difficult to program in the basic code of the machine and so exploit all its possibilities. The coherent logical design of the whole machine and the flexibility of a one-address code are a definite advantage when organizing the mechanical computation of these large problems. Moreover, the total storage capacity of the machine has proved ample for all the programs written so far; the maximum size of problem which may be computed on AMOS is likely to be restricted more on account of running time than by storage capacity. AMOS has not proved so satisfactory for the user with small computing problems. It is clear that a machine of much smaller capacity would be adequate, and certain differences in basic structure would be desirable. Since AMOS must nevertheless be used for small problems, an alternative system of programming has been devised, which in effect makes AMOS behave like a smaller machine more suited to small, routine computations. This system is called Intercode; it was inspired chiefly by the Mark I Autocode (Brooker, 1956). Unlike the Mercury Autocode (Brooker, 1958), it is not intended to replace programming in the basic code of the machine, except for a strictly limited range of problems. Indeed, many conventional programming techniques were deliberately retained in Intercode so that it might also serve as a first step in learning to program in the basic code. Extract: BASIC FEATURES OF INTERCODE BASIC FEATURES OF INTERCODE For the purpose of multiplication in AMOS, the position of the binary point is considered fixed, so that all the numbers occurring in a computation must be less than 2 in modulus. While it is often possible, especially in partial differential equation problems, to choose variables which stay in the range 5 2 , intermediate results frequently go "out of range," so that a programmer has to introduce extra scaling into his program, as necessary. No extra scaling would be needed in 9OU,, of tlic problems done on AMOS if results as big as 103 could be accumulated directly. In Intercode, numbers may go up to 239 (about 5 x 10"); this removes the scaling problem completely, allowing all practical computations to be carried out in the original physical units, with a reasonable margin of safety for intermediate results. As far as the programmer is concerned, the storage in Intercode is all on one level and there is no question of access time. The instructions and numbers are kept quite separately. The capacity of the instruction store is limited only by the addressing system chosen for jump instructions, and is, in fact, far larger than will ever be required. In the type of computation for which Intercode was designed, there are never many numbers involved simultaneously. A number store capable of holding 100 numbers is therefore adequate and the location of any number can be specified economically by a two-digit decimal integer in the range 00 to 99. in The Computer Journal 2(2) July 1959 view details Other TWSs ETC (Garwick [Gar 64], Gilbert [Gil 66] and Pratt [Pra 65]) In this section we describe three other efforts, that are best described as syntax-directed symbol processors. For various reasons, these systems have not had the impact of those discussed above and are presented in less detail. The GARGOYLE system [Gar 64] was developed for the Control Data 3600 by Jan Garwick at the Norwegian Defense Establishment. There are reasonably complete descriptions in internal reports, but the published paper [Gar 64], which was written first, gives only a vague picture of GARGOYLE. GARGOYLE is like TMG (Section III.A.1) in many ways; the recognizer is top-down with a facility for directing the search. All syntactic and semantic statements are written in a five-entry tabular form: (label) (else} (next} (link} (action). The sequencing rules are quite complex (partly because backup is handled implicitly) and are normally done by a "steering routine." The backup mechanism also requires complicated data handling involving stacking of some variables and copying of others. All five entries are used in multiple ways; e.g. the label may instead be a code controlling how the line is to be interpreted. The following example would be used to process an (assignment statement). (label) (else) (next} (link) (action} R ASSIGN L VAR 0 VARIABLE 1 1 NEXT 2 if S YMB=:COLEQ then VARy----WORD 2 3 ASSIGN 4 3 EXPR 4 4 RETURN OUTTEXT ("STO", 10); OUTFIELD (VAR, 20) ; The first line is the header for routine ASSIGN, whose local variable, VAR, is declared in the second line. If VARIABLE finds a (variable} then the next symbol must be COLEQ (":=") or the routine fails. Line 2 is a recursive call of ASSIGN for treating multiple left sides; the first backup will lead to EXPR (which will compile the right side), and subsequent returns will execute statement 4 once for each variable in the multiple assignment. The (action} in statement 4 produces text for storing into each successive value of VAR. The language of the (action} column includes partial word operators and a few fixed routines for table searching, input-output, etc. The GARGOYLE user is expected to embed assembly statements frequently, and the entire (action} language appears similar to the high level machine language of [Wir 66a]. GARGOYLE has been used by its author to help implement a complex language [Gar 66], but its wider use will require a somewhat cleaner design and considerably better publication. Thc TWS of Gilbert and McLellan [Gil 67] is based on some syntactic ideas of Gilbert (Section II.C, [Gil 66]) and an attempt to revive the UNeOL [Ste 61] concept. Source programs are to be translated into a machineindependent language, BASE, which in turn can be translated into many machine languages. The first translation is described in an intermediate language which is a macro assembly language having a few fixed data structure conventions; the second translation is described in a string form like that of TMG. Although there are a number of good ideas in the paper, they are not significantly different from others in this section. Some of the bad ideas, however, are uniquely illustrative. The UNCOL notion of a machine-oriented but machineindependent language has always foundered on the diversity of languages and computers. Gilbert and McLellan attempt to avoid this by Mlowing new operators to be defined in BASE and passed blindly to each BASE-to-machinelanguage translator. This gives the appearance of machineindependence but leaves untouched the basic problem of which macros to choose. The authors also make a point of the fact that their system is "rigorously based." This presumably encouraged them to use the set of strings "AmB-AmB-CCC '' as the programming language example illustrating all aspects of their system. Finally, in a classic example of misplaced rigor, they exclude infinite loops from their system by not permitting loops and go to statements. The only reference in this paper [Gil 67] to other TWS literature is [Ir 61]. The AMOS system developed by Pratt and Lindsay [Pra 65, Pra 66] is a direct application of list-processing ideas to TWSs. The source language is translated into an intermediate language (I-language) which is interpreted by AMOS. The I-language is a simple list processing language with some string processing operations and crude arithmetic; e.g. "*ADD* P1, P2, P3" means "add P1 to P2 and put the result in P3." The I-language was designed to be minimal and to be expanded in macro fashion. The syntax is treated by a variant of production language (Section II.B.5) relying heavily on recursive calls; the semantics is written in I-language. The most interesting feature of AMOS is the attempt to provide for the translation of data structures as well as programs. AMOS has had some minor successes in handling list structures, but the problem deserves much more attention (ef. Section IV.C). in [ACM] CACM 11(02) (February 1968) view details in Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details |