User:Steamerandy/sandbox

CWIC (Compiler for Writing and Implementing Compilers)

In 1968-1970, Erwin Book, Dewey Val Schorre, and Steven J. Sherman developed CWIC (Compiler for Writing and Implementing Compilers). The SDC documentation for CWIC is archived at System Development Corporation Charles Babbage Institute Center for the History of Information Technology (Box 12, folder 21), The ACM DIGITAL LIBRARY also contains a short introductory paper on CWIC

CWIC is a compiler-compiler that combines Schorre's META II parser programming language, with a LISP 2 based code generator functions. The MOL-360 programming languages is inluded for writing support functions. Each language permits programming certain aspects of translation, transformation or run time support functions.

CWIC's SYNTAX and GENERATOR languages create and operate on objects. A variable may contain any object type. An integer at some point, a string another time or a symbol or list, etc. Objects can be tested as to their type. In their day these languages were called object oriented but today they would be considered domain specific object based languages.

The syntax language is in part a string processing language used to write an analyzer of input text and its transformation to an intermediate, functional equivalent abstract parse tree.

The generator language is used to recognize tree and list structures, reducing and transforming them to object code.

MOL-360. Machine Oriented Language-360, is a mid-level systems programming language for the IBM System/360 family of computers that is used to provide an interface with the machine and it's operatering system. MOL-360 was independently developed in 1968 and used to develop the ADEPT time sharing system.

The language of the compiler created is called the object language. The Syntax language analyzes the object language grammar and transform it into abstract syntax trees that are passed to generator transform rules. Grammar analysis is performed using programmed top down analytical functions that are written as grammar rules. As rules parse the input, checking for errors, they create list/tree structures that are passed to a generator transform rule by placement of a generator call in a grammar rule. A tree is a list whose first element is a node. The colon : operator is used to create node objects. Created node objects are pushed onto the node stack. :ADD creates an ADD node and pushes it on the node stack. The exclamation ! operator followed by a number combines that number of parse stack entries with the top node to make a tree. !2 pops the top two parse stack entries, combines them with the popped top node stack entry making a three element list that is then pushed on the parse stack. The list having it's first element a node is recognized as a tree.

expr = term $(('+':ADD/'-':SUB) term!2);

The above grammar rule defines an expr to be a term followed by zero or more + or - term. The $ is an operator specifying that zero or more of the following should be recognized. ( ) are used to group tests in the same way as conditional expressions use them. Grammar rules are boolean functions returning success or failure. Success and failure are like boolean true and false but may be implemented as processor status flags. A rule is made up of operators, groupings ( ), and tests that primarily operate on the source input stream. A test may be a rule, string, or generator call.

The above rule recognized a single term or a sequences of terms separated by + or - arithmetic operators. When the arithmetic sequence:

a + b - c

is presented to the expr rule a tree of the following form is created:

SUB[ADD[a,b],c]

The above is in CWIC tree notation. The node is shown proceeding the tree branch list enclosed in [ ]. in list notation it would be shown as:

[SUB,[ADD,a,b],c]

The grammar generated lists are like a polish prefix functional notation. We now have the operation followed by it's operands.

The lists are processed by generator functions, returning success or failure. The syntax language is very close to TREE-META. Both use a colon to create a node. CWIC's tree building exclamation !<number> functions simular TREE-METAs [<number>] except it being in dependent of the :<node> creation opeation.

GENERATOR

A generator is a named series of transforming rules, each consisting of an unparse, pattern matching, rule. and an output production written in a LISP 2 like language. the translation was to IBM 360 binary machine code. Other facilities of the generator language generalized output. The parse tree was thought of as a recursive list. The general form of a Generators Language function is:

function-name(first-unparse_rule) => 
    first-production_code_generator
             (second-unparse_rule) => 
    second-production_code_generator
             (third-unparse_rule) =>
    third-production_code_generator
               ●
               ●
               ●

s a given tree included the features of a general purpose programming language, plus a form: <stuff>, which would emit (stuff) onto the output file. A generator call may be used in the unparse_rule. The generator is passed the element of unparse_rule pattern in which it is placed and returns values are listed in (). For example:

expr_gen(ADD[expr_gen(x),expr_gen(y)]) =>
           <AR + (x*16)+y;>
           releasereg(y);
           return x;
        (SUB[expr_gen(x),expr_gen(y)])=>
           <SR + (x*16)+y;>
           releasereg(y);
           return x;
        (MUL[expr_gen(x),expr_gen(y)])=>
                              .
                              .
      .
        (x)=>
;          r1 = getreg();
           load(r1, x);
           return r1;
...

That is, if the parse tree looks like (ADD[<something1>,<something2>]), expr_gen(x) would be called with <something1> and return x. A variable in the unparse rule is a local variable that can be used in the production_code_generator. expr_gen(y) is called with <something2> and returns y. Of note here is a generator call in an unparse rule is passed the element in the position it occupies. Hopefully in the above x and y will be registers on return. The last transforms is intended to load an atomic into a register and return the register. The first production would be used to generate the 360 "AR" (Add Register) instruction with the appropriate values in general registers. The above example is only a part of a generator. Every generator expression evaluates to a value that con then be further processed. The last transform could just as well have beenr writen as:

               (x)=>     return load(getreg(), x);

In this case load returns it's first parameter, the register returned by getreg(). the functions load and getreg are other CWIC generators.

MOL-360

The MOL-360: an independent mid level implementation language language developed in 1968 and used for writing the underlying support library.

Abstract Parse Tree

The APT (Abstract Parse Tree) is an Abstract Syntax Tree built up as input source code is recognized. It is created by the tree transform operators placed in grammar rules.

