LSD(ID:3109/lsd001)Language for Systems Developmentfor Language for Systems Development R. Daniel Bergeron, John D. Gannon, Andries van Dam Brown University PL/I with the addition of pointers, structure definitions, character facilities, and explicit declaration of coroutines. Related languages
References: Extract: Copy LANGUAGE FOR SYSTEMS DEVELOPMENT The Language for Systems Development (LSD) which is currently being implemented at Brown University is an attempt to satisfy the criteria described above. LSD has been designed specifically to be used on the IBM S/360. Hence, some of the terminology and even facilities are oriented to this type of machine. On the other hand, an effort has been made to limit the number of machine dependent constructs and to design all constructs, except those for low level I/O, In such a way that they may be interpreted in some reasonable manner on other machines. LSD is only the base language of a language system currently under development. When completed this system will contain the base language, an extensibility mechanisms a software paging system and an interactive debugging and program-writing facility. LSD is a procedure oriented language whose appearance and syntax are similar to PL/I. (Hereafter PL/I refers to the IBM implementation of the PL/I (F) compiler.) Some areas in which specific Improvements of LSD over PL/I have been made Include pointer chasing methods, structure definitions, character facilities, debugging and program linking, LSD might be viewed as a dialect of PL/I that is specifically designed for systems programmers. The syntactic differences between the two languages are generally minor and often merely a matter of personal preference. However, the basic philosophies are considerably different. The LSD approach is to let the programmer "get at" the machine, rather than to hide it from him. The hardware registers are explicitly available in the source code and may be used just as any other variable. Constants may be expressed in hexadecimal notation. As mentioned in the criteria section, data attributes are only used as a guide in debugging and generating code, and, in general, any specification of a construct wil1 be valid as long as the compiler can generate code. Implicit conversions will not be performed, but conversion routines are supplied and may be explicitly invoked by the programmer. in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details in Advances in Computers 12, (1972), Academic Press NY view details in Computers & Automation 21(6B), 30 Aug 1972 view details in ACM Computing Reviews 15(04) April 1974 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in ACM Computing Reviews 15(04) April 1974 view details In LSD, the user is allowed to specify alternate implementations of certain key constructions, specifically, interprocedure communication and dynamic storage allocation. The designers suggest that DO be done in some language other than LSD, presumably assembly language. When defining a procedure (in a PL/I-like language), the user can specify a macro to be used either for the entrance, the return, or both. Similarly he can specify the macro to be used by the caller; in this case the specification is associated with the entry declaration. Similar methods are used for "allocate" and "free." The macro expansions are specified by a "conventions" statement, and their invocation is triggered by the combination of a reference to the convention in a procedure heading, entry declaration, etc., and the actual procedure call. With these arrangements the user can obtain the default conventions with no additional effort, but can optimize critical interfaces when he deems it necessary. The article does not describe how LSD treats data structures, although it does provide facilities for them. Thus it is hard to compare LSD with, say, BLISS, another language for systems programming that has received much attention lately. [ See Wulf,W.; Russet, D.; and Habermann, N., " ;BLISS: a language for systems programming," Comm. ACM 14, 12 (Dec. 1971) pp. 780-790. ] The typesetting of the printed paper displays an amusing quirk: in many places the letter "O" has been misprinted as "C", so that, for instance, the paper mentions "Dc loops" (alternating current fans take note). in ACM Computing Reviews 15(12) December 1974 view details in ACM Computing Reviews 15(12) December 1974 view details in Klinger, A.; Fu, K. S.; Kunii, T. L. "Data Structures, Computer Graphics, and Pattern Recognition" (Largely based on IEEE Computer Society conference held in Los Angeles, May 1975) Academic Press, NY 1977 view details |