1130 Amtran(ID:7939/)
Amtran on the 1130
Implementation of Amtran on the IBM 1130 at Georgia under Reinfelds
Related languages
| AMTRAN | => | 1130 Amtran | Implementation of |
References:
The characteristics of a problem which is likely to be encountered in the field of problem solving
+ compute bound
+ small amount of data handling
somehow relate to the characteristics of the small computer
+ powerful central processing unit
+ small core storage
The main difficulty lies in the specification and execution of the sometimes complex computational algorithms within the limited amount of core storage without accessing the secondary storage device too often.
A compact specification of an algorithm can be achieved by a set of powerful problem oriented language operators . For example, the mathematical expression (Simpson Integral)
can be calculated in two AMTRAN statements:
since the integration operator is part of the basic AMTRAN system. Similar examples can be given for the powerful SYMBOL operator and many other language features. Such a user oriented source level language makes it possible to express complex computational algorithms within a few lines of source code and correspondingly in a small number of core storage locations. The implementation of an interactive system on a small computer is much more critical if the source language requires a large number of statements (and core storage locations) to express rather common user algorithms.
The second part, the execution of the complex algorithms within the limited amount of core storage is solved by a problem oriented system design. Such a design is only possible in a dedicated system, which does not have to take account of all requirements which are part of a general purpose operating system.
The implementation of the AMTRAN language on the IBM 1130 computer is disc oriented.
All input output modules and the disc organization are specifically designed for optimum efficiency in a dedicated timesharing environment. Only a part of the system programs reside in main storage at any one time. The remaining programs are in core image format on the Fixed Area of the system disc. They are organized in a number of overlays each one of which fills exactly one cylinder. No effort has been made to create device independent data sets since the additional overhead cannot be justified on such a small system . All system programs are reentrant and it is therefore not necessary to write them back out on the disc. All user dependent information is in the particular user area.
The translation of the source code to an Intermediate object code is done in one pass . This intermediate object code, a polish representation of the source code, consists of a series of calls to the appropriate execution routines and the associated parameters . The execution routines perform the actual operations, the program linkage, the run time checks and the data management . The user area is completely dynamic . There is no fixed boundary between the program space, data space, the namelist, the translation stack, the execution stack etc.
It is therefore possible to write recursive programs in AMTRAN.
The structure of the translator has been influenced by the language definition [3] which makes a clear distinction between the structural and semantic characteristics associated with each language element . Since AMTRAN does not require dimension or type declaration statements, the checks on the dimension and type of a variable are not performed at translation time . Many different high level operators belong to the same syntactic class so that the same translation mechanism can be used for a number of them.
Because of the limited amount of main memory it is not possible to have more than one user area in core at a given time . This constraint has affected the system layout to a considerable degree . To gain optimum run time efficiency, the system can adapt to the characteristics of the particular user problem . This has been achieved by an overlay structure where each overlay is tailored to a specific class of user operations . For example, the modules for the logical operators and the conditional operators will be in the same overlay, the trigonometric and the basic arithmetic functions will be together etc. Many commonly used modules will be in more than one overlay . The composition of the overlays, which can be changed easily, has been determined by run time observations over a large number of user programs . The same is also true for the sequence of overlays on the disc to minimize excessive arm movements.
Such an approach will not succeed in a system, where several user areas reside in core at the same time because, in the general case, the problems being solved in them will not fall into the same category . A considerably larger number of core resident execution modules would be needed to get a comparable runtime efficiency for such a system.
Furthermore, if the services of a general purpose operating system must be used to guarantee overall system integrity, a new situation arises. The operating system standards have been determined by a completely different set of objectives (e .g . device independence, expandability, data management) and an optimization of the timesharing system within these standards will only lead to a suboptimal system . Although the gain in computing power according to Grosch's [4] law will definitely outweigh the increased overhead, the chances of system breakdowns because of increased complexity are increased . A dedicated system on a large computer is in many cases economically not feasible since, as Auerbach [6] states, only two to three timesharing terminals are used in a typical user installation.
in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
Introduction
AMTRAN is an interactive, mathematically oriented computer system consisting of one or more remote terminals with a special function keyboard and immediate output of solutions in numerical or graphical form via storage scopes.It is designed especially for engineers and scientists who have no previous acquaintance with computers hut want to solve their numerical problems as quickly and efficiently as possible . AMTRAN allows simple problems to be solved easily and also permits the construction of complicated algorithms.
This report gives a concise, semantically-oriented definition of the AMTRAN-language; it is not intended to replace a manual. It should instead be supplementary to a manual and is primarily thought of as an aid for the compiler writer and as an exhaustive and exact definition of the language and its unifying concepts.
A general method of definition (applicable for any mathematically-oriented computer language) has been developed with the following aim: the systematization and formalization should cover a much larger part of the language than 'syntax'-definitions or the definition by BNF-notation (Backus Normal Form; ALGOL 60 Report). This is achieved by systematizing a large part of ' semantics ' in formalizing notions like 'type', 'range', 'sign', 'dimension' of numerical quantities and 'binding power' of mathematical operators.
in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
Introduction
The purpose of this paper is to describe the state of development of the AMTRAN language as it exists at this time. The description emphasizes the basic concepts on which the language design is based. Some of these concepts are already well developed and complete, others need further development indicating that AMTRAN has not yet achieved a completed final form . Most of the concepts discussed are implemented on the 1130 AMTRAN system, but some are not implemented because our NSF grant expired before this implementation could be completed.
These concepts and further extensions including the full n-dimensional array arithmetic will be included in the next implementation which is presently in progress at CERN, Geneva, Switzerland, on a CDC 6600 computer.
The main aim of AMTRAN is to exploit the general n-dimensional rectangular array as a basic data structure, using operators derived from concepts familiar to a numerical analyst. All general purpose programming languages provide array handling through explicitly programmed loops. The emphasis of AMTRAN (as well as APL, Culler-Fried and Klerer-May systems) is to make such component handling loops implicit and invisible to the user by providing operators which operate on the whole array or, in other words, regard the array, rather than a single number, as a basic data type of the language.
Languages in general and AMTRAN in particular have at times claimed to be easy to learn and easy to use. In many cases such claims are heavily tainted with emotions and a lack of knowledge and understanding of other languages. The purpose of this paper is to establish a rational base upon which AMTRAN's claim to simplicity and learnability may be founded.
It seems reasonable to assume that some measure of the ease with which a casual user can learn a computer language is given by the number of new concepts he has to learn before he can solve his particular problem with this language. Therefore, this paper describes the AMTRAN language through the concepts and rules an average user has to learn before he can solve his problems with it.
The average user is a scientist who has no background in computer science, but has some knowledge of numerical analysis or statistics. In other words, he should know the algorithms required to solve his problem. The average user will also know some Fortran because almost every science student of today is exposed to at least a one quarter introductory course on computing.
A concept is a conventional concept if it may be assumed known to the average user as defined above. More subtly, four broad groups of concepts may be distinguished:
(i) entirely conventional concepts, as for example -+- denotes addition in almost all computer languages in exactly the same way as addition is conventionally known in high school algebra and arithmetic.
(ii) partly conventional concepts, as for example * or / for multiplication or division which are largely conventional but contain a few clarifications and extensions such as a definition of A/B/C for linearly written expressions, the use of * for multiplication sign introduced by FORTRAN, the handling of division by zero, and so on.
(iii) entire new concepts, as for example the right to left rule of APL or the block structure of Algol.
(iv) disguised conventional concepts, as for example the declarations of FORTRAN. They appear as a new concept because they are introduced as 'non-executable statements which contain information to the compiler'.
They would appear conventional if they were interpreted as executable statements which create a data structure in the computer so that this data structure can later be filled with numbers or characters, manipulated and used in calculations . This interpretation would be very close to the conventional interpretation of the numerical representation of a mathematical function.
AMTRAN is an operator-operand language. All actions which are to be performed are expressed by operators which are the dynamic elements of the language . All actions are performed on operands which are the static elements of the language . Only the number of arguments assigned to each operator may be deduced unambiguously from the syntax of the source code.
The type and dimension of each operand is checked interpretatively at run time by the execution routines of the operators . By executing arrays as whole entities, interpretation is done once for each array and efficiency is improved by a factor equal to the reciprocal of the number of elements in the array.
This paper refers to the University of Georgia implementation of AMTRAN on the IBM 1130 computer . This implementation is similar to the Huntsville implementation for the IBM 1130, the Datacraft and PDP-9 computers.
Extract: Rules
2.0 Rules
The rules of a language give the user general guidance on how to use the language. The rules should be simple, clear, concise and general, like the axioms of a mathematical theory . They should avoid special cases and exceptions and apply directly to as many situations as possible.
Our inability to find such rules for most computer languages results in large user's manuals containing a compendium of special cases and exceptions to whatever rules are written down at all. Extract: Operand Rule
2.1 Operand Rule
Operands are used in three basic situations: assignment, procedural and value generating situations.
(i) in any value generating situation use any expression which may be constructed from the value generating operators defined in the language.
Exceptions: none
Consequences :
a) a computed GOTO is automatically a part of the GOTO statement of the language, provided that statements are labeled with numerical labels.
b) logical and relational operators must be regarded as an integral part of the generalized arithmetic as there is no syntactic distinction between Boolean and non-Boolean expressions. (ii) in any assignment situation use any name.
(ii) in case of assignment to array elements or subarrays the name may be subscripted.
Exceptions: none
Consequences:
a) the new value or program replaces whatever value or program, if any, was previously designated by that name.
b) no artificial conventions distinguishing type and/or dimension of variables from the lexicographic structure of their names.
(iii) in any procedural situation use any complete statement of the language. For example any complete statement (including an IF statement itself) may appear between THEN and ELSE or between ELSE and FI of any IF statement.
Exceptions :
Presently programs cannot be defined or edited by running programs. It is still a controversial issue whether self-modification of programs is desirable or not.
Consequences:
Powerful flexibility through nesting of statements within each other.
Extract: Operator Rules
2.2 Operator Rules
(i) expressions are evaluated from left to right with value generating operators obeying conventional priorities, but parenthesis may be used for easier reading or whenever a doubt exists as to what is meant by conventional priorities.
Exception:
Linear writing of expressions causes many unconventional situations where parenthesis may be needed for clarity as for example in A / B * C
(ii) arguments of all prefix operators should be placed in parenthesis. More than one argument constitutes an argument list where adjacent items are separated by commas.
(iii) operators are denoted by mnemonic keywords or conventional symbols (when such symbols exist) or single key-pushes on a special keyboard (when such a keyboard is available).
Extract: Blank Space Rule
2.3 Blank Space Rule
As in English, a blank space is regarded as a delimiter. Two or more adjacent blank spaces are equivalent to a single blank space everywhere except in the definition of a string array.
Extract: Humanizing Redundancy Rule
2.4 Humanizing Redundancy Rule
If syntactic ambiguity can be avoided, some of the above rules may be relaxed to permit redundant simplified notation in addition to the notation required by the rule.
For example: the requirement that arguments of prefix operators must be in parenthesis may be omitted if the arguments are simple identifiers or single argument functions . Hence, it is syntactically unambiguous to permit both forms sin(cos(x)) - sin cos x
in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details