Abstract:
A compiler compiler system with a design paradigm different from traditional compiler compiler systems in many aspects. First, instead of parsing tree, compiler compiler runtime and binary are designed according to compiler compiler parsing model. Second, any semantics processing is totally separated from syntax processing. Third, the whole compilation process is defined as syntax processing and semantics processing followed by syntax processing performed under compiler compiler management supervision. Fourth, syntax processing has two phases: building compiler compiler runtime, and converting compiler compiler runtime into compiler compiler binary with available option to convert back compiler compiler binary to compiler compiler runtime. Fifth, compiler compiler runtime and binary syntax-controlled APIs are defined in terms of syntax. Sixth, there are formal methods de-compiling compiler compiler runtime and/or binary into original program text accordingly to syntax. Seventh, compiler compiler runtime and binary with their syntax-controlled APIs serve as a multiplatform for obfuscation, security, binary files processing, and program-to-program communication.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    The present invention relates to information technology, and more specifically, to the generation of source code from formal descriptions that can be compiled and linked, creating an executable program. 
         [0002]    In applications performing compiler constructions those formal descriptions are defined in terms of context-free grammars. Such tools take a definition of context-free grammar usually in Backus-Naur Form (BNF) and generate a source code of compiler components; and that compiler is able to process source code according to the input grammar definition. Such tools are called compiler compilers or compiler generators. One of the earliest and still most common form of compiler compiler is a parser generator. In this case, the compiler compiler takes a grammar definition and generates parser source code. Also, a traditional compiler compiler generating parser source code from a grammar specification has another component that takes regular expressions and generates a tokenizer capable of processing specified tokens as a sequence of characters. 
         [0003]    Compiler compilers as parser and tokenizer generators have been implemented since the late 1960&#39;s. 
         [0004]    When a generated parser executes its actions during parsing a source program in accordance with a language grammar, it builds some form of parsing tree. A developer who implements a compiler based on conventional compiler compiler technology is responsible for writing code in terms of a parsing tree and some attributes assigned to parsing tree nodes. 
         [0005]    An ideal compiler compiler is supposed to take an input grammar specification and generate source code in automatic mode without any further manual procedures. Unfortunately this is far from what current information technology can offer in compiler compiler products available for developers. 
       SUMMARY OF THE INVENTION 
       [0006]    According to one embodiment of the present invention, a compiler compiler system includes compiler compiler executable program, compiler compiler management, compiler compiler runtime, compiler compiler binary, compiler compiler generator, compiler compiler source grammar definition language, and compiler compiler parsing model. 
         [0007]    In another embodiment of the present invention, parsing results processing is totally separated from any subsequent semantics processing; parsing results are not represented in the form of any parsing tree; and parsing results are represented in the form of compiler compiler runtime that can be formally converted into/from compiler compiler binary. 
         [0008]    In another embodiment of the present invention, target language defined in compiler compiler source grammar definition language as a source file is compiled by compiler compiler executable program, and a target parser and related source files are generated totally automatically providing to the target compiler a basic set of compile and de-compile operations. 
         [0009]    In another embodiment of the present invention, the compiler compiler runtime and binary have a common compiler compiler parsing model that considers parsing results to be represented in the form of entities such as Context, Name, Symbol, and Rule and their relationships. That model itself is another embodiment of the present invention, i.e., an alternative view to a traditional parsing tree. The compiler compiler runtime implements the model in efficient form required by parser performing create, update, search, and other low level operations in terms of Context, Name, Symbol, and Rule classes and their relationships. The compiler compiler binary implements the model in efficient form providing read only operations having all data allocated in a vector of Tag instances but still is logically equivalent to the compiler compiler runtime. 
         [0010]    In another embodiment of the present invention, a compiler compiler binary is a multiplatform data exchange protocol that allows interaction between programs running on different platforms, running on different operating systems, and built using different programming languages such as C, C++, C#, Java, Objective C, Ruby, Pyton, Perl, and others. 
         [0011]    In another embodiment of the present invention, a compiler compiler system can be used for binary files processing. In this case, a corresponding binary file format has to be designed in the form of compiler compiler source grammar definition language specification. After that, a custom convertor from binary file format into compiler compiler runtime format is implemented. Having a compiler compiler runtime built for a binary file with a given format allows all other compiler compiler phases to work automatically without any extra code development. 
         [0012]    In another embodiment of the present invention, an input compiler compiler binary can be formally transformed using a transformation algorithm into/from an output compiler compiler binary providing generic operations for applications such as obfuscation, security/access control, and content management. The transformation algorithm may be any suitable transformation algorithm typically used for obfuscation, access control, content management, or any other suitable algorithm as appropriate to the application. Consider a credit card account number represented in compiler compiler source grammar definition language as a sequence of digits, each of them represented as an integerToken. Then at the compiler compiler binary level the account number will be represented as a sequence of integerToken tokens. A simple obfuscation algorithm can transform those integerToken token values into different values in the output compiler compiler binary before transmitting output compiler compiler binary over the wire, protecting the account number, with subsequent de-obfuscation on the receiving side. Those algorithms can be changed dynamically also. For security control, compiler compiler binary can be transformed by adding user information with subsequent validation. Consider an audio or video file to be converted into compiler compiler binary. After that conversion, any custom transformations are possible including security control and obfuscation for content protection. Also, any kind of advertising incorporated into compiler compiler binary is possible with programmed options enabling/disabling ads. 
         [0013]    In another embodiment of the present invention, compiler compiler management, generator, runtime and binary source code are compiled into a compiler compiler foundation library that is used in compiler compiler executable program and any other target compiler built by means of a compiler compiler system. 
         [0014]    In another embodiment of the present invention, for any compiler compiler source grammar language description, the compiler compiler executable program generates code that is compiled into a generated library and a target compiler executable program is compiled and built with the compiler compiler foundation library and generated library. Built this way, the target compiler executable program has default compile and de-compile operations ready. All semantics processing can be done as independent subsequent operations implemented using a compiler compiler binary application programming interface (API). 
         [0015]    In another embodiment of the present invention, the compiler compiler source grammar definition language is defined using the same source grammar definition language that allows a bootstrapping method to be used for implementing compiler compiler executable program using itself. In other words, the compiler compiler generated code for a given meta grammar description is compiled into a generated library and a newly created compiler compiler executable program is compiled and built with compiler compiler foundation library and generated library. Built this way, the newly created compiler executable program has compile and de-compile operations ready. All semantics processing in this case is done as a code generation for parser and related generated source files implemented using compiler compiler binary API. If the abbreviation CCSGDL stands for compiler compiler source grammar definition language, then meta grammar is CCSGDL for CCSGDL. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  shows a prior art compiler compiler such as YACC or GNU BISON. 
           [0017]      FIG. 2  shows compiler compiler system phases according to the invention for building the compiler compiler itself. 
           [0018]      FIG. 3  shows compiler compiler system phases according to the invention for building a target compiler. 
           [0019]      FIG. 4  shows target compiler phases when a target compiler is built by a compiler compiler system according to the invention. 
           [0020]      FIG. 5  shows a UML diagram of compiler compiler management classes such as Shell, Compiler, Parser, and other related classes and their relationships. 
           [0021]      FIG. 6  shows a UML diagram of compiler compiler management KeyWordsContainer class. 
           [0022]      FIG. 7  shows a UML diagram of a compiler compiler management Parser class and its relationships with other classes. 
           [0023]      FIG. 8  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime class. 
           [0024]      FIG. 9  shows a UML diagram of a compiler compiler runtime MapVectorContainer template class. 
           [0025]      FIG. 10  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::ContextContainer inner class based on a MapVectorContainer template class. 
           [0026]      FIG. 11  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::Context inner class and its relationships with SyntaxControlledRuntime::NameContainer and SyntaxControlledRuntime::SymbolContainer inner classes. 
           [0027]      FIG. 12  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::NameContainer inner class based on a MapVectorContainer template class. 
           [0028]      FIG. 13  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::Name inner class. 
           [0029]      FIG. 14  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::SymbolContainer inner class based on a MapVectorContainer template class. 
           [0030]      FIG. 15  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::Symbol inner class. 
           [0031]      FIG. 16  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::RuleContainer inner class based on MapVectorContainer template class. 
           [0032]      FIG. 17  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime::Rule inner class. 
           [0033]      FIG. 18  shows a UML diagram of a compiler compiler runtime SyntaxControlledRuntime class and its inner classes with their relationships regardless of the implementation details of the containers. 
           [0034]      FIG. 19  shows a UML diagram of compiler compiler binary SyntaxControlledBinary class and its inner classes with their relationships. 
           [0035]      FIG. 20  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinaryContext class and other SyntaxControlledBinary inner classes with their relationships. 
           [0036]      FIG. 21  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinaryContextHeader class. 
           [0037]      FIG. 22  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinarySymbol class. 
           [0038]      FIG. 23  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinaryRule class. 
           [0039]      FIG. 24  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinaryRuleDefinition class. 
           [0040]      FIG. 25  shows a UML diagram of a compiler compiler management TypeInstance class. 
           [0041]      FIG. 26  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary::BinaryHelper class. 
           [0042]      FIG. 27  shows a UML diagram of a compiler compiler management Tokenizer class and its relationships with LineReader, Language, and TokenNameContainer classes. 
           [0043]      FIG. 28  shows a UML diagram of a compiler compiler management TokenNameContainer class. 
           [0044]      FIG. 29  shows a UML diagram of a compiler compiler management Language class and its relationships with related classes. 
           [0045]      FIG. 30  shows a UML diagram of a compiler compiler management Tokens class and its relationships with related classes. 
           [0046]      FIG. 31  shows a UML diagram of a compiler compiler management Token class hierarchy. 
           [0047]      FIG. 32  shows a UML diagram of a compiler compiler generator Generator class and its relationships with related classes. 
           [0048]      FIG. 33  shows a UML diagram of a compiler compiler generator GeneratorBinary class and its relationships with related classes. 
           [0049]      FIG. 34  shows a UML diagram of a compiler compiler generator GeneratorRuntime class and its relationships with related classes. 
           [0050]      FIG. 35  shows a UML diagram of a target compiler&#39;s child classes derived from GeneratorBinary and GeneratorRuntime classes. 
           [0051]      FIG. 36  shows target compiler standard and transformation phases performed in a multiplatform environment when a compiler compiler system builds a target compiler. 
           [0052]      FIG. 37  shows binary files processing based on a compiler compiler system performing standard and transformation phases in a multiplatform environment. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0053]      FIG. 1  shows an example of a prior art compiler compiler system. A compiler executable program  107  is a final step here and it is done as a compiling and linking of a compiler code  106  that consists of compiler source files  105 , generated compiler parser, and generated compiler tokenizer. The generated compiler parser is an output of executing parser generator  104  having input file for parser generator  103 . The generated compiler tokenizer is an output of executing a tokenizer generator  102  having input file for tokenizer generator. 
         [0054]    The input file for parser generator  103  contains a grammar definition in the form of a few sections such as implementation language declarations, compiler compiler declarations, compiler compiler grammar rules specification, and additional implementation language code. For YACC and GNU BISON the implementation language is C language. 
         [0055]    The compiler compiler grammar rules specification is a sequence of individual grammar rules. Each grammar rule is defined as a non-terminal on the left side and a potentially empty sequence of terminals and non-terminals on the right side followed by actions. The grammar rule actions are specified as implementation language code with additional features the compiler compiler can understand and convert into implementation language code during generation. Those additional features are related to attributes attached to parsing tree nodes. Usually those attributes have a prefix ‘$’ and the compiler compiler acts like a specialized preprocessor that for each rule finds all occurrences of ‘$’ and generates corresponding implementation language code based on compiler compiler executing environment rules for processing parsing results. 
         [0056]    For each grammar rule specified actions are executed every time the parser recognizes that the rule is supposed to be invoked during parsing. 
         [0057]    The input file for the tokenizer generator mainly consists of language tokens definitions in the form of token name and token regular expression specifying a valid set of characters comprising the token. 
         [0058]    To summarize, the prior art compiler compiler system model forces a compiler developer to define compilation tasks in the form of individual grammar rule actions for the isolated parsing tree context identified with the given rule invocation. As a result, when parsing is done a parsing tree is built along with a custom environment implemented by the compiler developer. Subsequent compilation phases followed by parsing are implemented in terms of that parsing tree and custom environment. 
         [0059]      FIG. 2  shows the present invention compiler compiler system phases for building itself. A compiler compiler executable program  205  takes compiler compiler source grammar definition language source text defining itself (meta grammar)  201  and performs a phase  2 . 1   a  generating compiler compiler runtime  202  for meta grammar  201 . Compiler compiler executable program  205  has an option to de-compile meta grammar generated compiler compiler runtime  202  into a text file (not shown) containing meta grammar executing phase  2 . 1   b . This newly de-compiled meta grammar as a text is identical to meta grammar  201  except for some differences related to supported indentation rules. 
         [0060]    Compiler compiler executable program  205  for meta grammar  201  performs phase  2 . 2   a  generating compiler compiler binary  203  for compiler compiler runtime  202 . The phase  2 . 2   a  is implemented as a formal procedure that converts compiler compiler runtime  202  into compiler compiler binary  203 . Compiler compiler executable program  205  has an option to de-compile meta grammar from generated compiler compiler binary  203  into a text file (not shown) containing meta grammar executing phase  2 . 2   c . This newly de-compiled meta grammar as a text is identical to meta grammar  201  except for some differences related to supported indentation rules. Compiler compiler executable program  205  has an option to re-create a compiler compiler runtime that is identical to original compiler compiler runtime  202  having compiler compiler binary  203  executing phase  2 . 2   b.    
         [0061]    Compiler compiler executable program  205  performs phase  2 . 3  creating a compiler compiler generated code  204  corresponding to meta grammar  201 . The compiler compiler source grammar definition language consists of a grammar name section followed by a sequence of rules where the first rule is also a grammar axiom. As used herein, the grammar name section consists of a single identifier that defines a name of grammar. As an example, when C++ compiler compiler executable program  205  takes the following meta grammar source file: 
         [0000]                                                (meta        (grammar ::=             0 =“ METAACTBEG( );”=             ‘(’ grammarNameDef               { rule }             ‘)’             0 =“ METAACTEND( );”=       )       (grammarNameDef ::=  identifier       )       (rule ::=   ‘(’ nterm ‘::=’ right ‘)’       )       (nterm   ::=  identifier       )       (right ::=  { element }       )       (element ::=   identAlt | alternative | identMiss | iteration | action       )       (action   ::=  integerToken ‘=’ { stringToken } ‘=’       )       (actions ::= ‘=’ { action } ‘=’       )       (identAlt ::= ntermtermact { Altpart }       )       (Altpart ::=  ‘|’ ntermtermact       )       (ntermtermact  ::=   ntermterm [ actions ]       )            (ntermterm   ::=   nterm | termToken       )       (alternative   ::=   ‘(’ identAlt ‘)’       )       (identMiss   ::=   ‘[’ identAlt ‘]’       )       (iteration   ::=   ‘{’ iterItemact iterItems ‘}’       )       (iterItems   ::=   { altIterItem }       )       (altIterItem   ::=   ‘|’ iterItemact       )       (iterItemact   ::=   iterItem [ actions ]       )       (iterItem   ::=   nterm | maybeNterm       )            (maybeNterm  ::=  ‘&lt;’ nterm ‘&gt;’       )       )                    
