UASAP(ID:2933/uas001)SHARE Macro-assemblerSHARE Macro-assembler Listed as in common use by Orchard-Hays in 1956 References: We will speak in terms of the IBM 704 but the ideas are equally applicable to any large computer. The first assembly program for the 704 was IBM's NYAP1 assembler (New York Assembly Program 1). It has been almost universally supplanted by United Aircraft's symbolic assembly program (UA- SAP), which is only slightly different but, according to some, an improvement. At any rate, both of these programs accept symbolic instructions, one per IEM card, written in alphadecimal with standard Hollerith punching. Great flexibility is allowed in assigning symbolic addresses or other identification, in making locations relative to arbitrary symbols, etc. In short, the inputs are such as to make the coder's job as easy as possible and to get the machine to do a maximum of organization within the definition of an assembler. (UA-SAP even has some features more apropos of a compiler, as remarked in the main text). We have only one complaint (discussed later) with regard to the rules for programming code which these assemblers accept as input. Now while quickly admitting great admiration for the coding skill which created these programs, we nevertheless submit the proposition that they are not very handy tools. The trouble is with the output; briefly, they are overly ambitious and seem to have been designed as an end in themselves rather than as a means. When one would like a little ball-peen hammer to smooth out a rough spot, they offer a rolling mill. Or, instead of a proof sheet, they hand one a bound book (well, almost). Yet, one cannot operate without an assembler. The symbolic code for the L.P. programs takes about a tray and a half of a standard filing cabinet or about 4800 cards. Imagine trying to code and record these in absolute binary! The assembler processes these and produces about 225 binary cards -- 22 absolute, machine language words-per card. (Some symbolic instructions produce more than one absolute word and not all binary cards are full.) At the same time, the 4800-odd instructions are printed out in both symbolic and absolute octal. This is the primary document for the program. This printing is a very expensive operation and, if wrong, must be done again, at least in part. Remember that we have not yet begun de-bugging. If the printing is right, it is still expensive to reproduce. If now a mistake is found in a section of code, it must be corrected and all the original symbolic cards for this section assembled again. The binary cards produced the first time are Junked and the new listing must be fitted in to replace the original incorrect part. (One simple improvement in present assemblers would be to start a new page on each "origin" card, i.e. at the start of each new section.) Not only is there no salvage from the first assembly, but the correction of the primary records is awkward. Now the time-consuming part of an assembly is not the assignment of actual locations and punching of binary cards. This is fairly cheap. It is the reading and printing of original symbolic code that is expensive. But what if a symbolic card is wrong? While this may invalidate the entire output, it usually does not affect the other symbolic cards. Probably 97 to 98 per cent of these are right the first time. When the assembler reads these cards it converts the information to a binary-coded alphadecimal form which can be packed into much less space. But, at this point, no information has been lost, it has only been written more efficiently. If the code being assembled wore saved in this status, in a form which could be hand corrected, re-assembly would be cheap, except for printing. But again, what of printing? Do we really have any use for all those reams of paper in de- bugging? The answer is no, in fact we would be better off with much less information given in condensed form. The detailed information is available on the binary cards if it is really required. When the code is checked out, then is the time for a full and complete -- and correct-listing of the program. Aside from ambiguities and mispunched hash detected by the assembler, the really useful information in de-bugging is the absolute location assigned each symbol. However, one feature of present assemblers makes every word of code a potential symbolic location. This is the feature of addresses relative to a symbol, e.g. SYMBL+6 means the sixth address after the address assigned to SYMBL. Similarly ABCDE-2 means the second address before the one assigned to ABCDE. This seems like a marvelous convenience from a coder's viewpoint. We found, however, in de-bugging the LP codes, that the great majority of errors occurred from miscounting the addresses from the symbol or forgetting to correct after insertions or deletions near the symbol. The references are often far removed. Of course, the obvious way to avoid this is to use a distinct symbol for each referenced location. However, this increases the amount of information required by the assembler and it is often convenient for symbols in a sub-section of code to be related. For example, one might use SYMB, SYMB1, SYMB2, etc. for referenced locations near together. This in fact is done throughout the coding of UA-SAP itself! (Amazingly, it is written in terms of itself.) Hence, why have relative locations at all? A better device would be second-order symbols, i.e. sub- symbols which are reheaded automatically whenever a new major symbol appears, e.g. (Location) (Reference) SYMB - = SYMB 1 = SYMB1 6 = SYMB6 ABCD - = ABCD 3 = ABCD3 where the location sub-symbols are written in a distinct column set aside for them. With these remarks, we can now state a set of proposed specifications for an assembly program. We will assume familiarity with UA-SAP. We would accept the standard "SHARE" 3-letter symbolic operation code in its entirety including the additional "prefix operations" MZE, MON, etc. We would modify the UA-SAP definition of a symbol to read as follows: SYMBOL: Any combination of not more than 5 Hollerith characters except the comma, the first of which is nonnumeric. SUB-SYMBOL: A symbol prefixed with a digit 1, ..., 9. FIXED SYMBOL: A symbol prefixed with a minus sign. We would reserve column 1 for a symbol prefix but otherwise adopt the UA-SAP symbolic card form. We would do away entirely with arithmetic expressions in terms of symbols and integers, including relative addresses. (These are properly functions of a compiler.) We would require all tags to be numeric and disallow all- numeric location fields to act as origin cards. We would accept the UA-SAP pseudo-instructions ORG, EQU, SYN, DEC, OCT, BCD, BSS, BES and END as defined. The EQU instruction would require a decimal address and the SYN operation a previously defined symbolic address. We would omit entirely REP, LIB, HED, DEF and REM and impose some restrictions on remarks. We would also add the pseudo-instructions GRP, OPE and CLR which will be explained subsequently. From this point, we diverge from UA-SAP, for we would introduce "circulating information" in the form of BCD (binary coded decimal) punched cards. All symbolic cards (with certain exceptions) would be punched in this form before punching the absolute binary deck. These BCD cards would be readable by the assembler and could be intermixed with symbolic cards for re-assembly. The BCD cards used as input would not be re-punched. These BCD cards would be punched in groups, each group being associated with a mayor symbol. The first card of a group would be distinctive and be associated only with the mayor symbol. We shall hereafter refer to these as S-cards. These are the only BCD cards on which comments would be reproduced and only the comments on symbolic cards with a mayor symbol in the location field would eventually be printed. The original alphadecimal symbol would be punched in standard Hollerith characters in columns 73 - 77 (no prefix) on an S-card which would act as a gang master for the rest of the group. (If an automatic sequencing device is available on the card punch, this could be used on columns 78 - 80). The BCD cards could then be interpreted for easy identification. The other cards of the group will be referred to as G-cards. These would contain up to 12 instructions each. Instructions which contain neither a location nor a decrement would require one row of a card, otherwise two rows. Symbolic cards with DEC, OCT or BCD operations and a mayor symbol in the location, would be reproduced on one S -card with no comments. If it should be desired to use several major symbols in sequence, as for a region of universal constants, then it would be desirable to punch them all in G-cards. This one could do by heading the symbolic cards with a card containing the pseudo-instruction GRP. All following symbolic cards would then be reproduced in G-cards (with no comments) until either a symbolic card with the instruction OPE or an S-card was read. Columns 73 - 77 of these cards would retain whatever symbol was previously being ganged. Symbolic cards with the pseudo-instructions ORG, EQU, SYN, GRP, OPE, CLR, or END would not be reproduced in BCD cards since this information might well vary from assembly to re- assembly. The pseudo-instruction GLR would accomplish the following: All unfixed symbols are sorted, stored on tape and cleared out of the symbol table. This would eliminate the difficulty of duplicate symbols in different sections of the program being assembled and be much more to the point than the UA-SAP instruction HED. Universal symbols (which ought to be universally honored) could be fixed. When the END card is read, all symbols remaining in the table would be sorted. Since the fixed symbols would be negative, they would occur first. The remaining unfixed symbols would be written on tape which would then be rewound and the records of unfixed symbols, i.e. sets divided by CLR cards, would be used in order of occurrence together with the fixed symbols. The BCD cards would be punched during reading of the symbolic cards. On the first assembly, this would require considerable punching but, on reassembly, only corrected symbolic cards would be punched and reading time should be cut by a factor of six or eight. There would be two kinds of printing, each subject to a switch. Before each set of symbols i8 sorted, they could be printed out in order of occurrence together with the absolute locations assigned. This would be the only printing normally done on a first assembly. The other option would be the complete listing of the assembled program in a form entirely similar to the UA-SAP format. Thus could be deterred until the program was de-bugged. At that time only BCD cards would have to be read (none punched) and printing could be done on vellum for reproduction. The assembled program would, of course, be punched in absolute binary cards in any case. The detailed formats of the S- and G-cards have been worked out and are entirely practicable. They are not discussed here as being of interest only in the event such a program is developed. This would, of course, be a two-pass assembler. The program for the first pass has been outlined and a considerable part of it actually coded. The second pass (actual assembly) would not be much different from the second pass of UA-SAP. On the first pass, there is no question of being able to handle 12 instructions per G-card at 250 cards per minute since there is no conversion, packing, editing, etc. to be done. This would have all been accomplished on the first assembly. in Computers & Automation 21(6B), 30 Aug 1972 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 Computers & Automation 21(6B), 30 Aug 1972 view details |