SCAT(ID:3197/sca012)

SHARE Compiler, Assembler, Translater 

for SHARE Compiler-Assembler-Translator (but also for the then-fashionable jazz wordless voice improvisation, hence improvised etc)

Discussed by Bemeber Nov 1957
unified system for the SHARE group on the IBM 709/7090 Nov 1958

Places Hardware:
Related languages
MICA => SCAT   Target language for
SAP II => SCAT   Subsumed
SQUOZE => SCAT   Subsumed
SCAT => MPL   Influence
References:
  • Bemer, R. W. "The Status of Automatic Programming for Scientific Problems" view details Abstract: A catalogue of automatic coding systems that are either operational or in the process of development together with brief descriptions of some of the more important ones Extract: Summary
    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
  • Boehm, E. M. and T. B. Steel "The Share 709 System: Machine Implementation of Symbolic Programming" 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
  • Greenwald, Irwin D. and Kane, Maureen "The SHARE 709 system: Programming and modification in the SHARE 709 system" view details Extract: Rationale of SCAT
    As is often the cases the design of the SCAT Symbolic programming system was based primarily on the prior experience of its designers. In reviewing the difficulties that programmers had been (and still are) having using existing techniques, the conclusion that the 709 System Committee reached was that almost all of the troubles could be traced to failings in language: with the exception of absolute machine language coding (the drawbacks of which need not be labored here), it was discovered that in practice, the language in which a code is written is not the same as that in which changes and corrections are made or in which debugging information is received. The former are usually done by making "patches" in absolute terms and the latter is almost always absolute machine language.
    Upon reflection, it becomes apparent that a solution to the language problem has two major requirements:
    1. That, in order for the programmer to "talk" to the machine in a purely symbolic language at all times, every "pass" at the machine must, in essence, be an assembly pass
    2. That, in order for the machine to "talk" to the programmer in the same symbolic language (or any symbolic language) there must be available to the machine at execution time information concerning the format of the program being executed.
    [...]
    This, then, is the essence of the SCAT system: at all stages the programmer is using and receiving the same language in a completely consistent format.
    The instruction format is similar to that of any symbolic assembler: location symbol (as required in the context of the program); operation; operand.
    The kinds of instructions acceptable to SCAT are of
    four general classes:
    1. Normal machine instructions
    2. Pseudo instructions
    3. Macro instructions
    4. Modification instructions.
    Pseudo instructions are, for the most part, instructions to SCAT itself: for manipulating the location counter, equating different symbols, differentiating between duplicate symbols, reserving blocks of storage, etc.
    Macro instructions may be defined as "instructions which generate words or sequences of words" These words may be actual machine instructions, parameters for calling sequences, etc. SCAT has an extensive set of built-in macros to facilitate debugging as well as provision for incorporating programmer written macros.
    The SCAT modification instructions are closely akin to the insertion-deletion control cards of regional assembly programs. Their most important difference is that, with minor exceptions, the when, wherej and how are expressed in the usual SCAT symbolic language.
    To summarize: SCAT overcomes the major weakness of other techniques, (namely, language), by enabling the programmer to deal entirely in one symbolic language and consistent format at all times.
          in Preprints of papers presented at the 13th national meeting of the Association for Computing Machinery, June 11-13, 1958, Urbana, Illinois view details
  • Shell, Donald L. "The Share 709 System: A Cooperative Effort" 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
  • Boehm, E. M. and T. B. Steel "The Share 709 System: Machine Implementation of Symbolic Programming" view details Abstract: As emphasized in the preceding paper, a fundamental requirement for effective utilization of high speed computing devices such as the 709 is a man-machine communication link that is at once rapid and unambiguous. Use of symbolic languages with conventional conversion techniques has resulted in reasonable initial specification of computational problems, but excess input handling has made such procedures uneconomical for the tedious corrections incumbent on the best of programmers. Also, checkout is frequently awkward, due to the inability of current systems to permit dynamic requests and responses in a language familiar to the writer. It is an objective of the system design to provide a mechanism for preservation of symbolic language communication between coder and calculator during the entire process of preparing, verifying and executing a program. Decisive in the accomplishment of this aim is recognition of a distinction between the information content of a language and the methods of encoding that language for presentation. Standard routines for translation of symbolic to absolute machine language uniformly result in information loss. This is not the case in the 709 system; only the syntax, not the semantics, are changed. Apart from mnemonic aids, the principal feature of symbolic coding is that referents and their relata maintain the same association when intervening elements are altered in number. A price is paid for this freedom as symbolic languages are uninterpretable by machine circuits without aid. A special program is required—an assembler. The principal disagreeable characteristic of an assembly program is the amount of time it occupies in execution. By attempting to minimize the frequency of reassembly, the programmer is forced to employ two languages in parallel. Logic shows that the only escape from this dilemma is to place some burden of the assembly on that program which loads codes into the machine storage for immediate execution. At once a question arises concerning the propriety of performing even a partial assembly at each machine pass.It is apparent to anyone familiar with historical assembly programs that the major time involved comes not from the internal processing but from the considerable read-in time associated with the usual methods of representing symbolic information. As this information is originally written by a human coder and then reproduced into, say, punched cards, again by a human operator, it is evidently impractical to start the process with binary encoding or some other form of compact expression. It is, however, possible to reduce this original writing to some new form of condensed encoding by computer processing and to use this form exclusively in subsequent operations. With care this can be done and not destroy the desirable features of the original representation.The basic concept in this system is a second encoding schema for the information concerning a program originally described in the symbolic language. This encoding, called the “SQUOZE encoding,” is at variance with the programmers' encoding in several respects. First, it is fundamentally binary, employing only two basic marks, while the programmer enjoys the use of 50. Secondly, the organization of information is quite different in the SQUOZE encoding. All information concerning a particular instruction occurs together in the original expression. This is not the pattern in the SQUOZE encoding. For example, the location symbols associated with the various instructions and storage cells are collected in a single, separate list. This proves to be most desirable for computational purposes when consideration is given to the special role played by such symbols. Finally, and with perhaps the most significance to the casual observer, the SQUOZE encoding is far more conservative of bits than the pseudo-English used by the programmer. It is from this phenomenon that the scheme derives its name, “SQUOZE” being a bastard past participle of the verb “to squeeze.” This condensation, which is on the order of ten to one, does not alter the functions of the system, but it does provide a considerable decrease in the time involved in processing program input, a major criterion for acceptability to those concerned with machine rentals. The critical difference from other systems inherent in the SQUOZE encoding is the retention and reorganization of information concerning symbols. It is this element that makes possible the more desirable modification and checkout procedures. Condensation does nothing more than make this sophistication cheaper and therefore more palatable. While clearly less redundant than the usual mode of expression, the SQUOZE encoding is not based on a minimum redundancy code. There are two reasons for this. In the first place, the construction of a true minimum redundancy code is not possible without precise knowledge of the probabilities of the various elements involved. Such data would be hard to come by for a programming language on an untried machine. Also, in the general case, a minimum redundancy code requires bit by bit examination for decoding. In the 709 this would require more internal processing time than would be saved on input read-in. It is evident that a compromise is necessary.A single example will suffice to illustrate the pattern of exchange between decoding time and input time. When the various macro instructions are adjoined to the actual 709 instructions, the number of operation codes which the loading program must recognize approaches 250. Allowing for later expansion, a principle that has been followed throughout the system, nine bits would be required for an elementary table description of the operation code list. Had this mechanism been adopted, only a single table lookup function would be required in the decoding program for the determination of the operation codes.If the exact frequency ranking of the operation codes were known, assuming a logarithmic distribution as a best example, approximately five and one-half bits would be the mean needed for representation of the operation codes in a minimum redundancy scheme. In this case no table lookup would be performed, but an average of five and one-half bit examinations would be essential. Evaluation of the computing and input times involved shows that the simple scheme enjoys an advantage by a factor approaching two. Additionally, in a machine with a finite high speed storage, attention must be given to the amount of program and table space needed for each procedure. Invariably the logic of present day machines favors the simpler table lookup approach.Certain improvements are possible, however. Although the precise frequencies are unknown, some a priori data are available regarding the relative probabilities for the occurrence of the various operation codes. For example, it is clear that a STORE instruction will occur more often than a REWIND TAPE instruction. By dividing the operation codes into two groups, a gain can be made. This is the procedure actually employed in the SQUOZE encoding. The operation codes representing those 32 instructions expected to be the most frequent are assigned a five bit code, while the remainder are encoded in nine. It is, of course, necessary to adjoin an additional bit to each code in order to provide an indicator for the category into which the code falls. Thus, frequent instructions require six bits for specification of their operation codes while the others demand ten. A mean of seven and one-half bits is estimated for the length of an operation code in the SQUOZE encoding.The decoding procedure for a SQUOZE operation code requires a single bit test and a table lookup. There is a slight advantage in this case over the straight table lookup. Eighteen microseconds per instruction are gained in input time at the expense of sixteen and one-half microseconds of decoding time. Clearly any more elaborate encoding would be less efficient.Talk of fractional microsecond savings may seem like woolgathering, but this time is saved on each occasion of loading an instruction into the machine. With some reasonable assumptions on the ratio of loading time to processing time, this one feature would account for some ten minutes of computer time each year. However, there are perhaps 100 such effects in the entire SQUOZE encoding and a similar number of machines involved. When translated through the rental formula, this represents some 50,000 dollars annually. For ease of discourse, the SQUOZE encoding schema will be discussed in terms of its representation on punched cards, the “SQUOZE deck.” The deck is divided logically into four parts: preface, introduction, dictionary, and text. The preface contains sundry information concerning the layout of the remainder of the deck and is utilized in allocating high speed storage effectively.The introduction contains information about those elements of the symbolic program not bearing directly on the resulting machine language code; such things as comments and data concerning which words were generated by the assembler initially as a result of library call cards and macro instructions. The dictionary is essentially a list of the location symbols encountered in the program, together with a description of the format of the cells these symbols name. The text, finally, contains the specific description of the instructions to be developed into 709 binary words and loaded into the high speed storage of the machine.Consider the functions the deck must perform. The loading process is, in fact, an assembly process. Although there is an option for the assembly program to produce an absolute binary program deck, the system is designed so that the normal modus operandi will be the production of a SQUOZE deck from original symbolic cards, this deck being used in all subsequent operations. A SQUOZE deck is not in a form that can be inserted directly into the machine for program execution. Basically, the squoze deck is the result of the first pass of a traditional assembly. For the derivation of an executable code it is necessary to perform the second pass and this is done by the loader just before execution time. As a mechanism is provided to permit symbolic modifications to the SQUOZE deck, both passes of assembly must be made on the disturbed material. In view of the possibility of altering the code through the medium of the loader, it is essential that the loader be able to produce, on demand, a new deck and a listing of the deck in symbolic language. In addition to all this, the loader must, surprisingly, be capable of loading the assembled code into storage and executing a control transfer to the object program.Making modifications to a program in terms of its symbolic referents calls for a knowledge of the number of machine words occurring between those words having symbolic names. This information is contained in the dictionary and is employed in updating the absolute assignments to location symbols just prior to actual decoding of the text.The dictionary is the primary source of information concerning the values to be assigned to symbols in the SQUOZE deck. It corresponds in many respects to the symbol tables found in assembly programs, having two parts, a symbol list and a reference list with a one-one mapping between the two. Two types of entries occur in the dictionary. First, every symbol which is to be defined during the loading process must appear in the list. Associated with each symbol is its relative placement in the original code. Secondly, to permit the loader to manage the stepping of the machine location counter during the assignment of the absolute locations, it is imperative that information be available on the details of those pseudoinstructions which have an effect on the sequence of location values. These include such things as origin specifications and block reservations. In view of the potential complexity of the requisite data, it has been found necessary to have a second table, called the “footnotes,” which contain this detail information in encoded form. There is an interesting feature related to the encoding of symbols for inclusion in the dictionary. In the usual mode of expression, symbols may be constructed from a set of 50 characters. If encoding were character by character, six bits would be required for the representation of each such character. As a symbol may contain as many as six characters, a total of 36 bits would be required for the representation of each symbol. This might seem convenient, as the length of a 709 word is exactly 36 bits, but a moment's consideration shows that it is unfortunate as it would be desirable to have a bit or two available in the same word as the symbol representation, giving a clue to the nature of the symbol. These flagging bits can be obtained. Let each character possible represent a digit in a number system having a base of fifty. Now six character symbols may be read as natural numbers in a base fifty system. If these numbers are converted to the usual base two system, only 34 bits are required for the maximum number and a gain of two flag bits has been made. This has the incidental feature of decreasing the requisite number of bits for representing the entire code, but conversion time would outweigh the saving by a significant margin were it not for the peculiar length of the 709 word. Here is a clear illustration of the critical effect the precise specifications of the machine concerned hold over the details of an encoding schema.Relative to the 709 internal location sequence, the dictionary is arranged in the numerical order of the symbols. It is obvious that this is not the order in which the symbols would occur in the original code. It is thus necessary to carry information which permits a determination of the order of the original deck. This, together with the word separation of successive symbols and the format data, comprises the basic dictionary. From it, recalling that origin specifications are included, it is possible to make an absolute determination of the value of each symbol, prior to examination of the text. Further, adjustment of these values in the dictionary is possible whenever it is necessary to incorporate insertions, deletions, or substitutions in the original text. The text is a linearly ordered string of bits representing the rest of the information required in the loading and listing processes. It consists of an encoded version of those parts of each symbolic instruction relevant to the loader's function. The singular exception is the location symbol which may be associated with an instruction. Information concerning these symbols has already been encountered in the dictionary, and, following a principle of nonrepetition, nothing covered in the dictionary occurs in the text. Although the SQUOZE encoding is emphatically not a minimum redundancy coding, it should be evident that the usual redundancy available for checking purposes is absent. Loss of a single bit will turn the entire loading operation into chaos. As a validity check, every 256th instruction possesses a peculiar, nonrecurring bit pattern which is recognized by the loader as a clue that decoding has been proceeding according to plan. Failure to meet this check is considered a catastrophic failure and loading is terminated at once. The following remarks concern the general flow of the loading procedure, although it is not possible in the space available to do justice to the complexities involved. The loading program will first accept any modification pseudoinstructions, such as CHANGE and ALTER, together with any symbolic instruction cards to be inserted, and convert them to a useful form for processing. It will then read the preface of the SQUOZE program to be loaded, from which it can allocate storage. It should be observed that the only data concerning storage allocation which may occur in this preface is information about the original state of the deck. All other necessary data must be computed from the modification decks which have already been read into the storage. Storage for these elements must have been allocated without reference to the SQUOZE deck preface and the structure of the deck to be modified. Proper allocation of storage to the various deck components and computed tables is, without question, the most difficult task faced by the system coders.Following this storage allocation exercise, the introduction is read and all ALTER modification pseudoinstructions have their card numbers reduced to a count of the type appearing in the dictionary. Indeed, this reduction is the sole function of the introduction. Were there no difference between instruction and card counts in the original deck, there would be no requirement for the data in the introduction.After the introduction is processed, the dictionary is read into storage and CHANGE cards are processed, giving the symbols encountered on them the same type of count assignment. It is the dictonary's separation count which makes this possible. Given the count for each modification, it is then possible to find the place of each such item in the dictionary and to update the count accordingly, adding new entries where required. Then the dictionary is processed to replace the count with the absolute value of each symbol.It is appropriate to note at this point that the dictionary processing is different from usual techniques. The dictionary is subjected to an iterative reprocessing until either all symbols have been defined or no further progress is possible. This implies, contrary to the situation in typical assembly programs, that definitions need not be made in a particular order in the original code. Thus, in the modification procedure, it is unnecessary to take special precautions in the order of symbol redefinition. Finally, the text will be read into storage and decoded, the resultant being placed in core storage until such time as the assigned locations overflow areas that are occupied by essential information. Should this occur, the entire code will be transcribed onto magnetic tape and the decoding continue. At the conclusion of the decoding, the code will be restored to the core and the loader will execute a control transfer to the point specified by the object code. In the event that a listing or a new deck is desired, the machine code will be written on magnetic tape and the printing and punching operations established before loading the code back into core. The emphasis of the discussion to this point has been on the loader and the modification techniques. This is as it should be for the remainder of the symbolic communication link is more or less traditional. The original translation of the symbolic information to SQUOZE deck form is in the nature of a conventional assembly, or, at least, the first pass of such a routine. Instead of absolute binary output, this assembler produces a SQUOZE deck. Hereafter the procedure is as outlined. Two other features are worth mention. For purposes of input and output, the dictionary may be preserved and used to permit the definition of input and output areas in terms of the original code symbols. Also, perhaps critical to the overall value of the system, the dictionary and its symbolic data are provided as input to the checkout routines, thus permitting a reproduction of the original symbolic language format for debugging. In summary it should be observed that the principles evident in the SQUOZE encoding technique permit the retention of information throughout the whole involvement of the machine with a computational problem, thus yielding a practical answer to the need for a man-machine communication line that is easily understandable to the human element. Careful construction has made this less expensive than one might expect from cursory examination of the usual symbolic language techniques. It remains to be seen how well all this works out in practice. Without direct experience, the constructors of the system can only proceed in the hope that their intuition has not been misleading and that, indeed, the approach taken by the 709 system is a sound departure in modern computing technology.
          in [ACM] JACM 6(2) April 1959 view details
  • Carr, John W III; "Computer Programming" volume 2, chapter 2, pp115-121 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
  • Shell, Donald L. "The Share 709 System: A Cooperative Effort" view details Abstract: SHARE was created in August 1955. From the beginning, its aim has been to reduce redundant effort among various users of the IBM 704, insofar as the preparation of commonly used routines is concerned.
    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
  • Hoffman, Joyce and Opler, Ascher "Use of MOBL in preparing retrieval programs" view details Extract: Description
    Description of the MOBL-MICA System

    MICA is an hierarchically organized compiler with a dominant system macro at the highest level. One level below the system macro lies the users program written in  the form of one macro. This may contain machine coding library macros and user's macros. By sublevel nesting of  macros, the user can eliminate redundant effort in the construction of new macros.

    If an address field is not defined in the macro which references it, the next higher level macro is examined and then the next, until the symbol is found. If the symbol is defined in more than one skeleton, MICA will alter the symbol (and all references to it) at each occurence to provide uniquely defined symbols. Operation codes (macros or machine coding), as well as location symbols, may appear as parameters; This allows MICA to compile alternate operations, depending on the decisions made at compiling time usually based on pr definitions.

    Fields may be defined without concern for word boundaries and may be either alphanumeric or binary. Once specified, the user may reference these fields with little concern for their description. For example, when using the MOVE macro, the user need only provide the symbolic locations (indexable) of the "from" arid "to" fields. The compiler will be responsible for such things as shifting, changing modes, masking and making the necessary  adjustments when the fields are unequal in length.

    The following types of macros are provided by the MOBL library:
    - Input-Output
    - Data Definitions
    - Field Test and Control
    - Arithmetic
    - Logic Control
    - Field Editing
    - Indexing
    - Debugging Extract: Technique
    Technique of Writing With MOBL
    To write a retrieval program in MOBL, one prepares the data description which defines files, records and fields. One then proceeds to write the procedure using, for the most part, the macros provided by the MOBL language which address the files, records and fields previously defined. These describe the required manipulations. A significant feature of an hierarchical macro system like MICA is that it allows simple extensions of the language by creating new procedures (user macros ) to embody repeated actions.

          in [ACM] CACM 4(09) (September 1961) view details
  • Bemer, R "ISO TC97/SC5/WGA(1) Survey of Programming Languages and Processors" December 1962 view details
          in [ACM] CACM 6(03) (Mar 1963) view details
  • James J. Peterka, "A Method for Obtaining Specific Values of Compiling-Parameter Functions", view details
          in [ACM] CACM 6(03) (Mar 1963) view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 212 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [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
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 522 view details Abstract: PREFACE  AND  INTRODUCTION
    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] CACM 6(03) (Mar 1963) view details