as a result of phase  2 . 3  the following C++ source files are generated:
 
         [0062]    metaGenerator.h 
         [0063]    metaKeyWordDefinition.h 
         [0064]    metaParser.h 
         [0065]    metaGenerator.cc 
         [0066]    metaKeyWordDefinition.cc 
         [0067]    metaParser.cc 
         [0068]    metaMakeGenerators.cc 
         [0000]    Note, that the ‘meta’ prefix in file names corresponds to the grammar name—the first section identifier in source grammar definition language. Note also that 
       0=“METAACTBEG( );”= 
     0=“METAACTEND( );”= 
       [0069]    are used as a special macro substitution actions defined in form of integer number followed by sequence of string literals enclosed in ‘=’ and ‘=’. Further elements and rules are explained in the following paragraphs. 
         [0070]    The compiler compiler source grammar definition language elements such as ‘(’ and ‘)’ are grammar terminals defined as a string literal with enclosed single quotes. 
         [0071]    The compiler compiler source grammar definition language element such as 
         [0000]    {rule}
 
is BNF extension called iteration meaning that enclosed by { and } non-terminal is actually may occur zero or any other number of times.
 
Note, that, e.g., rule
 
         [0000]                                            (iterationExample ::= { element } )                        
is equivalent to rules
 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 (iterationExample ::= element iterationExample ) 
               
               
                   
                 (iterationExample ::= ) 
               
               
                   
                   
               
             
          
         
       
     
         [0072]    The compiler compiler source grammar definition language rule 
         [0000]                                            (rule ::=   ‘(’ nterm ‘::=’ right ‘)’            )                        