Reductive Grammar

A reductive grammar is a set of rules for the analysis of a stream of symbols to determine their meaning and correctness

CWIC

In 1969-1970, Erwin Book, Dewey Val Schorre, and Steven J. Sherman developed CWIC (Compiler for Writing and Implanting Compilers). The SDC documentation for CWIC is archived at System Developmuent Corporation Charles Babbage Institute Center for the History of Information Technology (Box 12, folder 21),

CWIC is a metacompiler system. It combines Schorre's metaprogramming reductive grammar and LISP 2. There are three languages. Each language permits programming certain aspects of translation or transformation and run time support functions.

CWIC languages create and operate on objects. A variable may contain any object type. A variable may contain an integer at some point and at another a symbol or a list etc. Objects can be tested as to their type.

The syntax language is used to write an analyzer of input text and its transformation to an intermediate, functional equivalent, abstract parse tree.

The generator language is used to recognize tree and list structures, reducing and transforming them to object code.

MOL-360 ,Machine Oriented Language-360, is a mid-level systems programming language for the IBM System/360 family of computers that is used to provide an interface with the machine and it's operatering system. MOL-360 was independently developed in 1968 and used to develop the ADEPT time sharing system.

The language of the compiler created is called the object language.

Syntax

The Syntax language analyzes the object language grammar and transform it into an abstract syntax tree that are passed to generator transform rules. Grammar analysis is performed using programmed top down analytical functions that are written as grammar rules. As rules parse the input, checking for errors, they create list/tree structures that are passed to a generator transform rule by placement of a generator call in a grammar rule. A tree is a list whose first element is a node. The colon : operator is used to create node objects. Created node objects are pushed onto the node stack. :ADD creates an ADD node and pushes it on the node stack. The exclamation ! operator followed by a number combines that number of parse stack entries with the top node to make a tree. !2 pops the top two parse stack entries, combines them with the popped top node stack entry making a three element list that is then pushed on the parse stack. The list having it's first element a node is recognized as a tree.

expr = term $(('+':ADD/'-':SUB) term!2);

The above grammar rule defines an expr to be a term followed by zero or more + or - term. The $ is an operator specifying that zero or more of the following should be recognized. ( ) are used to group tests in the same way as conditional expressions use them. Grammar rules are functions returning success or failure. Success and failure are like boolean true and false but may be implemented as processor status flags. A rule is made up of operators, groupings ( ), and tests that primarily operate on the source input stream. A test may be a rule, string, or generator call.

The above rule recognized a single term or a sequences of terms separated by + or - arithmetic operators. When the arithmetic sequence:

a + b - c

is presented to the expr rule a tree of the following form is created:

SUB[ADD[a,b],c]

The above is in tree notation. The node is shown proceeding the tree branch list enclosed in [ ]. in list notation it would be shown as:

[SUB,[ADD,a,b],c]

The grammar generated lists are like a polish prefix functional notation. We now have the operation followed by it's operands.

The lists are processed by generator functions, returning success or failure. The syntax language is very close to TREE-META. Both use a colon to create a node. CWIC's tree building exclamation !<number> functions the same as the TREE-METAs [<number>].

Generator

A generator is a named series of transforming rules, each consisting of an unparse, pattern matching, rule. and an output production written in a LISP 2 like language. the translation was to IBM 360 binary machine code. Other facilities of the generator language generalized output.<ref name=CWIC The parse tree was thought of as a recursive list. The general form of a Generators Language function is:

  function-name(first-unparse_rule) => first-production_code_generator
                   (second-unparse_rule) => second-production_code_generator
                   (third-unparse_rule) => third-production_code_generator
               ..
               ...

s a given tree included the features of a general purpose programming language, plus a form: <stuff>, which would emit (stuff) onto the output file. 
A generator call may be used in the unparse_rule. The generator is passed the element of unparse_rule pattern in which it is placed and returns values are listed in ().  For example:
  expr_gen(ADD[expr_gen(x),expr_gen(y)]) =>
                                <AR + (x*16)+y;>
                                releasereg(y);
                                return x;
               (SUB[expr_gen(x),expr_gen(y)])=>
                                <SR + (x*16)+y;>
                                releasereg(y);
                                return x;
               (MUL[expr_gen(x),expr_gen(y)])=>
                              .
                              .
                              .
               (x)=>     r1 = getreg();
                            load(r1, x);
                            return r1;
...
That is, if the parse tree looks like (ADD[<something1>,<something2>]), expr_gen(x) would be called with <something1> and return x. A variable in the unparse rule is a local variable that can be used in the production_code_generator. expr_gen(y) is called with <something2> and returns y. Of note here is a generator call in an unparse rule is passed the element in the position it occupies. Hopefully in the above x and y will be registers on return. The last transforms is intended to load an atomic into a register and return the register.  The first production would be used to generate the 360 "AR" (Add Register) instruction with the appropriate values in general registers. The above example is only a part of a generator. Every generator expression evaluates to a value that con then be further processed. The last transform could just as well have beenr writen as:

               (x)=>     return load(getreg(), x);

In this case load returns it's first parameter, the register returned by getreg(). the functions load and getreg are other CWIC generators.

MOL-360
MOL-360: an independent mid level implementation language  language developed in 1968 and used for writing the underlying support library 

Abstract Parse Tree
The APT (Abstract Parse Tree) is an Abstract Syntax Tree built up is input source code is recognized. It is created by the tree transform operators placed in grammar rules.

Reductive Gramma
Reductive grammar is a set of rules for the analysis of a stream of symbols to determine their meaning and correctness.