SL/1(ID:3223/sl:004)Subset of SIMPL-TSubset of SIMPL-T for the Langley Star machine Places People: Hardware:
Related languages
Samples: References: Design Justification Some Justifications will be given on why this approach satisfies the design goals. At the lower level, a sequentially oriented language could be extended by incorporating some form of vector processing capability. This is the approach being taken by CDC in the development of their FORTRAN compiler for the STAR-100. However, these extensions inevitably take on the appearance of patches to the basic language design and valuable support constructs, such as appropriate data and control structures, are usually missing. This can leave the language with an inconsistent and cumbersome design. Certainly, an implementation of FORTRAN, perhaps with extensions, is needed to allow existing programs to run on the new machine. FORTRAN has the benefit of being well known and used by the relevant programming community. However, this familiarity is also a drawback since the user is in the habit of writing algorithms in FORTRAN which are centered around the manipulation of scalar quantities. For a machine like the STAR, this is not the appropriate level of algorithm expression for making best use of the hardware. Recognizing the equivalence of sequentially written algorithms to a single machine instruction is impossible in the general case, and is often inefficient in those special cases that are worth detecting. For example, the following piece of FORTRAN evaluates a polynomial with a set of coefficients A and for a set of argument values X: l0 LIMIT = N+l DO l0 J = 1,M VALUE(J) = X(J)'A(1) DO i0 I = 2,LIMIT VALUE(J) = (VALUE(J)+A(I))*X(J) This is equivalent to one machine instruction on the STAR. Recognition of this fact by special case is quite difficult and costly. Thus, the implementation of a compiler for the language is a major effort since it requires the translation of all of FORTRAN, the new special features, along with any number of special recognition cases that are to be included. The choice of a language which is much higher than the level of the machine is theoretically a better choice. An existing language like SETL could be chosen, or a new language could be designed. Relative to the design goals, the very high level nature of the language would most likely eliminate the need for extensions. It would certainly permit the easy expression of high level algorithms theoretically suitable for efficient execution on the machine. The practical implementation of the optimization techniques is another question. The primary drawback to this high level of language, however, would be the major design and implementation effort involved. Unless an existing language like SETL is chosen, the language design effort alone is an extensive research undertaking. In either case, the implementation of such a language is beyond the resources available to the project. In addition, compile time for programs written in the language would be inordinately high, and there are some strong feelings in the user community against programming at so high a level because of the lack of user control over run time efficiency. SL/i is designed at a level that capitalizes on vector architecture, and corresponds closely to the level of the machine. In designing a language at the machine level, care must be given to specifying a consistent, easy to use, reliable language which makes use of the power of the hardware without exposing the user to hardware idiosyncrasies. The purpose of this design effort is not a high level assembly language, but a high level algorithmic language that would provide the user with the appropriate set of data and control structures for expressing algorithms in a readable and efficiently executable form. The language design is relatively simple, which makes it easy to extend. The basic conservative language design was motivated partially by the design for the base language SIMPL T of the SIMPL family of programming languages. SL/1 is meant to be a base language for a possible family of languages, each of which would serve a special application area of the user community. Each language could be designed as an extension to the base language and the compiler built as an extension to the base compiler. It is difficult to specify a consistent design level for a bi-level (both scalar and vector instructions) machine like the STAR. However, the specification of basic data types and data structures in SL/1 solve both the consistent level problem and the problem of forcing the user into making maximum use of the machine hardware. Scalars (real, short real, integer, character, ...), vectors (real vector, short real vector, integer vector, ...), and strings (character string, bit string .... ) are available data types in the language. The only data structure in the language is the array, and only vector and string data types may be stored in arrays. Thus, the user is forced to vectorize scalar data when it is necessary to structure it. This permits the most effective use of the machine for entities such as real arrays since the high level vector machine instructions may be used to deal with them directly. 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 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 |