defines rule as a terminal ‘(’ followed by non-terminal nterm followed by terminal ‘::=’ followed by non-terminal right followed by terminal ‘)’.
 
         [0073]    The compiler compiler source grammar definition language rule 
         [0000]                                            (nterm   ::=  identifier           )                        
defines non-terminal nterm as identifier.
 
         [0074]    The compiler compiler source grammar definition language rule 
         [0000]                                            (right ::=  { element }           )                        
defines non-terminal right as an iteration of element non-terminals.
 
         [0075]    The compiler compiler source grammar definition language rule 
         [0000]                                (element ::=   identAlt | alternative | identMiss | iteration | action       )                    
defines non-terminal element as an alternative of non-terminals on the right side of rule definition separated by ‘|’. The alternative is BNF extension similar to iteration extension; it is used in cases when non-terminal on the left side of rule definition can be one of non-terminals from the right side. Note, that, e.g., rule
 
(alternativeExample::=A|B|C|Z)
 
is equivalent to rules
 
(alternativeExample::=A)
 
(alternativeExample::=B)
 
(alternativeExample::=C)
 
(alternativeExample::=Z)
 
         [0076]    The compiler compiler source grammar definition language rule 
         [0000]                                            (action   ::=  integerToken ‘=’ { stringToken } ‘=’           )                        
defines non-terminal action as an integerToken followed by terminal ‘=’ followed by iteration of stringToken followed by terminal ‘=’. Here integerToken and stringToken are another compiler compiler source grammar definition language reserved key words similar to identifier. integerToken defines token that holds integer value. stringToken defines token that holds string literal value as an arbitrary sequence of any characters enclosed with double quotes, i.e., “.
 
         [0077]    The compiler compiler source grammar definition language rule 
         [0000]                                            (actions ::= ‘=’ { action } ‘=’           )                        
defines non-terminal actions as a iteration of action enclosed with ‘=’.
 
         [0078]    The compiler compiler source grammar definition language rule 
         [0000]                                            (identAlt ::= ntermtermact { Altpart }           )                        
defines non-terminal identAlt as a ntermtermact followed by iteration of Altpart non-terminals.
 
         [0079]    The compiler compiler source grammar definition language rule 
         [0000]                                            (Altpart ::=  ‘|’ ntermtermact           )                        
defines non-terminal Altpart as a terminal ‘|’ followed by non-terminal ntermtermact.
 
         [0080]    The compiler compiler source grammar definition language rule 
         [0000]                                            (ntermtermact ::=  ntermterm [ actions ]           )                        
defines non-terminal ntermtermact as a non-terminal ntermterm followed by [actions] meaning that non-terminal actions may be omitted. Non-terminal enclosed with [ and ] is another compiler compiler source grammar definition language BNF extension representing elements that can be omitted. Note, that, e.g., rule
 
         [0000]                                            (ommitedElementExample ::= A [ W ])                        
is equivalent to rules:
 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 (ommitedElementExample ::= A Welement ) 
               
               
                   
                 (Welement::= W ) 
               
               
                   
                 (Welement::= ) 
               
               
                   
                   
               
             
          
         
       
     
         [0081]    The compiler compiler source grammar definition language rule 
         [0000]                                            (ntermterm ::=  nterm | termToken           )                        
defines non-terminal ntermterm as an alternative of nterm of term Token. nterm is defined above.
 
termToken is another compiler compiler source grammar definition language reserved key word that defines terminal token specification as a string literal enclosed with single quotes.
 
         [0082]    The compiler compiler source grammar definition language rule 
         [0000]                                            (alternative ::=  ‘(’ identAlt ‘)’           )                        
defines non-terminal alternative as an identAlt enclosed with terminals ‘(’ and ‘)’.
 
         [0083]    The compiler compiler source grammar definition language rule 
         [0000]                                            (identMiss ::=  ‘[’ identAlt ‘]’           )                        
defines non-terminal identMiss as an identAlt enclosed with terminals ‘[’ and ‘]’.
 
         [0084]    The compiler compiler source grammar definition language rule 
         [0000]                                            (iteration ::=  ‘{’ iterItemact iterItems ‘}’           )                        
defines non-terminal iteration as an iterItemact followed by non-terminal iterItems enclosed with terminals ‘{’ and ‘}’.
 
         [0085]    The compiler compiler source grammar definition language rule 
         [0000]                                            (iterItems ::=  { altIterItem }           )                        
defines non-terminal iterItems as an iteration of altIterItem non-terminals.
 
         [0086]    The compiler compiler source grammar definition language rule 
         [0000]                                            (altIterItem ::=  ‘|’ iterItemact           )                        
defines non-terminal altIterItem as terminal ‘|’ followed by non-terminal iterItemact.
 
         [0087]    The compiler compiler source grammar definition language rule 
         [0000]                                            (iterItemact ::=  iterItem [ actions ]           )                        
defines non-terminal iterItemact as non-terminal iterItem followed by [actions].
 
         [0088]    The compiler compiler source grammar definition language rule 
         [0000]                                            (iterItem  ::=  nterm | maybeNterm           )                        
defines non-terminal iterItem as an alternative of non-terminals nterm and maybeNterm.
 
         [0089]    The compiler compiler source grammar definition language rule 
         [0000]                                            (maybeNterm  ::=  ‘&lt;’ nterm ‘&gt;’           )                        
defines non-terminal maybeNterm as non-terminal nterm enclosed between terminals ‘&lt;’ and ‘&gt;’. The compiler compiler source grammar definition language iteration is actually defined as a sequence of terminals or non-terminals may be followed by actions, and also non-terminals may be enclosed between terminals ‘&lt;’ and ‘&gt;’ meaning that such non-terminal is allowed to be in iteration only zero or one time. Note, that, e.g., the rule
 
         [0000]                                            (anotherIterationExampe :: = { A | B | &lt;X&gt; | &lt;Z&gt; } )                        
is equivalent to the rules
 
         [0000]                                            (anotherIterationExampe :: = elem anotherIterationExampe )           (anotherIterationExampe :: = )           (elem ::= A | B | X | Z )                        
