SAP(ID:5252/sap002)
SHARE Assembly Program
for SHARE Assembly Programming
Not really a renaming, but the same name incorporating a new Acronym.
Related languages
| PACT I | => | SAP | Influence | |
| SAP | => | SAP | Renaming | |
| SAP | => | Macro SAP | Extension of | |
| SAP | => | SAP II | Evolution of | |
| SAP | => | SQUOZE | Augmentation of |
References:
Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming.
Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system.
Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's.
What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers.
Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered.
Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO
The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free.
in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
in Preprints of papers presented at the 13th national meeting of the Association for Computing Machinery, June 11-13, 1958, Urbana, Illinois view details
Introduction to the Problem
DEUCE is a two-plus-one-address computer having twelve 32-word mercury delay lines of rapid-access storage, and an 8,192-word magnetic drum backing store (see Haley, 1956). It has proved to be a powerful tool for both scientific and commercial applications, and its usefulness is greatly increased by a large library of subroutines and programs. The cost of the machine places it in the medium-scale computer class, but the speed of operation is comparable to machines in the large-scale class. Certain aspects of programming DEUCE, however, are clerical in nature, and can be somewhat tedious; such programming work might well be left to the machine itself.
The object of the work leading to this paper has been the development of a programming scheme which makes the writing down of a program much simpler and more straightforward than normal DEUCE programming. This is because the SODA language is closer to that of a mathematical language, and includes strong mnemonic aids. Any sort of intermediate routine which eases the programmer's work is especially of value in an academic environment. Universities tend to have a great number of problems which necessitate the use of a computer, but do not have the necessary programming staff to write the programs. A system such as SODA enables people who are familiar with a problem, and who are not familiar with computers, to write their own programs with relatively little external assistance.
The basic difficulties in preparing a program for any machine can be minimized by the use of either interpretive or translation routines. Almost all computers in use today have routines of this nature available simply for the ease, efficiency, and convenience of the user. Even though these "intermediate" routines generally require more machine time, the aid they give the programmer (particularly a novice) makes them highly desirable from an economic point of view.
Extract: Interpretive and Translation Routines
Interpretive and Translation Routines
Any intermediate automatic coding program for a computer may be broken down into either a translation or an interpretive routine. There are routines which combine the advantages of both translation and interpretive routines to give optimum results in terms of machine efficiency and programming effort. For example, some routines, in order to minimize programming time, require that a pseudo program be run through a translator, an interpreter, and then an optimizing program (in the case of computers with only a drum or delay-line store), before giving a coded program in machine language, suitable for the actual solution of the problem.
An interpretive routine is a program which, when given an order (which is called a pseudo order) in a simplified language, calls in (i.e. transfers control to) an appropriate subsequence, stored elsewhere in the machine, to carry out that step in the calculation. After completion of the subsequence, control returns to the interpretation of the next pseudo instruction. An interpretive routine most useful for the DEUCE machine is called the General Interpretive Program (GIF). GIF, designed for handling almost any matrix manipulation, also enables the programmer to operate on large blocks of data in a prescribed sequence. Another similar but less elaborate interpretive routine for the DEUCE is the Tabular Interpretive Program (TIP). Still another interpretive program is called Alphacode; this is an alpha-numeric system which transforms the computer into a three-address machine which has indexing facilities and works entirely in floating-point arithmetic. These three routines were described by Robinson (1959).
When using a translation routine, the program is first written down in terms of the pseudo orders of the translator's vocabulary, which is similar to that of an interpretive routine. These pseudo orders, however, are then fed into the translator, which produces an output program in terms of standard machine orders. It is this program, in the standard computer language, which effects the problem solution. The interpretation of the pseudo orders thus occurs only once. Since interpretation usually consumes considerable machine time, a translation scheme is of most advantage with often-used programs. It is believed that SODA is the first translation scheme prepared for DEUCE.
Extract: The SODA Machine and the SODA Language
The SODA Machine and the SODA Language
The selection of a pseudo language rests on many requirements, the most important of which are the ease with which the language can be used, and the efficiency of the final machine program. Other points of consideration include the ease with which the translation program itself can be written, and the more pressing requirements of the computation laboratory sponsoring the development.
The first point argues for a language close to that which the human user employs as his own language. Thus we might desire to write algebraic equations, or merely give sentence statements of what is desired. The former of these is presently receiving some attention by Dr. C. Hamblin of the Humanities Department of the University of New South Wales, Sydney, Australia. He has already written an interpretive program using such a language. A translation program for this type of language is extremely involved, and it was felt that something which would be available quickly would be more desirable.
In addition, it was felt that at a university it would be advantageous to have a language which was more like that of a conventional single-address machine. Once such a language is mastered, the step towards programming any machine, including DEUCE, is a relatively minor one. The choice for a language, therefore, embodies the principles employed in programming a more conventional type computer, with the additional facility that the instruction names and the various addresses can be alphabetical in nature, thereby allowing for mnemonic aids. Indeed, SODA incorporates many of the features employed in SOAP (Symbolic Optimum Assembly Program) for the IBM 650 computer and SAP (Share Assembly Program) for the IBM 704 machine. The basic language of these same two schemes was used as a guide throughout the development.
in The Computer Journal 2(2) July 1959 view details
in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details
The organization has operated on a cooperative basis, establishing a standard language of communication and exchanging a large number of programs which form the tools for effectively using the computer.
This standard language of communication is that used in the SHARE Assembly Program, which was developed by United Aircraft Corporation and patterned after the first such program for the 704 which was developed under the writer's direction by the General Electric Company.
This, in turn, was patterned to a considerable extent after the "Comprehensive System" which was pioneered at M. I. T. for use on the Whirlwind computer. At the SHARE meeting held in December 1956, the organization anticipated the forthcoming IBM 709 which was similar in a great many respects to the machine around which the organization was originally built.
In order to have a set of programs available for use upon delivery of the new machine, the organization established a 709 System Committee which was given the task of preparing a “system” for using the machine. The writer was made Chairman of this Committee. Various installations volunteered individuals for service on this committee on a full time basis.
The following people were selected by the Committee Chairman and the SHARE Executive Board for participation on the committee:
Donald L. Shell General Electric Co., Cincinnati, O., Chairman
Elaine M. Boehm IBM, New York
Ira Boldt Douglas Aircraft Corp., Santa Monica
Harvey Bratman Lockheed Aircraft Corp., Los Angeles
Vincent DiGri IBM, New York Irwin
D. Greenwald Rand Corporation, Santa Monica
Maureen E. Kane IBM, Poughkeepsie
Jane E. King General Electric Co., Schenectady
Owen R. Mock North American Aviation, Los Angeles
Stanley Poley Service Bureau Corp., New York
Thomas B. Steel System Development Corp., Santa Monica
Charles J. Swift Convair, San Diego
The Committee's work led to the creation of a system which has been named SCAT (for SHARE Compiler, Assembler, Translater). The initial problem facing the committee was to define what was meant by a system. The scope of the anticipated system varied greatly in the minds of the various members of the committee.
After due consideration, it was decided to specify a complete installation operational system with all the fundamental necessities for effective machine utilization supplied. The committee would use the best experience available and advance the art of machine usage, if possible. However, it would not attempt any features of such novelty as to endanger completion of the system in the time available.
Some of the objectives sought were: simplicity nonstop machine operation card-tape input interchangeability minimum programmer constraints automatic error detection ability to handle the SHARE 704 language, wherever possible. The most important advance made in the system over previous developments is in the area of program debugging. It was felt by the committee that if any true advancement were to be made in this direction, especially in higher language coding situations, it would be necessary to make the machine reply to the programmer in the same language that the programmer originally used to code his problem. The ability to perform this very desirable feat has not been accomplished in every instance. However, a rather long step has been taken in this direction.
This step was made possible through the use of symbolic machine language, patterned closely after the SHARE 704 language, as the common denominator for all communication with the machine.
Instructions written in symbolic form, as macro instructions,1 as algebraic statements, as subroutines or in any other acceptable form, are converted to symbolic machine language by the compiler and retained in an encoded symbolic form as the compiled version of the program. This encoded form of the program is called the SQUOZE deck. Thus, the symbolic machine language is used for compiler output. It is also used for communicating program changes and corrections at execution time and even for debugging output. This use of the symbolic language is, we feel, a major forward step in the techniques of machine utilization.A rather generalized picture of system usage is illustrated in figure 1.
The men pictured there are actually the same person (the programmer) at different points in the system. Initially, at the upper left, he supplies his programs. These go to the compiler, C, in various formats—symbolic instructions, macro instructions, library subroutines, previously compiled SQUOZE decks, and perhaps ultimately FORTRAN statements. The compiler processes this material to produce a single SQUOZE deck which may now be passed along to the modify and load, L, portion of the system. The loading procedure accepts, along with the compiler output, corrections and modifications directly from the programmer in the same symbolic language used to write the original program.
Whereas the compiler and loading procedures operate separately from the object program, the input, I, output, O, and debugging, D, systems are in essence attachments to the object program. These routines absorb the bulk of the burden of translation for the programmers. A set of fundamental routines are provided in a very flexible form—easily adapted to the specific needs of any particular problem. This whole procedure makes possible some very important advantages. First of all, one can make corrections in the same symbolic language in which the program was originally written. Thus, it is a simple matter to keep the program continuously up-to-date. Secondly, the machine has available at execution time sufficient information for the inverse translation—from absolute to symbolic machine language. Thirdly, it is possible to leave many program parameters undefined until execution time, which by former methods had to be defined at compile time. Further details as to methodology and procedure are outlined in the other papers of this set.Three methods were available for the development of this system: The 709 System Committee could assume complete responsibility for the system, including program coding and checkout.
The Committee could completely specify the system and SHARE members would volunteer to produce component programs for the system.
The Committee could specify the system, whereas coding and checkout would be done by the manufacturer. The planning effort expended by the committee amounted to about five man years. This, as can readily be seen, is a very large amount of planning time for such a system. A considerable number of alternative ideas were investigated and developed to some extent before being discussed and either discarded or finally adopted as part of the system.
Since there were a number of rather divergent points of view represented in the committee, it took a great deal of effort to reconcile these approaches into a unified working whole. In addition to the Committee effort, the manufacturer has spent between ten and fifteen man years in order to implement the system. This time has been spent in detailed specifications analysis, programming, coding, checkout, and system integration. The completed system will contain about 46,000 words of instructions and tables. About 13,000 words of this total are needed for the compiler. The remainder is used for the modify and load program, the input and output translation systems, the debugging system and the supervisory control system. About 1,000 words of memory will be needed by the system at execution time.
A considerable body of experience will be required before this effort can be properly evaluated. However, we shall here set forth a tentative evaluation. First of all, an excellent machine utilization system has been devised. It is a system which should be generally acceptable to all of the users of this particular machine. It has been recognized from the beginning that many local installations will wish to make changes and improvements in the system in order to adapt it especially to their needs. However, the fundamental procedures used throughout the system will undoubtedly be retained in every installation. In particular, the basic foundation, the encoded symbolic language, can and will be used as a common language from one installation to another and will serve as an excellent communication device.
It is the writer's feeling that the planning took more effort than was really necessary to produce such a system. This was due in large measure to the enforced inefficiencies of committee action; particularly a committee which is supposed to reconcile many divergent points of view and which does not have a really effective decision procedure. Viewed in this light, it would appear that the very excellent talent which made up the Committee was not used in the most effective possible way. On the other hand, probably all the Committee members will agree that the final result is a better system than any one of the members would have developed completely on his own.
Furthermore, it was obtained with a smaller expenditure of effort by any one installation than would have been necessary to develop any reasonable working system. Viewed in this light, it would appear that although these individuals may not have been operating in the most effective way, still the various installations which contributed these people are getting more for their money than they would have obtained by having them work at home for the same period of time. In addition, future communication of programs among the members of SHARE will be greatly enhanced and expedited through the use of this language which is common to all. These results have made the whole effort extremely worthwhile.
in [ACM] JACM 6(2) April 1959 view details
The organization has operated on a cooperative basis, establishing a standard language of communication and exchanging a large number of programs which form the tools for effectively using the computer.
This standard language of communication is that used in the SHARE Assembly Program, which was developed by United Aircraft Corporation and patterned after the first such program for the 704 which was developed under the writer's direction by the General Electric Company.
This, in turn, was patterned to a considerable extent after the "Comprehensive System" which was pioneered at M. I. T. for use on the Whirlwind computer. At the SHARE meeting held in December 1956, the organization anticipated the forthcoming IBM 709 which was similar in a great many respects to the machine around which the organization was originally built.
In order to have a set of programs available for use upon delivery of the new machine, the organization established a 709 System Committee which was given the task of preparing a “system” for using the machine. The writer was made Chairman of this Committee. Various installations volunteered individuals for service on this committee on a full time basis.
The following people were selected by the Committee Chairman and the SHARE Executive Board for participation on the committee:
Donald L. Shell General Electric Co., Cincinnati, O., Chairman
Elaine M. Boehm IBM, New York
Ira Boldt Douglas Aircraft Corp., Santa Monica
Harvey Bratman Lockheed Aircraft Corp., Los Angeles
Vincent DiGri IBM, New York Irwin
D. Greenwald Rand Corporation, Santa Monica
Maureen E. Kane IBM, Poughkeepsie
Jane E. King General Electric Co., Schenectady
Owen R. Mock North American Aviation, Los Angeles
Stanley Poley Service Bureau Corp., New York
Thomas B. Steel System Development Corp., Santa Monica
Charles J. Swift Convair, San Diego
The Committee's work led to the creation of a system which has been named SCAT (for SHARE Compiler, Assembler, Translater). The initial problem facing the committee was to define what was meant by a system. The scope of the anticipated system varied greatly in the minds of the various members of the committee.
After due consideration, it was decided to specify a complete installation operational system with all the fundamental necessities for effective machine utilization supplied. The committee would use the best experience available and advance the art of machine usage, if possible. However, it would not attempt any features of such novelty as to endanger completion of the system in the time available.
Some of the objectives sought were: simplicity nonstop machine operation card-tape input interchangeability minimum programmer constraints automatic error detection ability to handle the SHARE 704 language, wherever possible. The most important advance made in the system over previous developments is in the area of program debugging. It was felt by the committee that if any true advancement were to be made in this direction, especially in higher language coding situations, it would be necessary to make the machine reply to the programmer in the same language that the programmer originally used to code his problem. The ability to perform this very desirable feat has not been accomplished in every instance. However, a rather long step has been taken in this direction.
This step was made possible through the use of symbolic machine language, patterned closely after the SHARE 704 language, as the common denominator for all communication with the machine.
Instructions written in symbolic form, as macro instructions,1 as algebraic statements, as subroutines or in any other acceptable form, are converted to symbolic machine language by the compiler and retained in an encoded symbolic form as the compiled version of the program. This encoded form of the program is called the SQUOZE deck. Thus, the symbolic machine language is used for compiler output. It is also used for communicating program changes and corrections at execution time and even for debugging output. This use of the symbolic language is, we feel, a major forward step in the techniques of machine utilization.A rather generalized picture of system usage is illustrated in figure 1.
The men pictured there are actually the same person (the programmer) at different points in the system. Initially, at the upper left, he supplies his programs. These go to the compiler, C, in various formats—symbolic instructions, macro instructions, library subroutines, previously compiled SQUOZE decks, and perhaps ultimately FORTRAN statements. The compiler processes this material to produce a single SQUOZE deck which may now be passed along to the modify and load, L, portion of the system. The loading procedure accepts, along with the compiler output, corrections and modifications directly from the programmer in the same symbolic language used to write the original program.
Whereas the compiler and loading procedures operate separately from the object program, the input, I, output, O, and debugging, D, systems are in essence attachments to the object program. These routines absorb the bulk of the burden of translation for the programmers. A set of fundamental routines are provided in a very flexible form—easily adapted to the specific needs of any particular problem. This whole procedure makes possible some very important advantages. First of all, one can make corrections in the same symbolic language in which the program was originally written. Thus, it is a simple matter to keep the program continuously up-to-date. Secondly, the machine has available at execution time sufficient information for the inverse translation—from absolute to symbolic machine language. Thirdly, it is possible to leave many program parameters undefined until execution time, which by former methods had to be defined at compile time. Further details as to methodology and procedure are outlined in the other papers of this set.Three methods were available for the development of this system: The 709 System Committee could assume complete responsibility for the system, including program coding and checkout.
The Committee could completely specify the system and SHARE members would volunteer to produce component programs for the system.
The Committee could specify the system, whereas coding and checkout would be done by the manufacturer. The planning effort expended by the committee amounted to about five man years. This, as can readily be seen, is a very large amount of planning time for such a system. A considerable number of alternative ideas were investigated and developed to some extent before being discussed and either discarded or finally adopted as part of the system.
Since there were a number of rather divergent points of view represented in the committee, it took a great deal of effort to reconcile these approaches into a unified working whole. In addition to the Committee effort, the manufacturer has spent between ten and fifteen man years in order to implement the system. This time has been spent in detailed specifications analysis, programming, coding, checkout, and system integration. The completed system will contain about 46,000 words of instructions and tables. About 13,000 words of this total are needed for the compiler. The remainder is used for the modify and load program, the input and output translation systems, the debugging system and the supervisory control system. About 1,000 words of memory will be needed by the system at execution time.
A considerable body of experience will be required before this effort can be properly evaluated. However, we shall here set forth a tentative evaluation. First of all, an excellent machine utilization system has been devised. It is a system which should be generally acceptable to all of the users of this particular machine. It has been recognized from the beginning that many local installations will wish to make changes and improvements in the system in order to adapt it especially to their needs. However, the fundamental procedures used throughout the system will undoubtedly be retained in every installation. In particular, the basic foundation, the encoded symbolic language, can and will be used as a common language from one installation to another and will serve as an excellent communication device.
It is the writer's feeling that the planning took more effort than was really necessary to produce such a system. This was due in large measure to the enforced inefficiencies of committee action; particularly a committee which is supposed to reconcile many divergent points of view and which does not have a really effective decision procedure. Viewed in this light, it would appear that the very excellent talent which made up the Committee was not used in the most effective possible way. On the other hand, probably all the Committee members will agree that the final result is a better system than any one of the members would have developed completely on his own.
Furthermore, it was obtained with a smaller expenditure of effort by any one installation than would have been necessary to develop any reasonable working system. Viewed in this light, it would appear that although these individuals may not have been operating in the most effective way, still the various installations which contributed these people are getting more for their money than they would have obtained by having them work at home for the same period of time. In addition, future communication of programs among the members of SHARE will be greatly enhanced and expedited through the use of this language which is common to all. These results have made the whole effort extremely worthwhile.
in [ACM] JACM 6(2) April 1959 view details
in [ACM] CACM 4(01) (Jan 1961) view details
Univac LARC is designed for large-scale business data processing as well as scientific computing. This includes any problems requiring large amounts of input/output and extremely fast computing, such as data retrieval, linear programming, language translation, atomic codes, equipment design, largescale customer accounting and billing, etc.
University of California
Lawrence Radiation Laboratory
Located at Livermore, California, system is used for the
solution of differential equations.
[?]
Outstanding features are ultra high computing speeds and the input-output control completely independent of computing. Due to the Univac LARC's unusual design features, it is possible to adapt any source of input/output to the Univac LARC. It combines the advantages of Solid State components, modular construction, overlapping operations, automatic error correction and a very fast and a very large memory system.
[?]
Outstanding features include a two computer system (arithmetic, input-output processor); decimal fixed or floating point with provisions for double
precision for double precision arithmetic; single bit error detection of information in transmission and arithmetic operation; and balanced ratio of high speed auxiliary storage with core storage.
Unique system advantages include a two computer system, which allows versatility and flexibility for handling input-output equipment, and program interrupt on programmer contingency and machine error, which allows greater ease in programming.
in [ACM] CACM 4(01) (Jan 1961) view details
in [ACM] CACM 6(03) (Mar 1963) view details
in [ACM] CACM 6(03) (Mar 1963) view details
[321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.]
in [ACM] CACM 6(03) (Mar 1963) view details
in [ACM] CACM 15(06) (June 1972) view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
in C.J. Bashe, L.R. Johnson, J.H. Palmer, and E.W. Pugh "IBM's Early Computers" MIT Press, 1986 (Vol. 3 in the History of Computing series) view details