DEC simplified Algol
for DEC Algebraic Language (no relation to DEC Author Language)
or perhaps (according to Bennett 1976) for DEC Compiler, Assembler, and Linking Loader (though that would be DECCALL)
Hybrid of DEC assembler and Algol 60, used in the Decision Sciences Lab ESD and written by ICS.
Like Algol 60, it lacked I/O which was rectified in different ways (hence different dialects)
The basic 1-core version of DECAL was released in its present form as DECAL-BBN in September, 1963. Since that time there has been a general increase in memory capacity of many PDP-l's, and DECAL has likewise been expanding. The first development was the moving of the compiler's symbol table into the second core field. This al lowed large programs with many symbols to be compiled. Next came a 2-core modification to allow the compilation to be carried out in sequence break mode. This doubled the speed of compilation. Recently there has been a further modification to compile programs written in ASCII source language .
The author has been carrying on work to extend the DECAL language. In particular the work has been in the area of allowing real (floating-point) variables and constants to be handled automatically in algebraic statements. The other area of work has been to implement input/output facilities in the DECAL language. This has lead to the development of a language similar to the FORTRAN input, output, and format statements.
Finally the author will discuss the desirability of implementation of DECAL on the other PDP computers. DECAL has been developed into a powerful and elegant language through many man-years of effort. Perhaps consideration should be given to other machines, specifically the PDP-6 and PDP-7.
DECAL, Digital Equipment Corporation Algorithmic Language, in its original form, came into being in 1960 as the first algebraic compiler for a DEC computer. It was designed with some very advanced features still applicable to today's compilers, and has been well proven as a compiler for the professional programmer. In fact, as an assembler-compiler, DECAL can be used when a mixture of both machine codes and problem-oriented language is required. The problem-oriented language is similar to ALGOL in call-by-value procedures and conditional statements, and in statements and subscripted variable handling . Dynamic array handling is also allowed. The compiler does not process recursive procedures, call-by-name procedures, or its own variables.
The object code produced by DECAL is an intermediate code which is then loaded into core in binary by the DECAL Linking Loader. All source programs are compiled relative to a common origin. At load time they are processed in any order by the DLL and automatically relocated with symbols cross-linked between the various programs. The DLL can accept a library tape on which all utility subroutines may be stored.
The present generation of DECAL compilers was initiated in 1962, by the author and his associates at Bolt, Beranek and Newman, Inc . , and is known as DECAL-BBN. This is a one-core version which contains all the features of the language described in the DECAL-BBN Programming Manual which is used today. It was soon decided, however, that one core did not allow enough room for future system expansion or for compilations of large programs, and was too restrictive because most users had more than one core memory on their computers.
It was decided to move the symbol table to the second core, and this new version became known as 2-core DECAL-BBN. A subsequent version, Sequence Break DECAL, provided for the reader, punch, and typewriter to operate under program interrupt control, making compilation about twice as fast.
The next major development came from BBN under sponsorship of the Decision Sciences Laboratory. The DSL PDP-1 Complex had grown to include ASR-33Teletypes and a Type 164 Line Printer, both of which used ASCII code. DECAL and DECAL Loader were modified to accept ASCII code as source codes as well as to compile strings into ASCII code. The nonalphabetic codes, mostly for the instruction generators, were modified to be compatible with the ASCII character set. For example, the FIODEC codes representing instruction generators such as "A " and "V" were changed to "AND " and "OR"; the symbol "AND" was made to have meaning both in an algebraic statement (A AND B => C) or in an instruction statement (AND B). This Teletype DECAL will be embedded into a DSL Monitor System able to compile, load, and go through a sophisticated monitor built around the Type 24 Serial Drum.
in DECUS Spring Conference 1965 view details
The ideas and philosophy of the BUILD approach have been developed over a period of years, starting with discussions in early 1960 between the author and Edward Fredkin, now Professor at M.I.T., about how an assembler might be built with a minimum effort, which could be extended from its input. Later that year, Fredkin wrote FRAP (Fredkin's Assembly Program) for the DEC PDP-1, and the author, DECAL (DEC Compiler, Assembler, and Linking Loader for the same machine.
In 1962, the author employed the macro facility in BE-FAP to implement a partial-word facility, a list-processing facility, and many special purpose tools, in the process of writing a large-scale communications network simulator for Bell Telephone Laboratories. Although this method of language extension was awkward and inefficient, it nevertheless proved the great value of the ability to create general- and special-purpose tools, as they are needed in a complex programming project.
Between 1962 and 1964, the author directed a project which produced SET (Self-Extending Translator) for the IBM 7094. In 1967, the author received support from the Air Force Office of Scientific Research for a year, to pull together the ideas and results of previous work. This effort culminated in a report in 1968. in which the acronym "BUILD" was first used.
In 1969, the author implemented a small BGP on a DEC PDP-9 at Berkeley Enterprises, Inc.. Newtonville, Massachusetts. This BGP was used principally to experiment with phrase-delimiting and phrase-processing algorithms. During the past two years (1972-1974) the author has implemented the current BGP (about 75% complete) as an adjunct to his work producing an assembler and other subsystems on a DEC PDP-10. Extract: Basic Language Constructs
Basic Language Constructs
A word in the BUILD system is like a word in a natural language. It is a concatenation of characters, which forms an entity whose meaning is independent of the meaning of its individual characters or sub-parts. In the present version of BGP, a word may contain up to 28 characters. Where the term "word" may be confused with a machine word, the term lexical word (LW) IS used instead to avoid confusion.
A lexical word is the same as "token". "symbol", "identifier", "operator", etc. in other systems. In the BUILD approach, the special characters form words, In the same way as alphanumeric characters do,
In the BUILD system, it is thought important to have a word-delimiting algorithm (lexical scanner) which is independent of the meaning of the words delimited. The algorithm used in the present BCP has this property, is simple, and has proved to be fully adequate for all purposes thus far encountered. The algorithm is more precisely stated in Appendix I. Briefly, each character is assigned a character class, solely for the purpose of word delimitation. (The character class does not prejudice the meaning of resulting words.) Characters of the same, or related, classes combine to form words. Characters of different and unrelated classes delimit words. Blanks, tabs, and end-of-line characters delimit words formed of characters of any class.
Alphabetic and numeric characters combine, but a pure numeric is recognized as an integer, Also, most special characters combine to form words.
The definition or declaration of a word Is specified prior to its use. The definition of a word consists of its type and an attribute list constituting its meaning. The structure and interpretation of the attribute list of a word is a function of its type.
The BGP contains many predefined words. The user can define new words of any existing type. (Eventually, the user will be able to add new word types.)
A phrase is a group of words which is interpreted in a uniform manner. Examples of phrases include a statement, a compound statement, an argument list, and an individual argument.
In the BUILD system, phrases are delimited by words of type "Phrase Delimiter" (PD). Phrase Delimiters come in 4 subtypes: Open, Close, Alternating, and Separator. The first two are matched. The third, Alternating, alternates between opening and closing phrases. The last, Separator, is used to separate elements of a list, although precisely speaking it terminates phrases.
The rules of phrase delimitation, together with "the predefined PD's in BOP, are given in Appendix IL Briefly, the user has the option of the method to be used for phrase delimitation, for style .and readability. The matched PD's, in the order of increasing closure strength:
are availably in the current BOP. (Closure strength is defined in Appendix II.) The user may select among these, or add new ones, as he chooses. He may also omit PD's, where the context permits.
In the text of this paper, parentheses ( ) are used to delimit simple phrases and brackets [ ], compound phrases. (In practice, the user has the choice between the methods of phrase delimitation, as described above.)
A prefix operator is one which precedes its operands (or arguments), if it takes any. Examples of prefix operators include the word types: Macro (ME), Procedure (PR), Machine Instruction (IN), Action Operator (AS). (The latter, AS, is defined in Section 5.)
A prefix operation is a prefix operator, together with its arguments.[...]
An infix operator is one that appears between its operands. A unary operator is considered to he an infix operator with a null left operand.
An infix operation is an infix operator, together with its operand(s). The syntax of a simple infix operation is a word of type Variable (VR), followed by a word of type Infix Operator (OP), followed by a word of type VR. The first word of type VR may be missing -- the unary operation case.
An infix operation may be nested, in the sense that one or both of its operands may be operations -- either infix operations or certain prefix operations (e.g., function calls, subscripted variables).
A prefix operation may also be nested, in the sense that, in certain cases, one or more of its arguments may be prefix or infix operations. The nesting syntax and conventions are essentially the same as for FORTRAN, ALGOL, and PL/I.
in SIGPLAN Notices 11(07) July 1976 view details