with the limitation that X and Z are allowed to be defined zero or one times only.
 
         [0090]    If phase  2 . 5  is performed for newly compiler compiler generated code corresponding to meta grammar  204 , then a new default version of compiler compiler executable program  205  is created with default ‘metaGenerator.cc’ that has empty implementation. When that default version of compiler compiler executable program  205  is running it has all phase  2 . 1   a , phase  2 . 1   b , phase  2 . 2   a , phase  2 . 2   b , and phase  2 . 2   c  available to be executed. 
         [0091]    The phase  2 . 3  is actually implemented in the ‘&lt;prefix&gt;Generator.cc’ file. In case of the C++ compiler compiler system mentioned above, seven files are created automatically without any manual intervention from the developer, not only for meta grammar but also for any other grammar defined in the compiler compiler source grammar definition language. In other words, compiler compiler semantics processing is performed by phase  2 . 4  and it is done by the ‘&lt;prefix&gt;Generator.cc’ file. That code is actually implemented on top of the generated initial default version. 
         [0092]      FIG. 3  shows compiler compiler system phases for building a target compiler. Compiler compiler executable program  205  takes compiler compiler source grammar definition language source text defining target language grammar  301  and performs phase  3 . 1   a  generating compiler compiler runtime  302 . Compiler compiler executable program  205  has an option to de-compile target language grammar from generated compiler compiler runtime  302  into a text file containing compiler compiler source grammar definition language source text defining target language grammar executing phase  3 . 1   b . This newly de-compiled target language grammar as a text is identical to target language grammar  301  except for some differences related to supported indentation rules. 
         [0093]    Compiler compiler executable program  205  performs phase  3 . 2   a  generating compiler compiler binary  303  for target language grammar compiler compiler runtime  302 . The phase  3 . 2   a  is implemented as a formal procedure that converts compiler compiler runtime  302  into compiler compiler binary  303 . Compiler compiler executable program  205  has an option to de-compile target language grammar from generated compiler compiler binary  303  into a text file containing compiler compiler source grammar definition language source text defining target language grammar executing phase  3 . 2   c . This newly de-compiled target language grammar as a text is identical to target language grammar  301  except for some differences related to supported indentation rules. Compiler compiler executable program  205  has an option to create compiler compiler runtime  302  having compiler compiler binary  303  executing phase  3 . 2   b.    
         [0094]    Compiler compiler executable program  205  performs phase  3 . 3  creating compiler compiler generated code  304  corresponding to target language grammar  301  directly from  303 . When C++ compiler compiler executable program  205  takes target language grammar source file  301  the following C++ source files are generated: 
         [0095]    &lt;Prefix&gt;Generator.h 
         [0096]    &lt;Prefix&gt;KeyWordDefinition.h 
         [0097]    &lt;Prefix&gt;Parser.h 
         [0098]    &lt;Prefix&gt;Generator.cc 
         [0099]    &lt;Prefix&gt;KeyWordDefinition.cc 
         [0100]    &lt;Prefix&gt;Parser.cc 
         [0101]    &lt;Prefix&gt;MakeGenerators.cc 
         [0000]    Note, that the &lt;Prefix&gt;prefix in file names corresponds to the grammar name—the first section identifier in source grammar definition language. 
         [0102]    If phase  3 . 5  is performed for newly compiler compiler generated code corresponding to target language grammar  304 , then a new default version of target language compiler executable program  305  is created with a default ‘&lt;Prefix&gt;Generator.cc’ that has empty implementation. When that default version of target language compiler executable program  305  is running, it has all phase  3 . 1   a , phase  3 . 1   b , phase  3 . 2   a , phase  3 . 2   b , and phase  3 . 2   c  available to be executed. The phase  3 . 3  is actually implemented in ‘&lt;Prefix&gt;Generator.cc’ file corresponding to target language grammar  301 . In the case of the C++ compiler compiler system mentioned above, seven files are created automatically without any manual intervention from the developer, not only for meta grammar but also for any other grammar defined in the compiler compiler source grammar definition language. In other words, compiler compiler semantics processing is performed by phase  3 . 4 , and it is done by the ‘&lt;Prefix&gt;Generator.cc’ file corresponding to the target language compiler. That code is implemented on top of the generated initial default version with no manual actions. So, phase  3 . 3  performs the same steps as phase  2 . 3 , but phase  3 . 4  is related to semantics processing of the target language compiler. 
         [0103]      FIG. 4  shows phases of target language compiler executable program  305 . When the target language compiler executable program  305  takes target language source text in accordance with target language grammar  401  its parser goes through phase  4 . 1   a  creating a compiler compiler runtime  402  corresponding to target language grammar  401 . In accordance with  FIG. 3  target language compiler executable program  305  is built with the same set of operations as the compiler compiler executable program  205  shown in  FIG. 2 . The target language executable program  305  has an option to de-compile source program from generated compiler compiler runtime  402  into a source text file in accordance with target language grammar executing phase  4 . 1   b . This newly de-compiled source text is identical to original target language grammar source text  401  except for some differences related to supported indentation rules. 
         [0104]    Target language compiler executable program  305  performs phase  4 . 2   a  generating compiler compiler binary  403  for compiler compiler runtime  402 . Phase  4 . 2   a  is implemented as a formal procedure that converts compiler compiler runtime  402  into compiler compiler binary  403 . Target language compiler executable program  305  has an option to de-compile source text from generated compiler compiler binary  403  into a source text file in accordance with target language grammar  401  executing phase  4 . 2   c . This newly de-compiled target language source text is identical to original target language source text  401  except for some differences related to supported indentation rules. The target language compiler executable program  305  has an option to create compiler compiler runtime  402  having compiler compiler binary  403  executing phase  4 . 2   b.    
         [0105]    The target language compiler executable program  305  performs phase  4 . 3 , a target compiler semantics processing  404  based on compiler compiler binary  403 . 
         [0106]    To summarize  FIG. 2 ,  FIG. 3 , and  FIG. 4 , compiler compiler management, generator, runtime and binary source code are compiled into a compiler compiler foundation library that is used when compiler compiler executable program compiles compiler compiler source grammar definitions and when target compiler executable program compiles target language programs. 
         [0107]      FIG. 5  shows a Unified Modeling Language (UML) diagram of compiler compiler management classes such as Logger, Shell, Compiler, Parser, and other related classes and their relationships. Logger class is defined for logging any activities performed during compilation/de-compilation. Shell class is defined for interacting with main routine performing compilation/de-compilation operations. Given Shell instance maintains a container of Compiler instances. Shell instance allocates Logger instance. Compiler class is defined for performing compilation/de-compilation operations under Shell control. Action abstract base class is defined for compilation/de-compilation interface to be instantiated inside Compiler. ActionCompile and ActionDecompile are classes derived from Action class to perform compilation/de-compilation operations. KeyWordsContainer class is defined to maintain set of names related to grammar such as predefined key word, tokens, key words, non-terminals. This class is instantiated inside Compiler instance. Parser class defines generic class as a parent for all generated parser classes for given grammar. This class is instantiated inside Compiler instance. IRun defines common interface in form of abstract class for Shell, Compiler, and Action classes. The compiler compiler executable program source code contains main function implementation by instantiating Shell with provided program arguments and executing run method of Shell instance. 
         [0108]      FIG. 6  shows a UML diagram of compiler compiler management KeyWordsContainer class. It has inner type KeyWordsContainer::NameVector defined as std::vector&lt;std::string&gt;. KeyWordsContainer data members are of KeyWordsContainer::NameVector type; they are predefined_, tokens_, keyWords_, and nonTerminals_. So, all grammar symbol names are categorized into those four groups, the last one for grammar non-terminals, while the first three divide grammar terminals into predefined tokens such as identifier, integerToken, etc. . . . , tokens as sequences of any characters, and tokens as reserved key words. 
         [0109]      FIG. 7  shows a UML diagram of compiler compiler management Parser class and its relationships with other classes. Parser class is derived from abstract class IParser that has few methods for compilation from file source with/without listing and from string source with/without listing. Parser class has references to Logger and KeyWordsContainer actually instantiated by Shell class and propagated to Parser through Compiler. Parser class has data members context_ and axiom_ of type Tag defined in C++ version at some namespace as follows: 
         [0000]    
       
         
               
               
             
               
               
               
             
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 #ifdef_CPPCC_TAG_32BITS —   
               
             
          
           
               
                   
                 typedef unsigned long 
                 UnsignedTag; 
               
               
                   
                 typedef long  Tag; 
               
               
                   
                 typedef float 
                 Real; 
               
               
                   
                 struct TypeInstance { 
               
               
                   
                  UnsignedTag 
                 symbolID:10; 
               
               
                   
                  UnsignedTag 
                 ruleID:22; 
               
               
                   
                 }; 
               
               
                   
                 #else 
               
               
                   
                 typedef unsigned long long 
                 UnsignedTag; 
               
               
                   
                 typedef long long 
                 Tag; 
               
               
                   
                 typedef double 
                 Real; 
               
               
                   
                 struct TypeInstance { 
               
             
          
           
               
                   
                  UnsignedTag 
                 symbolID:16; 
               
               
                   
                  UnsignedTag 
                 ruleID:48; 
               
               
                   
                 }; 
               
               
                   
                 #endif 
               
               
                   
                   
               
             
          
         
       
     
         [0110]    Along with Tag, UnsignedTag, Real, and TypeInstance are defined the same way. For 32 bit computer architecture all those types occupy a four-byte word; for 64 bit computer architecture all those types occupy an eight-byte word. TypeInstance instance in many cases is represented as a Tag value with subsequent fields packing/unpacking operations. 
         [0111]    The Parser class instantiates some simple data members such as file name as a string class instance, as well as Boolean flags such as debugging flag, XML token indicator flag, etc. . . . shown in  FIG. 7 . 
         [0112]    The Parser class shown on  FIG. 7  also instantiates other important members such as runtime_ of type SyntaxControlledRuntime, a binary_ of type SyntaxControlledBinary, a tokenizer of type Tokenizer_, and a generator_ of type Generator. 
         [0113]      FIG. 8  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime class. This class has currentContext_ data member of type Tag, debug_ and optimizationMode_flags of type int, and contexts_ of type SyntaxControlledRuntime::ContextContainer. The purpose of SyntaxControlledRuntime class is to define syntax-controlled runtime API as a collection of its methods and methods of inner classes and their relationships designed in accordance with compiler compiler parsing model. 
         [0114]    As described in the following paragraphs with reference to  FIGS. 9-18 , the compiler compiler runtime syntax-controlled API, including various inner classes, is designed to perform the following set of operations to be invoked from any parser generated by compiler compiler system: 
         [0115]    Create new ‘Context’ instance returning ‘ContextID’. 
         [0116]    Create new ‘Rule’ instance for the current ‘Context’ instance having ‘SymbolID’, returning ‘Tag’ instance actually mapped to ‘TypeInstance’ class instance with packed ‘symbolID’ and ‘ruleID’. 
         [0117]    Return ‘Symbol’ instance reference for the current ‘Context’ instance having ‘SymbolID’. 
         [0118]    Return ‘Rule’ instance for the current ‘Context’ instance having ‘Tag’ instance actually mapped to ‘TypeInstance’ class instance with packed ‘symbolID’ and ‘ruleID’. 
         [0119]    Modify ‘Rule’ instance dynamic part for the current ‘Context’ instance having ‘Rule’ instance reference and vector reference representing dynamic part. 
         [0120]    Modify ‘Rule’ instance fixed part for the current ‘Context’ instance having ‘Rule’ instance reference and vector reference representing fixed part. 
         [0121]    Create identifier representation having string representing identifier and returning identifier index. 
         [0122]      FIG. 9  shows a UML diagram of compiler compiler runtime MapVectorContainer template class. This template class is designed to support different SyntaxControlledRuntime containers that are defined as SyntaxControlledRuntime inner types instantiating MapVectorContainer template class with different SyntaxControlledRuntime inner classes. In many compilation tasks a sequence of objects must be identified by object name or sequentially by sequential number in accordance with objects definition. 
         [0123]    Consider a definition like this: 
         [0000]    int z, a, b, w;
 
