NELIAC(ID:32/nel003)
Navy Electronics Laboratory International ALGOL Compiler
Navy Electronics Laboratory International ALGOL Compiler. 1958- 1959.
Numeric and logical computations, based on IAL.
Significant in that it provided the first ever bootstrap implementation, and the standard reference for NELIAC (Halstead's book) was for many years the primary reference for such compilers.
A significant non-language development of NELIAC was the first great Decompiler, NELIAC-D, which was originally a proof of concept machine independent system, but grew in importance in its own right.
People:
Related languages
| IAL | => | NELIAC | Influence | |
| NELIAC | => | Aerojet Commercial NELIAC | Extension of | |
| NELIAC | => | BC NELIAC | Implementation | |
| NELIAC | => | DIALGOL | Based on | |
| NELIAC | => | EULER | Written using | |
| NELIAC | => | Intrinsic | Inspired by | |
| NELIAC | => | NELIAC Simulator | Extension of | |
| NELIAC | => | SIMPL | Influence | |
| NELIAC | => | TEAM | Written using |
References:
in [ACM] CACM 3(08) August 1960 view details
in [ACM] CACM 3(08) August 1960 view details
in [ACM] CACM 3(11) November 1960 view details
in [ACM] CACM 3(11) November 1960 view details
in [ACM] CACM 3(11) November 1960 view details
in [ACM] CACM 4(01) (Jan 1961) view details
in [ACM] CACM 4(01) (Jan 1961) view details
The third table defines a set of some twenty-odd subroutines which do the various tasks that occur in a translation. The fourth table defines the translation algorithm by coupling all legal symbol pairs to a set of 81 generators. These generators are defined in this table and consist of sequences of subroutines defined in the previous table. The paper concludes with two examples.
The method described in this article is basically the same as that used in the original IT compiler. The addition of the operator precedence levels makes possible a natural hierarchy of operations in the input language. In the IT language, this hierarchy was determined strictly by the order in which the operators were encountered in a statement as the statement was scanned from right to left.
in ACM Computing Reviews 3(01) March-April 1962 view details
Since 1958, there has been a substantial interest in the development of problem-oriented languages as a means of controlling computers or data processing systems. All of these efforts have had as a primary purpose the goal of reducing the human effort necessary to prepare a problem for computation or processing on such a computing system.
Perhaps the most significant of these developments is the publication of the international algorithmic language called ALGOL in 1958 and a revised version in 1960. ALGOL can be described as a very general scientific language suitable for scientific or engineering computation. It has two purposes: one of these is for the communication or the publication of algorithms for solving problems, and the other is its direct use as an input language to computing machines. It has perhaps been more successful in the first case than it has in the second. However, there is a substantial number of translators which will accept ALGOL statements and produce machine language for the appropriate computer. In all cases, however, compromises have been made with the complete language. In some cases, these are very minor compromises; in other cases, they are very extensive compromises. Perhaps a more significant aspect of the development of ALGOL is the effect it is expected to have on the future design of computing machines.
Another language development, which has been sponsored by the Department of Defense of the United States, is that of COBOL, a common business-oriented language. In the meantime, the problem-oriented language which has been used most widely is the FORTRAN system, developed by the International Business Machines Corporation.
Simultaneous with the development of ALGOL 58, the author participated in the development of a problem-oriented language with a restricted field of application, namely that of simulation. In this particular problem there was no need for the various general features of ALGOL so a restricted language called NELIAC was developed and put into operation. This activity took place at the U.S. Naval Electronics Laboratory at San Diego. The unique feature of the NELIAC development has been that the translating system has always been written in the problem-oriented language itself. Consequently, revisions were easy to make and the description of the compiler on punched cards or punched tape was the up-to-date documentation of the system. Since this system was developed simultaneously with the development of the specifications of ALGOL 58, some of its features are more similar to ALGOL 58 than to ALGOL 60.
Extract: THE NELIAC SYSTEM
THE NELIAC SYSTEM
In the NELIAC system, it is possible to modify the command generators so that they will generate commands for a machine B on a computing machine A.
The original NELIAC system was written for a military computer called the Sperry-Rand M-460, and the first version generated commands for the same computer. Early in the development, the system which ran on the M-460 was modified so as to generate commands for the Datatron 205 and also for the Datatron 220, In another effort, the M-460 system was modified to generate commands for the CDC 1604.
With some help in the way of hand operations, the whole translating system was transformed from the M-460 to the Datatron 220 to obtain a NELIAC system, which runs on the Datatron 220 and generates commands for the 220. The need for the hand operations arose primarily from the fact that the Datatron 220 is a decimal machine without access to binary bits, whereas the M-460 is a strictly binary machine. In a similar way, the system was transformed onto the CDC 1604 so as to have a NELIAC system which would generate CDC 1604 commands on that computer. In another effort, the NELIAC system on the M-460 was modified so as to generate IBM 709 commands, and in a boot-strap type operation, the whole compiler was transformed onto the IBM 709 computer. A version of this was developed which generated IBM 704 commands, and of course the 709 version runs on the 7090. Various features have been added to the 7090 system to take care of the special machine features available.
In each of these cases, the NELIAC system is written in its source language form and can be recompiled on the specific computer. Consequently, if some variation in the translator is desired for a particular purpose, this is easily accomplished with a minimum of man-hour effort.
In all this development, however, whenever a new machine is considered, it is necessary to change the command generators HO that they will generate commands for the new machine. If the logic of the new machine is different, or if there are features which are of sufficient interest to be used, then perhaps even the logic of the compiling has to be modified to some extent. Thus, it may require as much effort as six man-months to establish a NELIAC system on a new computer.
in Symbolic Languages in Data Processing, in the Proceedings of the Symposium organized and edited by the International Computation Centre, Rome, Italy, March 2631, 1962, Gordon and Beech Science Publishers, 1962. view details
in Invited papers view details
in Automatic programming and compilers III view details
Contents
[1] Introduction to machine-independent computer programming
[2] How to read NELIAC or ALGOL; Publication ALGOL
[3] How to write in the language
[4] First Concepts of Self-Compilers
[5] Load programs
[6] Processing Noun Lists
[7] CO-NO Tables
[8] Generators
[9] Compiling compilers and compiler systems
[10] Input/Output
[11] Decompiling with D-NELIAC.
Appendices covering NELIAC C, NELIAC 704, NELIAC 1604, D-NELIAC
in ACM Computing Reviews 3(01) March-April 1962 view details
in Proceedings of the 16th ACM National Conference, January 1961 view details
generated using the original NELIAC system developed at the
Naval Electronics Laboratory, San Diego, in 1958. A basic
"bootstrap" process was used to generate all but the first, i.e.
the systems were described in the NELIAC language and generated
by an existing NELIAC compiler. This experience has
shown there is no inherent difficulty in "building compilers with
compilers"; indeed, it pointed out many advantages in using a
POL for constructing programming systems.
This report presents the results of a project completed in
May, 1961, in which the NELIAC system was used to generate
a compiler for the IBM 1401. The 1401 compiler, which runs on
the 7090 and produces 1401 programs, was described in the
NELIAC language and generated with the 7090 NELIAC system.
The reduction in programming time and the improvement
in documentation of the system were very significant.
in [ACM] CACM 5(02) February 1962 view details
in [ACM] CACM 6(03) (Mar 1963) view details
in [ACM] CACM 6(03) (Mar 1963) view details
in ACM Computing Reviews 4(01) January-February, 1963 view details
Advantages claimed for most NELIAC compilers are simplicity of construction and fast compiling speeds. These, coupled with the self-compiling feature, enable the programmer to produce improved versions of the compiler quite cheaply.
A listing is given of the machines for which NELIAC compilers are currently available.
in ACM Computing Reviews 5(01) January-February 1964 view details
in ACM Computing Reviews 5(01) January-February 1964 view details
To go on with the Algol development, the years 1958-1959 were years in which many new computers were introduced, The time was ripe for experimentation in new languages. As mentioned earlier there are many elements in common in all Algebraic languages, and everyone who introduced a new language in those years called it Algol, or a dialect of Algol. The initial result of this first attempt at the standardization of Algebraic languages was the proliferation of such languages in great variety.
A very bright young programmer at Burroughs had some ideas about writing a very fast one pass compiler for Burroughs new 220 computer. The compiler has come to be known as Balgol.
A compiler called ALGO was written for the Bendix G15 computer. At Systems Development Corporation, programming systems had to be developed for a large command and control system based on the IBM military computer (ANFSQ32). The resulting Algebraic language with fairly elaborate data description facilities was JOVIAL (Jules Schwartz' own Version of the International Algebraic Language). By now compilers for JOVIAL have been written for the IBM 7090, the Control Data 1604, the Philco 2000, the Burroughs D825, and for several versions of IBM military computers.
The Naval Electronics Laboratory at San Diego was getting a new Sperry Rand Computer, the Countess. With a variety of other computers installed and expected they stressed the description of a compiler in its own language to make it easy, among other things, to produce a compiler on one computer using a compiler on another. They also stressed very fast compiling times, at the expense of object code running times, if necessary. The language was called Neliac, a dialect of Algol. Compilers for Neliac are available on at least as great a variety of computers as for JOVIAL.
The University of Michigan developed a compiler for a language called Mad, the Michigan Algorithmic Decoder. They were quite unhappy at the slow compiling times of Fortran, especially in connection with short problems typical of student use of a computer at a University. Mad was, originally programmed for the 704 and has been adapted for the 7090 It too was based on the 1958 version of Algol.
All of these languages derived from Algol 58 are well established, in spite of the fact that the ACM GAMM committee continued its work and issued its now well known report defining Algol 60.
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
An important step in artificial language development centered around the
idea that i t is desirable to be able to exchange computer programs between
different computer labs or at least between programmers on a universal level.
In 1958, after much work, a committee representing an active European computer
organization, GAMM, and a United States computer organization, ACNI,
published a report (updated two years later) on an algebraic language called
ALGOL. The language was designed to be a vehicle for expressing the processes
of scientific and engineering calculations of numerical analysis. Equal stress was
placed on man-to-man and man-to-machine communication. It attempts to
specify a language which included those features of algebraic languages on
which it was reasonable to expect a wide range of agreement, and to obtain a
language that is technically sound. In this respect, ALGOL Set an important
precedent in language definition by presenting a rigorous definition of its syntax.
ALGOL compilers have also been written for many different computers.
It is very popular among university and mathematically oriented computer
people especially in Western Europe. For some time in the United States, it will
remain second to FORTRAN, with FORTRAN becoming more and more like
ALGOL.
The largest user of data-processing equipment is the United States Government.
Prodded in Part by a recognition of the tremendous programming investment
and in part by the suggestion that a common language would result only
if an active Sponsor supported it, the Defense Department brought together
representatives of the major manufacturers and Users of data-processing equipment
to discuss the problems associated with the lack of standard programming
languages in the data processing area. This was the start of the conference on
Data Systems Languages that went on to produce COBOL, the common business-
oriented language. COBOL is a subset of normal English suitable for expressing
the solution to business data processing problems. The language is
now implemented in various forms on every commercial computer.
In addition to popular languages like FORTRAN and ALGOL, we have
some languages used perhaps by only one computing group such as FLOCO,
IVY, MADCAP and COLASL; languages intended for student problems, a
sophisticated one like MAD, others like BALGOL, CORC, PUFFT and various
versions of university implemented ALGOL compilers; business languages in addition
to COBOL like FACT, COMTRAN and UNICODE; assembly (machine)
languages for every computer such as FAP, TAC, USE, COMPASS; languages to simplify problem solving in "artificial intelligence," such as the so-called list
processing languages IPL V, LISP 1.5, SLIP and a more recent one NU SPEAK;
string manipulation languages to simplify the manipulation of symbols rather
than numeric data like COMIT, SHADOW and SNOBOL; languages for
command and control problems like JOVIAL and NELIAC; languages to simplify
doing symbolic algebra by computer such as ALPAK and FORMAC;
a proposed new programming language tentatively titled NPL; and many,
many, more. A veritable tower of BABEL!
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
in [AFIPS] Proceedings of the 1967 Fall Joint Computer Conference FJCC 31 view details
in [AFIPS] Proceedings of the 1967 Spring Joint Computer Conference, April 18-20, Atlantic City, N. J. SJCC 30 view details
in Computers & Automation 16(6) June 1967 view details
The language known as NELIAC (Navy Electronics Laboratory International ALGOL Compiler) was developed concurrently with the creation of ALGOL 58. The work started at the Navy Electronics Laboratory in San Diego, California in the summer of 1958 because NEE was expecting delivery of some large computers for which there were no compilers. Professor Harry Huskey served as a consultant to a NEL group headed by Dr. Maurice Halstead. An attempt was made to follow ALGOL 58 as it was developing, but since the people concerned with NELIAC were anxious to get a system running and could not wait for the official specifications, they put in facilities or syntactic features of their own.
The key references for this language are Halstead's book [HS62], Halstead's article on documentation [HS63], and the article by Huskey, Love, and Wirth [HU63]. Without indicating specific quotation marks except where direct quotes are being made, the reader should assume that the information described here is obtained from one of these three sources.
In July, 1958 the work on the first compiler was started and it was finished within 6 months. Table IV. 1 shows Halstead's list of the implementation status in 1962. Since then, at least the following have been developed: A version called the BC NELIAC was implemented on the 7094 and versions on the UNIVAC 1107/1108, CDC 3100, 3600, 3800, Burroughs D825, and IBM System/360. Associated with one or more of these implementations or other aspects of the NELIAC developments were R. Johnson, W. Landen, K. S. Masterson, Jr., R. McArthur, C. B. Porter, S. W. Porter, R. Rempel, R. T. Stelloh, J. B. Watt, and W. Wattenburg. In spite of the large number of versions that exist, there is really no standard definition of NELIAC. There was a NELIAC users conference held in January, 1963 which appointed a committee to develop such a standard, but it never came into being. As a result, and due to the relative ease of writing and documenting NELIAC compilers (about which more will be said later), there are as many versionsas there are physical compilers. The language described will be that discussed in Halstead's book [HS62]. Certain improvements to this language were made, however, by Huskey et al. [HU63].
During much of 1962 and part of 1963, there was a great deal of controversy centering around NELIAC and its potential competition with JOVIAL. Some comparisons which I feel were not too meaningful were made, and a significant political battle ensued when a decision was made (and carried out) by the Navy to use JOVIAL for some of its command and control problems.
The language is general, with notation that is both formal and succinct. It is easy to learn, read, and write, but its usage appears to me to be error prone because of the large number of specialized punctuation rules.
The language was designed to be used for mathematics and engineering problems, business problems, command and control problems, and systems programming. It is procedure-oriented, problem-oriented, and problemsolving and simultaneously a hardware, reference, and publication language if special typewriters are available. It was meant to be used by all types of programmers, both professional and nonprofessional. It was definitely a batch system but requires typewriters with the defined character set or key punches which then require a hardware representation for some of the characters.
The compatibility of NELIAC is something about which one could write an entire book (and to some extent Halstead did). It was meant to be machine independent, particularly since the NELIAC compilers were written in NELIAC except for the initial bootstrapping. However, the ability to allocate variables to particular bits or characters in words makes this impossible. Furthermore, differing input/output facilities made NELIAC obviously dependent upon particular machines. Since the compilers were readily changed, it is not clear if the results obtained on one compiler could necessarily be obtained on the other; there does not appear to be any significant substantive data on this. There were definitely subsets created to permit bootstrapping, but much less was done in the way of providing direct clearly identifiable extensions; most of the latter appeared in the form of removing certain restrictions, which of course can be considered a form of extension. There is no doubt but that a NELIAC program can be very easily converted, if not directly at least with a very small amount of effort, to run on another machine with a NELIAC compiler. NELIAC can be transliterated fairly easily into ALGOL publication language, but in my view its external appearance does not resemble ALGOL 58 very much.
Any consideration of NELIAC compatibility must take into account the basic philosophy that the language is meant to be easy to modify for any particular implementation or application. In Halstead's words, 'In short, it is a dynamic language, with compatibility preserved by the ease with which desirable features can be added to any implementation as it becomes useful to do so.{13} While recognizing the validity of such an approach for solving problems, I do not feel that this philosophy addresses itself to compatibilitydifficulties in any realistic way, where compatibility is meant to ensure ease of running a program on more than one computer.
As indicated before, there was no official group standardization effort, and the closest thing to such a standard is Halstead's book. Unfortunately that does not contain a complete description of the language, except through the actual listings of one of the compilers, The language was designed by a group at the Naval Electronics Laboratory under the guidance of Huskey and Halstead, with the objectives indicated above. It has been implemented by a number or different people, but the language is not being maintained in an official way. According to Halstead's description, the official documentation for any given compiler is the listing of the NELIAC statements comprising that compiler. The primary source document for the language is Halstead's book [HS62]. Other references are shown in the bibliography at the end of the chapter. One of the interesting facets of the documentation is that Halstead's book serves not only to define the language but also to cover the methods in writing NELIAC compilers as well.
NELIAC has been implemented in varying degrees of completeness on many computers (which were listed earlier), The language has apparently been most effective for relatively small programs but less so for extremely large ones; however, programs containing 100,000 words of object code have been successfully written. NELIAC has proved easy to use and the compilers are fast because of the simplicity of the language.
Extract: Technical details of NELIAC
Technical details of NELIAC
The character set consists of the 52 upper- and lower-case letters, the 10 digits, and the following 26 characters:
, ; : . ( ) [ ] { } + - x / {} {} | = {} < > {} {} {} {} 8 (subscript)
Various hardware representations exist.
There are key words but in most cases they are optional. The graphic operators and punctuation are shown above.
Identifiers must begin with a letter of the alphabet; they can contain only letters, spaces, numbers; they must be uniquely determined within the first 15 characters. Upper- and lower-case letters are interchangeable, i.e., ABC and abc represent the same name. The words IF, IF NOT, DO, GO, TO, and FOR are both reserved and noise words. They can be omitted in certain cases, but when present, they must be preceded and followed by at least one space, They cannot be used as identifiers. The six single letters I, J, K,L, M, N, when standing alone, are used as counters and cannot beused for identifiers. An identifier can have one subscript which consists of one of those letters or an integer, or a letter with an integer added to it; some compilers permit the use' of a variable as a subscript. Generally only one subscript is permitted.
The operators consist of the five arithmetic operators, the absolute sign, and the six relational operators. There are also two Boolean operators. Punctuation is extremely critical and used as the delimiters in most cases, as seen from the following rules. (1) The comma is used to delimit executable statements. (2) A semicolon can be used for this purpose also except in conditional statements, where the true and false parts must end with either semicolons or periods. (3) A semicolon also delimits the dimension statement. (4) A comma following a single identifier denotes a subroutine call. (5) A period following a single identifier denotes an unconditional control transfer. (6) A double period denotes the end of the program. (7) A colon is used to delimit a statement label and also to delimit the comparison in a conditional statement. (8) Braces are used to enclose a subroutine, to delimit the range of a loop, and to delimit either alternative of a comparison statement. Braces are also used to specify parts of a word in both the dimension statement and the execurable statements.
As indicated in the rules for naming, blanks are significant. Although in many cases both fixed words and punctuation may be written, it is the punctuation which is critical and the words can be omitted. In general, noise words are not permitted, except for the cases of this type. Literals are enclosed in quote marks" which appear in some hardware representations, but they are often limited to one machine word.
Since there are differing devices although primarily paper tape in the earlier systems used for input, the physical input form depends on the device somewhat. The conceptual form is certainly free form to the largest extent possible.
There is really no smallest executable unit considered as a separate entity because the language is completely based on the concept of a triplet consisting of two operators and an operand between them. Thus there is no grouping. Looping is controlled by either conditional statements or by the FOR statement. Both subroutines and functions can be defined with input and output parameters; they are called by location. Delimiting is normally accomplished by the specification of the meaning of each triplet. However, function and subroutine definitions must be enclosed in braces. Functions can be embedded in expressions. There is no language provision for recursion. The noun list which contains the dimensional information, and can contain initial values, must appear at the beginning. Other languages can be entered through the use of the crutch operator, which serves as a flag to the NELIAC compiler that some other language is to be processed. Only arithmetic variables, and vectors of them, are permitted. Perhaps the most interesting aspect about NELIAC is the facility to assign names to parts of computer words. Thus the programmer can pack several variables within a single word, and this is shown in the noun list, e.g., Unit Cost: [cost per apple (0 {} 5), cost per orange (6 {} 11), cost per lemon (12 {} 17),}. These character limits can overlap. In addition to that, even if the programmer has not specified a partial word in his noun list, he can nevertheless refer to a part or' any named noun by the use of parentheses and an arrow; e.g.,
Code (0 {} 10) Form (15 {} 25), List A[1] (3 {} 7) B1, C(l5 {} 20) + D (25 {} 30) C(0 {} 6),
Note that this reduces or eliminates compatibility between binary and decimal machines, or even between machines of different word lengths.
Only fixed and floating point numbers are allowed. All variables are considered integers by default, unless they appear in the noun list with some floating point number to set the mode. Boolean arithmetic is done with the relational operators and the use of the cap and cup characters.
In some (but not all) of the compilers, integer and floating point numbers are permitted in the same expression, and the computation is done in floating point. In some compilers, arithmetic expressions cannot contain grouping parentheses, but normal precedence is used.
Scope is handled in a rather interesting way. If a variable is to be used in several programs, the most recent value will be taken unless an absolute sign (i.e., vertical bar) is placed after the first letter of the noun or verb; in this case it has only local significance. For nouns the absolute sign is used only in the Noun List or Dimensioning statement. For verbs or verb phrases, it should be used only at the point where the verb is being defined.
There is a single type of assignment statement which assigns the value of an arithmetic expression to a variable or to parts of a variable. Thus writing A {} B (1{} 5) would store the contents of A in positions 1-5 of word named B and leave the rest untouched. However, A(1{} 5) B would set all of word B to zero before carrying out the assignment. It is possible to have assignment statements concatenated; hence A[l] + B[J] {} C {} D would store A[l] + B[J] in both C and D. In most systems, converting variable types across the arrow is not automatic. There is no provision for handling alphanumeric information.
An unconditional transfer is actually shown by means of punctuation; the rule is that whenever a name is preceded by a nonarithmetic operator and followed by a period, control will pass to the indicated name. However, if a comma follows the name then this serves as a subroutine jump. Thus for example, writing, ABC. or A + B {} C; ABC. will cause an unconditional control transfer to the statement named ABC. By writing ,ABC, FIND NEXT WORD: Xl - Y {} Z, the instructions in subroutine ABC will beexecuted and then the statement X1 - Y {} Z will be executed. Subroutines and functions are invoked by writing the parameter list in parentheses after the name, separating the arguments by commas, and following this with a comma, e.g., SUM(1, GAMMA, 4),. The comma is not used when the function is included in an expression.
The conditional statement is written in the form
IF relation: statement-for-true-path; IF NOT , statement-for-false-path.
Several points need to be made about this general form. First, the relation can have only a single variable on the right of the relation sign. Thus, the following are legitimate:
IF A(2{}7) < B < C: IF A + (B/C) {} U = V,
whereas
IF A + B = B + 1:
is incorrect. In some compilers it is possible to include Boolean ands and ors, thus permitting
IF A < B {} C = D U A = D:
Second, the words IF NOT are not required; the semicolon or period following the statement for the true path is the defining character for the negative path. Third, the executable statements can themselves be conditional, provided they are stated completely within either the true or false path. Finally, the actual sequencing rules are controlled by punctuation. Since either a period or a semicolon can terminate the true or false path, these paths can contain subroutine calls or unconditional transfers. For example, one can write
IF Y < 2: Y + 1 {} Y, ROUTINE 1, ROUTINE 2, ETC. IF NOT , Y - 1 {} Y, CASE 1, CASE 2;
Loop control is handled by the FOR statement, which has the following format:
FOR variable = initial value (increment) final value [range]
As an example, the user can write
FOR I = 0(1)20 {NR[I] + COST[1] {} TOTAL COST[I], COMPUTATION: A + B[I] {} C[I],}In some compilers there was a restriction that the final value must be reached precisely by adding increments to the initial value.
Since ALGOL did not have any input/output statements, it is not surprising that NELIAC did not originally. Many of the early compilers just created subroutines or borrowed existing input/output packages. However a semi-machine-independent technique has been implemented on a few of the NELIAC compilers. This technique makes use of the < and > symbols to serve as quotation marks. Three forms exist, of which the first specifies the output of headings, the second the output of numerical data, and the third calls for the reading of data into the computer, as shown below:
Form 1. Form 2. Form 3.
,A{B<
The letter A can be replaced by any appropriate comment, B refers to a particular piece of peripheral equipment, and C represents names of nouns or noun lists. If 8 [s either omitted or calls for equipment not available, some fixed equipment designated by each installation will be used. Thus for example, the user can write
, Print Headings { Flex << List >> ) , Print Result ( {ISP < Answer > ) , Read Data [ > Temperatures < )
There are no library facilities or built-in functions, debugging statements, storage-allocating statements, nor interaction with the operating system, although certain systems provide some of these facilitiesThe only declaration is the noun list which appears at the beginning of the program and in which every variable to be used in the program must he listed. Initial values can be given here, and dimensioning is handled by simply writing the dimension enclosed in parentheses after the name o1' the variable, e.g., COST (3) = 10, 15, 8. Also within those declarations are specified the part of the word that the user is applying to the variable, e.g., LENGTH (0 {} 5). The dimension and word portion can be given at the same time.
Subroutines and functions are defined by following the name with a colon, then a parameter list in parentheses, and then the body of the routine enclosed within braces and terminated by a comma, e.g., FUN: (X, Y) [body}. Types and numbers of parameters depend on a particular implementation.
Extract: Impact of NELIAC
Impact of NELIAC
The strongest feature or NELIAC is the ease with which it can be used to write its own compiler. There has been a very definite interaction between the language design and the implementation- In fact the syntax of thelanguage is built entirely on the implementation technique, which is what they call the Co-No (current operator--next operator) Tables. There are actually 676 combinations in the Co-No Table, but of course some of these are errors. Furthermore, a number of the combinations require the same code generation.
The self-compilation feature produces an interesting effect on object code efficiency. As the compiler is improved, it may improve both the object time and compile time efficiency simultaneously because the compiler is run through itself. Hence, any differences in the relative effect on compile time and object code efficiency would tend to be caused by the logic of the compiler rather than by the code generation phase.
One of the applications for which NELIAC has been used is the rather interesting Blood Bank Program described by Singman et at'. [SI65]. An older application was its use to write a very simple compiler for the 140I (see Watt and Wattenburg [WJ62]). An ALGOL system at the University of California at Berkeley has been written in NELIAC. A successful command and control application was the Command Ship Data System for the Navy, whose object program contained over 100,000 instructions. NELIAC has also been used to help program a search procedure (see Halstead, Uber, and Gielow [HS67]). Unfortunately, public documentation of actual applications of NELIAC is very scarce and the descriptions seem to be internal documents of the using installation. As somebody noted facetiously, the main use of NELIAC has been to write other NELIAC compilers.
NELIAC has made several contributions to the technology. It was the first language used consistently to create all its own compilers, and it was used several times to compile programs on one machine, producing object code for another. For example, the NELIAC on the CDC 1604 produced code for the CDC 160A. The use of the partial word designations in the executable statements is still unique to NELIAC, except for the JOVIAL BIT and BYTE, which are not as powerful or flexible. The use of the clearly defined tables of operators and operands formalized the compiling technique but simultaneously caused a more stilted language.
in Computers & Automation 16(6) June 1967 view details
NELIAC
A very early operating system that was developed using a higher level language is NELOS (NELIAC Operating System). This was developed on the UNIVAC 460 around 1961. An operating system on the CDC I604 was developed later using NELIAC [Halstead, 1971].
in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details
[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] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details
in [ACM] CACM 15(06) (June 1972) view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
in ACM Computing Reviews 15(04) April 1974 view details
The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.
There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.
The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.
Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .
It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.
The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.
It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.
We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.
Graz / Austria, May, 1973
in ACM Computing Reviews 15(04) April 1974 view details
in SIGPLAN Notices 13(11) Nov 1978 view details
Machine-Independent Computer Programming, by Maurice Halstead, was a pioneering book of the early 1960s. It told the story of a new programming language- Neliac, an Algol-derivative language defined for Naval Electronics Laboratory (NEL) use-which had certain almost magical properties. One such property was that it was a language defined so as to make it easy to build a compiler for it. In that, it succeeded admirably. The listing for the full compiler, a marvel of simplicity, could be held easily on one fully extended hand, so small and light was it. Another magical property was that the compiler was coded in its own language, an idea so daring for its time that the typical software mind boggled that such a thing could be done. "But how do you start one of those?" was the most frequently asked of many incredulous questions. Neliac, as Halstead described it in his book, was a language for systems and scientific programming. The thrust of this story is the attempt by an earnest group of programmers at the Aerojet-General Corp in Sacramento to make the language viable for commercial programming as well. Extract: NELIAC as commercial autocode II
An operating system called Nimble was to be designed and implemented in-house, some needed utilities like math libraries and sort packages and report generators were to be added, and-to bring the story back to its focus-a Neliac compiler had been obtained from the government, put into immediate use for scientific applications, and work as begun on the necessary commercial language supplements. All of that software effort, it is worth repeating, had evolved under the alert eye and specific planning of Don Starr. It was, for that time and for all time, a truly impressive undertaking for an industrial production-oriented computing shop. Essentially we took a bare-bones IBM 7040 and built the whole software system for it.
Neliac was critical to the whole scheme. Nimble, the operating system, was entirely coded in it (some parts were later recoded into assembler due to efficiency problems). And in fact, all the other system components were coded in it, too. For us, it had already become both a scientific and a systems programming language when we set out to make the commercial enhancements. That may not seem exciting now, but for its time, this whole project-and especially the reliance on a high-order language-was daring.
The commercial enhancements wereeasy to define. We needed a good, capable sequential I/O package, buffered and blocked, and callable from the language transparent to the user. We needed an indexed-sequential package to support pseudo-random, real-time accessible files (more innovation!). We needed data structures, including the capability to define and manipulate heterogeneous data aggregates which often contained non-word-oriented bit and character strings.
We did it! We added what we needed to that elegant language of Halstead’s, retaining its fast-compilation origins but enhancing it for a whole new domain. We implemented what we added, sometimes consistent with the compiler’s simplicity, but sometimes not. And we put it all, the language and the operating system and all its trappings, proudly, on the air. Our commercial colleagues were not technologically as well as managerially integrated with us. Extract: Compiler Delivery
The Neliac compiler and language were at the heart of the Aerojet system. My personal role in the project was largely that of adding commercial data processing capabilities (character string moving and comparing, and index sequential file manipulation) to the language and the compiler. Nearly 30 years after the fact, I clearly remember the following several incidents in working with the compiler.
Compiler Delivery
Neliac was designed for Naval Electronics Laboratory use, and as such it was in the public domain. The decision to use Neliac for the Aerojet project, of course, involved contacting the Navy to determine availability. At the time, the compiler was being maintained for the Navy by a commercial software house located in San Diego. We contacted that software house, and flew from Sacramento to San Diego to take delivery.
Although we did not need to buy the compiler itself, we did buy something that was far more impottant--consultation support on the internal design and workings of the compiler. We spent a day or two at the offices of the San Diego software house, and received thorough and intimate training in compiler modification. One problem with the compiler at the time was that the symbol table searchwas sequential-for large source programs, compilation time became excessive. With advice from the compiler maintainers, our delivery team learned how to convert the symbol table access mechanism from sequential to hashed.
What most impressed me about this compiler delivery is the ease with which that conversion was made. The symbol table access mechanisms were well isolated from other functionality, and the symbol table could only be accessed through those mechanisms. It was a simple matter to unplug the sequential routines and plug in new hashing ones. In retrospect, it was an impressive display of the value of data abstraction and object orientation. Although we did not use those terms then, we certainly understood the importance of the underlying ideas. It is interesting to note that this idea was used by whoever built this part of the compiler, perhaps Maury Halstead himself, over 25 years before it became a key part of the computer science world.
Extract: Character String Handling
Character String Handling
Dramatic simplification of complexity is perhaps the most brilliant achievement programmers can hope for. Maury Halstead’s compiler was a model of simplicity. During a one-pass, left-to-right scan of the source text, the compiler successfully generated every bit of object code that was needed. Remember that the language was designed to facilitate easy compilation. For example, parenthetic algebraic expressions as such were not allowed.
When I began to add character string handling capability on behalf of our data processing users, I was dismayed to find that I simply could not make the changes I needed to and maintain the one-pass simplicity of the compiler. No matter how hard I tried, some kind of extra pass, at least over the character-handling procedural code was required. I sought advice from all who would listen, but to no effect. In the last analysis, it felt like my additions to the compiler, so necessary for the expanded use of a new application domain, were a patched kludge in a brilliant design.
Extract: Indexed Sequential Files
Indexed Sequential Files
The idea of random files was quite new at the time. We had just learned that purely random files, so quick to access, were dreadfully slow to create and rebuild. A middle ground between sequential files (the old way) and random files (the exciting new way) was needed for efficiency’s sake.
I’m not sure who originally thought of the idea of index sequential files-files stored sequentially but accessed semi-randomly via an index. It may well have been IBM, because it wasn’t too long after that that IBM made ISAM file handling available. But I was assigned to provide a callable index sequential package to supplement the compiler, a library routine that would be invoked through the procedure call mechanism whenever the necessary subroutine call was made in the source code. Don Starr laid out the requirements for such a package for me, and I quickly designed and coded the appropriate routines. My most clear memory of this time is that someone who happened to be in the machine room one day, when my routines were processing some live and sizeable files, reported back to me that they had spotted an inefficiency.
Every time a record was needed, my code would access an index, then access the needed record. Even if the needed index or record were already in computer main memory! Why not, the eagle-eyed observer suggested, build a flag into your package so that if the same index or record were needed twice in a row, the software could simply reuse it rather than go through the (painfully slow) file access process all over again. Our learning experiences as growing computing professionals in those early days were derived from a wide variety of educational sources, even including people standing in the computer room!
in Annals of the History of Computing 13(1) 1991 view details