ADES(ID:37/ade002)

Automatic Digital Encoding System  


for Automatic Digital Encoding System

E. K. Blum, US Naval Ordnance Laboratory, 1955

First declarative language, also designed to be machine independent

Uses left Polish notation and Kleene functions.




People: Hardware:
Related languages
Kleene => ADES   Based on
White Oak Curry => ADES   Influence
ADES => ADES II   Evolution of

References:
  • Blum, E. K. "An Automatic Digital Encoding System" view details
          in Proceedings of the 1955 10th ACM national meeting view details
  • "An ADES Encoder for the 650 Calculator" U.S. Naval Ordnance Laboratory, Department of the Navy, December 1956. view details
          in Proceedings of the 1955 10th ACM national meeting view details
  • Blum, E. K. "The ADES System" Aeroballistic Research Report 326, Naval Ordnance Laboratory, 8 Feb. 1956 view details
          in Proceedings of the 1955 10th ACM national meeting view details
  • Blum, E. K., "Automatic digital encoding system, II" view details
          in [Office of Naval Research] Symposium on Advanced Programming Methods for Digital Computers (Washington, DC, June 26-29). Dept. of the Navy, Washington, D.C., 1956. view details
  • Gorn, Saul "Standardized Programming Methods and Universal Coding" view details Extract: Introduction
    Introduction
    It is possible so to standardize programming and coding for general purpose, automatic, high-speed, digital computing machines that most of the process becomes mechanical and, to a great degree, independent of the machine. To the extent that the programming and coding process is mechanical a machine may be made to carry it out, for the procedure is just another data processing one.
    If the machine has a common storage for its instructions along with any other data, it can even carry out each instruction immediately after having coded it. This mode of operation in automatic coding is known as 'interpretive'. There have been a number of interpretive automatic coding procedures on various machines, notably MIT's Summer Session and Comprehensive systems for Whirlwind, Michigan's Magic System for MIDAC, and IBM's Speedcode; in addition there have been some interpretive systems beginning essentially with mathematical formulae as the pseudocode, such as MIT's Algebraic Coding, one for the SEAC, and others.
    We will be interested, however, in considering the coding of a routine as a separate problem, whose result is the final code. Automatic coding which imitates such a process is, in the main, non-interpretive. Notable examples are the A-2 and B-O compiler systems, and the G-P (general purpose) system, all for UNIVAC, and IBM's FORTRAN, of the algebraic coding type.
    Although, unlike interpretive systems, compilers do not absolutely require their machines to possess common storage of instructions and the data they process, they are considerably simpler when their machines do have this property. Much more necessary for the purpose is that the machines possess a reasonable amount of internal erasable storage, and the ability to exercise discrimination among alternatives by simple comparison instructions. I t will be assumed that the machines under discussion, whether we talk about standardized or about automatic coding, possess these three properties, namely, common storage, erasable storage, and discrimination. Such machines are said to possess "loop control".
    We will be interested in that part of the coding process which all machines having loop control and a sufficiently large storage can carry out in essentially the same manner; it is this part of coding that is universal and capable of standardization by a universal pseudo-code.
    The choice of such a pseudo-code is, of course, a matter of convention, and is to that extent arbitrary, provided it is
    (1) a language rich enough to permit the description of anything these machines can do, and
    (2) a language whose basic vocabulary is not too microscopically detailed.
    The first requirement is needed for universality of application; the second is necessary if we want to be sure that the job of hand coding with the pseudo-code is considerably less detailed than the job of hand coding directly in machine code. Automatic coding is pointless practically if this second condition is not fulfilled.
    In connection with the first condition we should remark on what the class of machines can produce; in connection with the second we should give some analysis of the coding process. In either case we should say a few things about the logical concept of computability and the syntax of machine codes.
          in [ACM] JACM 4(3) July 1957 view details
  • [Bemer, RW] [State of ACM automatic coding library August 1958] view details
          in [ACM] JACM 4(3) July 1957 view details
  • [Bemer, RW] [State of ACM automatic coding library] view details
          in [ACM] CACM 1(08) (Aug 1958) view details
  • [Bemer, RW] [State of ACM automatic coding library] view details Extract: Raison d'etre
    On 6 August 1957 a questionnaire was mailed to various persons known to be connected with the production of coding systems. It read, in part:
    "It is my hope to update this survey and make it available in the 'Communications of the A.C.M.,' where it may serve as a reference list for requests to the A.C.M. library. It will be appreciated if you could arrange to send me three (3) copies of all material to date on the above referenced system. I would like one of these for my own purposes and will forward two to the A.C.M. library for historical reference. Such material may include various manuals, flow charts, training courses and published talks on the system. I should like to request, in addition, that new material be forwarded automatically for those systems in process and still used. If possible, please specify the person responsible for the conception of the system and those programmers who actually produced it. Also appreciated would be a short summary of the usage the system has received and at what installations."
    Information on more than half of the known systems has been collected and is now deposited at the A.C.M. offices at 2 E. 63rd Street, New York 21, N. Y. The accompanying chart (page 8) is an interim report on the specific systems on hand. When essentially complete, a new chart will be published. This department has taken on the responsibility of further collection and maintenance of this material. It wilt be much appreciated if those responsible for the missing systems will help to complete this library by sending in the needed material. Please make it a continuing effort so it will be as up-to-date as possible; forward revisions and manuals for new systems without reminder and urging. Several machines and coding systems do not appear on the chart for lack of information. Do not feel slighted. Send in your material and appear in the next chart.

          in [ACM] CACM 1(04) April 1958 view details
  • Blum, E. K., and S. Stern, An ADES Encoder for the IBM 650 Computer, NAVORD Report 4412, U.S. Naval Ordnance Laboratory, December 19, I958 view details
          in [ACM] CACM 1(04) April 1958 view details
  • [Bemer, RW] [State of ACM automatic coding library May 1959] view details Extract: Obiter Dicta
    Bob Bemer states that this table (which appeared sporadically in CACM) was partly used as a space filler. The last version was enshrined in Sammet (1969) and the attribution there is normally misquoted.
          in [ACM] CACM 2(05) May 1959 view details
  • Blum, E. K. review in ACM of Goodman (1961) view details Abstract:
    The paper by J. Iliffe on "The Use of the GENIE System in Numerical Calculation" describes a mathematical programming language for the Rice University computer. The GENIE language bears a strong resemblance both to ALGOL and to the ADES language developed several years ago by the reviewer. GENIE has some of the best features of both languages. It also embodies some ideas not possessed by either of these systems or any other system of this kind. Perhaps the most important departure from .\LGOL is the extension of the domain of possible values assigned to the symbols in the language. Whereas in ALGOL values are limited to real, integer and Boolean, GENIE permits as additional domains of values other symbol sets and instruction sets. Thus, the value of the expression P(ll, a) could be a set of single-address machine instructions for performing the addition ~ + v. The claim is also made that analytical processes can be performed as well as numerical processes. Another feature, although not original in GENIE, is worth mentioning. This is the use of a table of codewords for assignment of storage to arrays. The use of codewords rather than the ALGOL array declarations (or the dimension statements in FORTRAN) permits a much more flexible and efficient handling of storage assignments for arrays both in the source language and in the compiler.
    Extract: Review
    The paper by R. F. Clippinger titled "FACT -- A Business- Compiler: Description and Comparison with COBOL and Commercial Translator," must be singled out as an example c(-; the kind of paper which a compendium such as this should strive to present. Clippinger's excellent paper does much more than describe the FACT system for the Honeywell 800. Avoiding the dreary style of the instruction manual which one finds in most papers on programming, Clippinger gives a well-reasoned aoJcarefully thought-out discussion of the general aspects of business data processing, shows how FACT treats each major problem area and explains the technical factors which influenced the particuls~ technique chosen. At the same time, he manages to give a good account of the details of FACT by referring to 17 exhibits placed.
          in [ACM] CACM 2(05) May 1959 view details
  • Knuth, Donald Ervin, and Luis Trabb Pardo "The early development of programming languages" pp419-96 view details
          in Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details