If a compiler builds a map from a string representing object name to object instance, then it would be easy and efficient to manipulate those objects by finding them by name. However, the original order of z, a, b, w would disappear since in the map they are ordered differently. MapVectorContainer is designed to provide both effective operations by name and preserving original sequence in the way objects were originally defined having direct access by name (object key) and by index (object sequential number).
 
         [0124]    On  FIG. 9  MapVectorContainer template class takes two formal arguments, &lt;D&gt; representing object type and &lt;K&gt; representing object key type. MapVectorContainer defines three inner types such as MapVectorContainer::Map, MapVectorContainer::Vector, and MapVectorContainer::Data. The MapVectorContainer::Map type is defined as std::map&lt;K, Tag&gt;. The MapVectorContainer::Vector Map type is defined as std::vector&lt;K&gt;. MapVectorContainer::Data type is defined as std::vector&lt;D&gt;. MapVectorContainer template class instantiates name2index_instance of type MapVectorContainer::Map, index2name_instance of type MapVectorContainer::Vector, and index2data_instance of type MapVectorContainer::Data. 
         [0125]      FIG. 10  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::ContextContainer inner class based on MapVectorContainer template class. SyntaxControlledRuntime::ContextContainer inner class is MapVectorContainer template class instance with arguments K=Tag and D=SyntaxControlledRuntime::Context. 
         [0126]      FIG. 11  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::Context inner class and its relationships with SyntaxControlledRuntime::NameContainer and SyntaxControlledRuntime::SymbolContainer inner classes. SyntaxControlledRuntime::Context has data members contextID_ of type Tag, names_ of type SyntaxControlledRuntime::NameContainer, and symbols_ of type SyntaxControlledRuntime::SymbolContainer. 
         [0127]      FIG. 12  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::NameContainer inner class based on MapVectorContainer template class. SyntaxControlledRuntime:: NameContainer inner class is MapVectorContainer template class instance with arguments K=std::string and D=SyntaxControlledRuntime::Name. 
         [0128]      FIG. 13  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::Name inner class having contextID_data member of type Tag and name_data member of type std::string. 
         [0129]      FIG. 14  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::SymbolContainer inner class based on MapVectorContainer template class. SyntaxControlledRuntime::SymbolContainer inner class is MapVectorContainer template class instance with arguments K=Tag and D=SyntaxControlledRuntime::Symbol. 
         [0130]      FIG. 15  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::Symbol inner class having contextID_and symbolID_data members of type Tag and rules_data member of type SyntaxControlledRuntime:: RuleContainer. 
         [0131]      FIG. 16  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::RuleContainer inner class based on MapVectorContainer template class. SyntaxControlledRuntime:: RuleContainer inner class is MapVectorContainer template class instance with arguments K=Tag and D=SyntaxControlledRuntime::Rule. 
         [0132]      FIG. 17  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime::Rule inner class class having contextID_, symbolID_, and ruleInstanceID_data members of type Tag and fixed_ and dynamic_data members of type std::vector&lt;Tag&gt;. 
         [0133]      FIG. 18  shows a UML diagram of compiler compiler runtime SyntaxControlledRuntime class and its inner classes with their relationships regardless containers implementation details. Actually  FIG. 18  defines compiler compiler runtime logical view as a collection of individual context. Logically each compiler compiler runtime context maintains its own collection of names ordered alphabetically or by sequential number with direct access by name or sequential number. 
         [0134]    Logically each compiler compiler runtime context maintains its own collection of symbols ordered by symbolID with direct access by symbolID. 
         [0135]    Logically each compiler compiler runtime symbol maintains its own collection of rules representing each rule invocation during parsing for a given symbol. 
         [0136]    Actually, compiler compiler runtime logical view and compiler compiler binary logical view are the same since compiler compiler runtime and compiler compiler binary are interchangeable. However, compiler compiler runtime is designed to be an effective environment for processing parsing results during parsing itself, and compiler compiler binary is designed to be an effective environment for processing final parsing results in read only mode serving as a multiplatform interchange format. 
         [0137]    In other words,  FIG. 18  shows one form of compiler compiler parsing model with entities such as Context, Name, Symbol, and Rule with their relationships. 
         [0138]    As described in the following paragraphs with reference to  FIGS. 19-26 , the compiler compiler binary syntax-controlled API, including various inner classes, is designed to perform the following set of operations to be invoked from any application responsible for any semantics processing based on compiler compiler system: 
         [0139]    Get const pointer to ‘SyntaxControlledBinary::Context::BinaryHeader’. 
         [0140]    Get pointer to ‘SyntaxControlledBinary::Context::BinaryHeader’. 
         [0141]    Get identifier as a const char* having its sequential number. 
         [0142]    Get identifier as a const char* having its alphabetic number. 
         [0143]    Get identifier sequential number having its alphabetic number. 
         [0144]    Get pointer to ‘SyntaxControlledBinary::Context::BinarySymbol’ having symbol sequential number. 
         [0145]    Get pointer to ‘SyntaxControlledBinary::Context::BinarySymbol’ having ‘SymbolID’. 
         [0146]    Get pointer to char having offset in ‘memory_’ data member. 
         [0147]    Get const pointer to char having offset in ‘memory_’ data member. 
         [0148]    Return aligned size of anything to ‘Tag’ size with given initial size. 
         [0149]    Get pointer to ‘SyntaxControlledBinary::Context::BinaryRule’ having ‘SyntaxControlledBinary::Context:: BinarySymbol’ instance pointer and rule instance number given for that symbol. 
         [0150]    Populate ‘SyntaxControlledBinary::Context::BinaryRuleContent’ by its reference having ‘SyntaxControlledBinary::Context:: BinarySymbol’ instance pointer and ‘SyntaxControlledBinary::Context::BinaryRule’ instance pointer. 
         [0151]    Get rule fixed part as a pointer to ‘Tag’ having ‘SyntaxControlledBinary::Context::BinaryRule’ instance pointer. 
         [0152]    Get rule fixed part as a reference to ‘TypeInstance’ having ‘SyntaxControlledBinary::Context::BinaryRule’ instance pointer and rule instance number. 
         [0153]    Get rule dynamic part as a pointer to ‘Tag’ having ‘SyntaxControlledBinary::Context::BinaryRule’ instance pointer. 
         [0154]    Get rule dynamic part as a reference to ‘TypeInstance’ having ‘SyntaxControlledBinary::Context::BinaryRule’ instance pointer and rule instance number. 
         [0155]    Write binary into file having file name. 
         [0156]    Read binary from file having file name. 
         [0157]      FIG. 19  shows a UML diagram of a compiler compiler binary SyntaxControlledBinary class and its inner classes with their relationships. SyntaxControlledBinary class has contexts_ of type SyntaxControlledBinary::BinaryContextContainer, i.e., SyntaxControlledBinary is a collection of individual binary contexts each of them is represented by inner class SyntaxControlledBinary::BinaryContext. 
         [0000]    SyntaxControlledBinary::BinaryContextContainer is defined as std::map from Tag to SyntaxControlledBinary::BinaryContext. 
         [0158]      FIG. 20  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinaryContext class and other SyntaxControlled Binary inner classes with their relationships. SyntaxControlledBinary::BinaryContext class has only one data member, memory_ that is of type std::vector&lt;Tag&gt; meaning that SyntaxControlledBinary::BinaryContext is represented as a raw memory where SyntaxControlledBinary::BinaryContextHeader, SyntaxControlledBinary::BinarySymbol, SyntaxControlledBinary::BinaryRule class instances are actually allocated. 
         [0159]    SyntaxControlledBinary shown in  FIG. 19  can be converted into a single binary object specified by the following Backus-Naur Form (BNF): 
         [0000]    (1) SyntaxControlledBinary::=header catalog elements
 
(2) header::=headerSize headerTotal headerCatalogOffset headerElementsOffset
 
(3) headerSize::=integerToken
 
(4) headerTotal::=integerToken
 
(5) headerCatalogOffset::=integerToken
 
(6) headerElementsOffset::=integerToken
 
(7) catalog::={catalogElement}
 
(8) catalogElement::=catalogElementContextID catalogElementOffset catalogElementSize
 
(9) catalogElementContextID::=integerToken
 
(10) catalogElementOffset::=integerToken
 
(11) catalogElementSize::=integerToken
 
(12) elements::=SyntaxControlledBinaryContext)
 
       (13) SyntaxControlledBinaryContext::= 
       [0160]    BinaryContextHeader 
         [0161]    BinaryContextSequentialNames 
         [0162]    BinaryContextAlphabeticalNames 
         [0163]    BinaryContextNames 
         [0164]    BinaryContextSymbols 
         [0165]    BinaryContextRules 
         [0166]    BinaryContextRuleElements 
       (13.1) BinaryContextHeader::= 
       [0167]    BinaryContextHeaderLength 
         [0168]    BinaryContextHeaderCurrent 
         [0169]    BinaryContextHeaderAxiom 
         [0170]    BinaryContextHeaderNumberOfIdentifiers 
         [0171]    BinaryContextHeaderStartOfIdentifiersMap 
         [0172]    BinaryContextHeaderNumberOfSymbol 
         [0173]    BinaryContextHeaderStartOfSymbols 
         [0000]    (13.1.1) BinaryContextHeaderLength::=integerToken
 
(13.1.2) BinaryContextHeaderCurrent::=integerToken
 
(13.1.3) BinaryContextHeaderAxiom::=integerToken
 
(13.1.4) BinaryContextHeaderNumberOfIdentifiers::=integerToken
 
(13.1.5) BinaryContextHeaderStartOfIdentifiersMap::=integerToken
 
(13.1.6) BinaryContextHeaderNumberOfSymbol::=integerToken
 
(13.1.7) BinaryContextHeaderStartOfSymbols::=integerToken
 
       (13.2) BinaryContextSequentialNames::={BinaryContextSequentionalNameOffset} 
       [0174]    (13.2.1) BinaryContextSequentionalNameOffset::=integerToken 
       (13.3) BinaryContextAlphabeticalNames::=BinaryContextAlphabeticalName) 
     (13.3.1) BinaryContextAlphabeticalName::= 
       [0175]    BinaryContextAlphabeticalNameOffset 
         [0176]    BinaryContextAlphabeticalNameID 
         [0000]    (13.3.1.1) BinaryContextAlphabeticalNameOffset::=integerToken
 
(13.3.1.2) BinaryContextAlphabeticalNameID::=integerToken
 
       (13.4) BinaryContextNames::=BinaryContextNameAligned 
       [0177]    (13.4.1) BinaryContextNameAligned::=stringToken 
       (13.5) BinaryContextSymbols::=BinaryContextSymbol 
     (13.5.1) BinaryContextSymbol::= 
       [0178]    BinaryContextSymbolNumberOfRuleInstances 
         [0179]    BinaryContextSymbolID 
         [0180]    BinaryContextSymbolStart 
         [0000]    (13.5.1.1) BinaryContextSymbolNumberOfRuleInstances::=integerToken
 
(13.5.1.2) BinaryContextSymbolID::=integerToken
 
(13.5.1.3) BinaryContextSymbolStart::=integerToken
 
       (13.6) BinaryContextRules::={BinaryContextRule} 
     (13.6.1) BinaryContextRule::= 
       [0181]    BinaryContextRuleFixed 
         [0182]    BinaryContextRuleDynamic 
         [0183]    BinaryContextRuleStart 
         [0000]    (13.6.1.1) BinaryContextRuleFixed::=integerToken
 
(13.6.1.2) BinaryContextRuleDynamic::=integerToken
 
(13.6.1.3) BinaryContextRuleStart::=integerToken
 
       (13.7) BinaryContextRuleElements::={BinaryContextRuleElement} 
     (13.7.1) BinaryContextRuleElement::= 
       [0184]    BinaryContextRuleElementFixed\BinaryContextRuleElementDynamic 
         [0000]    (13.7.1.1) BinaryContextRuleElementFixed::=integerToken
 
(13.7.1.2) BinaryContextRuleElementDynamic::=integerToken where memory_data member of SyntaxControlledBinary::BinaryContext class is represented by rule (13) SyntaxControlledBinaryContext. Note, that this BNF is extended by special extensions such as iteration when some non-terminal is enclosed with ‘{’ and ‘}’ meaning that that non-terminal can occur zero or unlimited number of times; alternative when some non-terminals are separated by ‘|’ meaning that one of them can occur; ‘integerToken’ is used to represent 4 bytes integer or 8 bytes integer; ‘stringToken’ is used to represent string literal properly aligned. So, BinaryContextRuleElements::={BinaryContextRuleElement} is equivalent to
 
       BinaryContextRuleElements::=BinaryContextRuleElement BinaryContextRuleElements BinaryContextRuleElements::= 
     So, 
     BinaryContextRuleElement::= 
       [0185]    BinaryContextRuleElementFixed\BinaryContextRuleElementDynamic 
         [0000]    is equivalent to 
       BinaryContextRuleElement::=BinaryContextRuleElementFixed 
     BinaryContextRuleElement::=BinaryContextRuleElementDynamic 
       [0186]      FIG. 21  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinaryContextHeader class. It is a struct that has the following fields of type Tag: size_, axiom_, numberOfNames_, startOfNames_, numberOfSymbols_, and startOfSymbols_. The instance of this struct is actually allocated inside SyntaxControlledBinary::BinaryContext memory_data member. 
         [0187]      FIG. 22  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinarySymbol class. It is a struct that has the following fields of type Tag: numberOfRuleInstances_, symbolID_, and symbolStart_. The instances of this struct are actually allocated inside SyntaxControlledBinary::BinaryContext memory_ data member. 
         [0188]      FIG. 23  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinaryRule class. It is a struct that has the following fields of type Tag: fixedSize_, dynamicSize_, and ruleStart_. The instances of this struct are actually allocated inside SyntaxControlledBinary::BinaryContext memory_data member. 
         [0189]      FIG. 24  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinaryRuleDefinition class. It is a struct that has the following fields of type TypeInstance*, pointer to TypeInstance: fixed_ and dynamic_. This struct is an auxiliary type that is not actually allocated inside SyntaxControlledBinary::BinaryContext memory_data member, it has two pointers fixed_ and dynamic_ for fixed and dynamic rule parts actually allocated inside SyntaxControlledBinary::BinaryContext memory_data member. 
         [0190]      FIG. 25  shows a UML diagram of compiler compiler management TypeInstance class. The description of  FIG. 7  also has a definition of TypeInstance class. Its fields symbolID_ and ruleID_ are actually packed fields that form 4- or 8-byte word depending on the computer architecture. 
         [0191]      FIG. 26  shows a UML diagram of compiler compiler binary SyntaxControlledBinary::BinaryHelper class. This class is an auxiliary type that is not actually allocated inside SyntaxControlledBinary::BinaryContext memory_data member. This class implements SyntaxControlledBinary logical view similar to  FIG. 18 . SyntaxControlledBinary::BinaryHelper class has references to SyntaxControlledBinary and SyntaxControlledBinary::BinaryContextHeader, binary_ and header_ respectively. Also it has data members nameByIndex_ and nameByID_ of type std::vector&lt;const char*&gt;, nameIndex2ID_ of type std::vector&lt;Tag&gt;, symbols_ of type std::vector&lt;SyntaxControlledBinary::BinaryHelper:Symbol&gt;. The nameByIndex_ represents all context names ordered sequentially. The nameByID_ represents all context names ordered alphabetically. The nameIndex2ID_ represents mapping from alphabetic order to sequential order. The symbols_ represents a vector container of all context symbols with individual elements of type SyntaxControlledBinary::BinaryHelper::Symbol. The SyntaxControlledBinary::BinaryHelper::Symbol has a pointer reference to SyntaxControlledBinary::BinarySymbol instance as symbol_ member, data member rules_ of type std::vector&lt;SyntaxControlledBinary::BinaryHelper:Rule&gt;. The SyntaxControlledBinary::BinaryHelper::Rule has a pointer reference to SyntaxControlledBinary::BinaryRule instance as rule_ member. 
         [0192]      FIG. 27  shows a UML diagram of compiler compiler management Tokenizer class and its relationships with LineReader, Language, and TokenNameContainer classes. The Tokenizer class has references logger_ to Logger, grammarSymbols_ to KeyWordsContainer, and parser_ to Parser. The Tokenizer class instantiates an instance of TokenNameContainer as grammarSymbols_member. The Tokenizer class instantiates LineReader as reader_ and Language as language_. 
         [0193]    The LineReader class is an abstract base class. The FileLineReader and StringLineReader classes are derived from LineReader. The FileLineReader class provides implementation for reading source text of compiled program from a file, it also maintains the corresponding listing as a file. The StringLineReader class provides implementation for reading source text of compiled program from a std::string as a sequence of lines separated by a given delimiter, it also maintains the corresponding listing. Any other line reader classes can be implemented as derived from LineReader abstract base class. 
         [0194]    The LineReader class comprises the following pure virtual functions or their equivalents: 
         [0195]    ‘get’ returning argument by reference, the next line as a string to be processed by ‘Tokenize’. 
         [0196]    ‘put’ having const reference to string to be put into listing by ‘Tokenizer’. 
         [0197]    boolean ‘hasListing’ returning true if listing is maintained. 
         [0198]    boolean ‘isEof’ indicating end of source lines to be processed. 
         [0199]    ‘start’ having file name and listing file name. 
         [0200]    ‘start’ having const reference to string to be processed as a sequence of lines and boolean flag if listing is required. 
         [0201]    The Language class is an abstract base class. The LanguageMeta and LanguageXML classes are derived from the Language class. The LanguageMeta class implements tokens set and Language interface for compiler compiler source grammar definition language. The LanguageXML class implements tokens set and Language interface for XML type of languages. 
         [0202]      FIG. 28  shows a UML diagram of compiler compiler management TokenNameContainer class. It has a data member tokenNames_ of type TokenNameContainer::TokenNameMap defined as std::map&lt;std::string, std::string&gt;. 
         [0203]      FIG. 29  shows a UML diagram of compiler compiler management Language class and its relationships with related classes. The Language is an abstract base class derived from abstract base class ILanguage that consists of a set of pure virtual functions defining its interface. The Language class has a reference tokenizes to Tokenizer class. The Language class has a data member tokenizerSet_ of enumeration (a.k.a. enum) type LanguageTokenizerSet. The Language class instantiates three instances such as tokens_, keyWords_, and nonTerminals_ of type Tokens. 
         [0204]    The ‘Language’ abstract class comprises the following pure virtual functions or their equivalents from the set of functions defining the ILanguage interface: 
         [0205]    ‘getCharacter’ populating ‘Tokenizer’ ‘currentCharacter’. 
         [0206]    ‘getIdentifier’ populating ‘Tokenizer’ ‘currentIdentifier’ and ‘currentKeyWord’. 
         [0207]    ‘getNumeric’ populating ‘Tokenizer’ ‘currentDoubleValue’ or ‘currentIntegerValue’ depending on token value, and ‘Tokenizer’ ‘currentKeyWord’. 
         [0208]    ‘getString’ populating ‘Tokenizer’ ‘currentStringValue’ and ‘currentKeyWord’. 
         [0209]    ‘getNextToken’ populating ‘Tokenizer’ next token and ‘currentKeyWord’. 
         [0210]    In addition, the ‘Language’ class comprises generic functions common to all languages as derived classes from the ‘Language’ class; those generic functions are: 
         [0211]    ‘populateTerminals’ populating ‘SymbolID’ for each token defined in ‘terminalTokens_’, ‘terminalKeyWords_’, and ‘nonTerminals_’. 
         [0212]    ‘isDefinedToken’ returning true or false depending on check of all tokens defined in ‘terminalTokens_’ if that token matches the sequence of characters starting from ‘Tokenizer’ ‘currentCharacter’. 
         [0213]    ‘isKeyWord’ returning true or false depending on check if a given formal parameter is defined in corresponding name to index container of ‘terminalKeyWords_’. 
         [0214]    ‘setNextToken’ setting ‘Tokenizer’ ‘currentKeyWord’ by performing loop for each token size ‘k’ starting from maximum size while ‘k’ greater than zero reducing ‘k’ by one 
         [0000]    by performing loop for each token ‘t’ in ‘terminalTokens_’
 
checking if ‘k’ equals to token ‘t’ size and token ‘t’ is Token predicate is true then executing token ‘t’ ‘flushToken’ function (see description of the Token class below); setting ‘Tokenizer’ ‘currentKeyWord’ as token ‘t’ ‘SymbolID’.
 
         [0215]    ‘getToken’ having a formal argument as an input with token ‘SymbolID’ returning corresponding reference to ‘Token’ class instance. 
         [0216]    ‘skipToken’ having a first formal argument as an input with token ‘SymbolID’ and a second formal argument as an output with token reference to ‘Tag’ actually mapped to ‘TypeInstance’ class instance with token ‘SymbolID’ and token ‘RuleID’; performing call to ‘getToken’ with the first formal argument as an input with token ‘SymbolID’ getting reference ‘t’ to ‘Token’ class instance; performing call to method ‘skipToken’ with the first formal argument as an input with token ‘SymbolID’ and the second formal argument as an output with token reference to ‘Tag’; performing call to ‘getNextToken’. 
         [0217]    ‘getTerminalString’ setting ‘Tokenizer’ ‘currentTerminalStringValue’ and related ‘Tokenizer’ data members processing sequence of input characters enclosed with single quotes representing language defined terminal as a sequence of characters enclosed with single quotes. 
         [0218]      FIG. 30  shows a UML diagram of compiler compiler management Tokens class and its relationships with related classes. The Tokens class has data members name2index_of type Tokens::Name2IndexMap and tokens_of type Tokens::TokenVector. The type Tokens::Name2IndexMap is defined as std::map&lt;std::string, int&gt; mapping token name to token index for getting access to Token in tokens_container. The type Tokens::TokenVector is defined as std::vector&lt;Token*&gt; and it will be replaced by std::vector&lt;std::shared_ptr&lt;Token&gt;&gt; when std::shared_ptr will be widely available as C++ standard library class. 
         [0219]    The Token class is an abstract base class that is derived from abstract base class IToken that consists of a set of pure virtual functions defining its interface. The Token class has a reference tokenizer— to Tokenizer class instance. The Token class has a data member symbol_ that is actually corresponds to SymbolID of Symbol related to the given Token. The Token class has data members token_ and name_ of std::string type. 
         [0220]    The ‘Token’ class comprises pure virtual functions or their equivalents from the set of pure virtual functions defining the IToken interface, such as: 
         [0221]    ‘isToken’ predicate returning true or false depending on if ‘Tokenizer’ sequence of characters starting from ‘Tokenizer’ ‘currentCharacter’ matches given token ‘token_’ data member. 
         [0222]    ‘flushToken’ checking if ‘isToken’ predicate returns true, then advancing ‘Tokenizer’ ‘currentCharacter’ to the next one beyond the given token sequence of characters; and executing ‘Tokenizer’ ‘flushBlanks’ function skipping white space characters such as blank, tabulation, etc. 
         [0223]      FIG. 31  shows a UML diagram of compiler compiler management Token class hierarchy. The OneCharToken, TwoCharToken, ThreeCharToken are derived from Token class abstract class implementing its interface. The OneCharXMLGreaterThanToken is derived from OneCharToken providing custom implementation of ‘&gt;’ token in case of XML type of languages. 
         [0224]      FIG. 32  shows a UML diagram of compiler compiler generator Generator class and its relationships with related classes. The Generator class is derived from IGenerator abstract base class that consists of a set of pure virtual functions or their equivalents defining its interface, such as: 
         [0225]    ‘decompileRuntime’ having file name as a formal argument where runtime content is de-compiled. 
         [0226]    ‘decompileBinary’ having file name as a formal argument where binary content is de-compiled. 
         [0227]    ‘generateFromRuntime’ having file name as a formal argument that is used to generate output based on runtime content. 
         [0228]    ‘generateFromBinary’ having file name as a formal argument that is used to generate output based on binary content. 
         [0229]    The Generator class implements IGenerator interface; i.e., implements the foregoing functions or their equivalents. The Generator class has a reference parser_ to the Parser instance. The Generator class has a data member tokenizerSet_ of enumerated type LanguageTokenizerSet. The Generator class instantiates runtime_ as GeneratorRuntime* and binary_ as GeneratorBinary*. Pointer to GeneratorRuntime, GeneratorRuntime*, and Pointer to GeneratorBinary, GeneratorBinary*, will be replaced by std::shared_ptr&lt;GeneratorRuntime&gt; and 
         [0000]    std::shared_ptr&lt;GeneratorBinary&gt; when std::shared_ptr will be widely available as C++ standard library class. The GeneratorBinary class is a base class derived from IBinaryGenerator abstract base class that consists of a set of pure virtual functions defining its interface. The GeneratorRuntime class is a base class derived from IRuntimeGenerator abstract base class that consists of a set of pure virtual functions defining its interface. 
         [0230]      FIG. 33  shows a UML diagram of compiler compiler generator GeneratorBinary class and its relationships with related classes. The GeneratorBinary class is a base class derived from IBinaryGenerator abstract base class that consists of a set of pure virtual functions defining its interface. The GeneratorBinary class has a reference generator_ to Generator class instance. The GeneratorBinary class instantiates style_ data member of type GeneratorBinary::GeneratorBinaryStyle* that will be replaced by std::shared_ptr&lt;GeneratorBinary::GeneratorBinaryStyle&gt; when std::shared_ptr will be widely available as C++ standard library class. The GeneratorBinary::GeneratorBinaryStyle is an abstract base class that is derived from IBinaryGeneratorStyle that consists of a set of pure virtual functions defining its interface. The GeneratorBinary::GeneratorBinaryStyleMeta and GeneratorBinary::GeneratorBinaryStyleXML classes are derived from GeneratorBinary::GeneratorBinaryStyle abstract base class. 
         [0231]    The IBinaryGenerator abstract base class consists of the following pure virtual functions or their equivalents: 
         [0232]    makeAlignment having formal argument token as a reference to Token returning void; 
         [0233]    decompile having formal argument filename as a const reference to string returning void. 
         [0234]    generate having formal argument filename as a const reference to string returning void. 
         [0235]    The IRuntimeGenerator abstract base class consists of the following pure virtual functions or their equivalents: 
         [0236]    makeAlignment having formal argument token as a reference to Token returning void; 
         [0237]    decompile having formal argument filename as a const reference to string returning void; 
         [0238]    generate having formal argument filename as a const reference to string returning void. 
         [0239]    The IRuntimeGeneratorStyle abstract base class consists of the following pure virtual functions or their equivalents: 
         [0240]    makeAlignment having formal argument token as a reference to Token returning void. 
         [0241]    The IBinaryGeneratorStyle abstract base class consists of the following pure virtual functions or their equivalents: 
         [0242]    makeAlignment having formal argument token as a reference to Token returning void. 
         [0243]      FIG. 34  shows a UML diagram of compiler compiler generator GeneratorRuntime class and its relationships with related classes. The GeneratorRuntime class is a base class derived from IRuntimeGenerator abstract base class that consists of a set of pure virtual functions defining its interface. The GeneratorRuntime class has a reference generator_ to Generator class instance. The GeneratorRuntime class instantiates style_ data member of type GeneratorRuntime::GeneratorRuntimeStyle* that will be replaced by std::shared_ptr&lt;GeneratorRuntime::GeneratorRuntimeStyle&gt; when std::shared_ptr will be widely available as C++ standard library class. The GeneratorRuntime::GeneratorRuntimeStyle is an abstract base class that is derived from IRuntimeGeneratorStyle that consists of a set of pure virtual functions defining its interface. The GeneratorRuntime::GeneratorRuntimeStyleMeta and GeneratorRuntime::GeneratorRuntimeStyleXML classes are derived from GeneratorRuntime::GeneratorRuntimeStyle abstract base class. 
         [0244]      FIG. 35  shows a UML diagram of target compilers child classes derived from GeneratorBinary and GeneratorRuntime classes. Target compiler related classes such as metaFirstGeneratorBinary, metabootGeneratorBinary, xsdGeneratorBinary, and similar are derived from GeneratorBinary class. Target compiler related classes such as metaFirstGeneratorRuntime, metabootGeneratorRuntime, xsdGeneratorRuntime, and similar are derived from GeneratorRuntime class. 
         [0245]      FIG. 36  shows built by compiler compiler system target compiler standard and transformation phases performed in multiplatform environment. This  FIG. 36  is similar to  FIG. 4  with additional elements. The phase  36 . 1   c  is a transformation of input compiler compiler runtime into output compiler compiler runtime. This type of transformation could be obfuscation, security protection, or content management. The phase  36 . 1   d  is a back transformation of output compiler compiler runtime into input compiler compiler runtime. The compiler compiler binary  3603  could be transmitted or received by  3605  in a binary format to/from other program. Those two sides of program to program communication can be implemented in different platforms, different operating systems, and different programming languages. 
         [0246]      FIG. 37  shows binary files processing based on compiler compiler system performing standard and transformation phases in multiplatform environment.  FIG. 37  is similar to  FIG. 36 . It shows an idea of converting any binary file into compiler compiler runtime. This can be done in form of designing binary file format in term of compiler compiler source grammar definition language. A custom binary file format convertor is required that loads binary file content into compiler compiler runtime. Having compiler compiler runtime built all other operations of  FIG. 37  are available for free. 
         [0247]    While the invention has been described with respect to certain preferred embodiments, as will be appreciated by those skilled in the art, it is to be understood that the invention is capable of numerous changes, modifications and rearrangements and such changes, modifications and rearrangements are intended to be covered by the following claims.