CA1223663A

CA1223663A - Language compiler writing system

Info

Publication number: CA1223663A
Application number: CA000481989A
Authority: CA
Inventors: Lawrence E. Larson
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1984-10-24
Filing date: 1985-05-21
Publication date: 1987-06-30
Also published as: JPS61103247A; US4729096A; EP0179334A3; EP0179334A2

Abstract

ABSTRACT OF THE DISCLOSURE

A translator writing system is disclosed for developing a translator program capable of transforming a user's source code into object code. The language of the source code is summarized in a unique form, namely, a Backus-Nauer Form (BNF). This BNF form of the source code is utilized by the translator writing system to transform the source code into object code. The BNF form takes into account the attribute specifications associated with the language of the source code and the interaction of the attribute specifications in the grammar of the language of the source code.
The translator writing system includes a valid testcase generator for testing the developed translator program utilizing every possible correct program statement in the language of the user's source code. The translator writing system further includes an incorrect, invalid testcase generator for testing the developed translator program utilizing every possible incorrect, invalid program statement in the language of the user's source code. As a result, the amount of effort required to test the developed translator program has been significantly reduced.

Description

~r \ J~
~LZi~3~;63 METHOD AND APPARATUS FOR GENE~ATING A TRANSLATOR
PROGR~M FOR A COMPILER/INTERPRETER AND E'OR TESTING 2 SAID TRANSLATOR PRO~RAM 3 Field of the Invention 8 The subject matter of this invention pertains 10 to a computer system, and more particularly, to an 11 apparatus within the computer system for au~omating 12 the generation of translators and test cases needed 13 for the verification and testing of said 14 translators. lS
f Description o~ the Prior Pbr~ 17 CompilPrs and interpreters are utilized by a 19 computer system to transform a set of source code 20 into a set of machine-readable object code. The 21 compilers/interpreters generally comprise a data 22 processing system and a translator program stored in ~3 said system. The data processing system under the 24 control of the accompan-ying translator program 25 receives the user's source code and transforms said 26 code into the machine readable object code. 27 When the translator program is developed, it 29 must be tested. Testing a translator program may 30 require several man-years of testing effort. 31 Translator writing systems have been developed 33 to aid in reducing the amount of time required to 34 develop and test the translator program. These 35 writing systems develop the translator progxam 36 required by the compilers/interpreters. However, 37 the translator writing systems of the prior art 38 possess certain disadvantages. 39 ~-b "~`, 'f EN98402Z ~ 1 ~.~23Çj63 Any set o~ translator software must utilize certain basic rules in per~orming a compilation 2 func~ionO For example, in an operation designated 3 as "A+B*C", it must be determined whether the 4 operation represented by "+" should be per~ormed 5 before or after the operation represented by "*". 6 In making this determination, a set of rules for 7 constructing symbol strings of a programming 8 language shouLd be utilized. This set of rules is 9 known as the grammar of a language. In addition, in 10 the above operation, a semantic analysis determines 11 what particular actions are specified by the 12 operations "+" and "*", that is, semantic analysis 13 determines the meaning of the user's source code. 14 Furthermore, the meaning of a symbol present in a 15 user's source code is expressed by means of its 16 attributes. Among possible attributes are 17 source-text line numbers, type, number of 18dimensions, length of each dimension, internal tree 19 structure, and storage class. For further 20 information on these basic rules utilized by 21 translator softwaxe in performing the compilation 22 function, reference is directed to a book entitled 23 "Assemblers, Compilers, and Program Translation~', by 24 Peter Calingaert, published by Computer Science 25 Press, Inc. 26 Translator programs developed by the translator 28 writing systems of the prior art did not take into 29 account the attribute specifications required by the 30 language of the source code bein~ compiled and did 31 not take into account the interaction of the 32 attribute specifications in the grammar associated 33 with the language of said source code. In addition, 34 it was necessary to manually place 5emantic n,odule 35 invocations, associated with the above-mentioned 36semantic analysis, in the translator program 37 developed by these translator writing systems. 38 Manual placement of the semantic module invocations 39 3~3`

represented a major prob]em. The reason for the major problem is as follows: Translator writiny 2 systems act as compilers themselves, in that an 3 original input grammar undergoes a compilation 4 process producing a transformed grammar. Due to the 5 manual placement of the semantic module invocations 6 in the translator program produced by these writiny 7 systems, there was no way to relate the transformed 8 grammar used by the system to the original input 9 grammar. In addition, once the translator program 10 was developed and stored in its associated data 11 processing sys~em environment, testing of the 12 translator program required a tremendous amount of 13 effort, the amount of effort required beiny measured 14 in terms of man-years of testing effort. 15 It is a primary objec~ of the present invention 19 to provide an improved translator writing system 20 designed to eliminate the disadvantages associated 21 with the translator writing system of the prior art. 22 It is a ~urther object of the present invention 24 to provide an improved translator writing system 25 possessing a novel test case production and testing 26 capabilityO 27 It is a further object of the present invention 29 to provide an improved translator writing system for 30 developing a translator pro~ram in response to a 31 language description representative of the language 32 of the user's source code, the language description 33 being a Backus-Nauer Form (BNF) definition of said 34language. 35 It is a further object of the present invention 37 to provide an improved translator writing system 38 wherein the BNF definition of the language of the 39 ~3~3 user's source code takes into account the attribute specificationS associated with said language and the 2 interaction of the attribute specifications in the 3 grammar o~ said language. 4 ; It is a further object of the present invention 6 to provide an improved translator writing system 7 wherein the BNF definition of said language 8 correctly and automatically places the semantic 9 module invocations in the developed translator 10 program. 11 In accordance with these and other objects of 13 the present invention, an improved translator 14 writing system is provided for developing a 15 translator program in response to a language 16 description representative of the language of a 17 user's source code, the language description being a 18 Backus-Nauer Form (BNF) definition of said language. 19 The translator writing system is characterized by a 20 data processing system and a translator writing 21 program stored in said system for developing the 22 translator program in response to the input language 23 description. The developed translator program is 24 used by a compiler, for example, to transform the 25 usex's source code into corresponding ob~ect code, 26 the ob~ect code being used by a computer system to 27 control-and direct the performance of certain 28 functions defined by said code. The format of the 29 BNF definition of said language is unique, and takes 30 into account certain attribute specifications 31 required by the language of the user's source code 32 and the interaction of the attribute specifications 33 in the grammar associated with the source code. 34 Furthermore, the translator writing system 35 automatically places the semantic module invocations 36 in the developed translator program. In addition, 37 the translator writing system of the present 38 invention further possesses a test case production 39 and interrogation capability. The translator writing system inclucles a data base comprising a 2 complete set of accurate and correct language 3 statements and a complete set OL errOneOI1S
statements. The accurate statements are developed 5 by the translator writing system of the present 6 invention for testing the developed translator 7 program used by said compiler and for analyzing the 8 results produced as a result of the testing. The 9 erroneous statements are develo~ed for testing the 10 developed translator program ~o determine if all of 11 the proper error messages are produced as a result 12 of the testing. The translator writing system 13 includes a translator writing program whlch, in 14 association with its data processing system, 15 produces the translator program used by the 16 compiler/interpreter in response to the BNF 17 definition of the user's source code. 18 Further scope of applicability of the present 20 invention will become apparent from the description 21 given hereinafter. However, it should be understood 22 that the details of the description and the specific 23 examples, while indicating preferred embodiments of 24 the invention, are given by way of illustration 25 only, since various changes and modifications within 26 the spirit and scope of the invention will become 27 apparent to those skilled in the art from the 28 detailed description. 29 A full understanding of the present invention 33 will be obtained from the detailed description given 34 hereinbelow and the accompanying drawings, which are 35 given by way of illustration only, and thus are not 36 limitative of the present invention, and wherein: 37

2~

Figure 1 illustrates a basic bloc]c diagram of a translator writing system including the data 2 processing system and the stored translator ~Jriting 3 program according to the present invention; 4 Figure 2 illustrates a more detailed construction of 6 the translator writing program stored in the data 7 processing system of fig. 1 for developing the 8 translator program, and a compiler/interpreter 9 system stored in the data processing system for 10 utilizing the translator program to create object 11 code from a user's source code, and 12 Figures 3a through 3n and 3p ~hrough 3q illustrate a 14 flow diagram representing the Attributed Translation 15 Backus-Nauer Form (ATBNF) processor portion of the 16 translator writing program of Figure 2, 17 Figures 4a through 4e illustrate a flow diagram 19 representing the code generator portion of the 20 translator wri~ing program of Figure 2; 21 Figure 5 illustrates a flow diagram representing the 23 "good" testcase generator portion of the translator 24 writing program of Figure 2; and 25 . .
Figures 6a through 6b illustrate a flow diagram 27 represehting the "bad" testcase generator portion of 28 the translator writing program of Figure 2. 29 DESCRIPTION OF THE PREFERRED EM~ODIMENT 31 Referring to Figure 1, a translator writing 33 system 10 according to the present invention is 34 illustrated., The translator writing system 10, as 35 set forth in the followiny parayraphs, i5 36 implemented primarily in software. However, the 37 software is utilized by a hardware system to perform 38 the unique function of the present invention. It 39 should be understood, however, that the translator writing system ]0 could be implemented primarlly or 2 completely in hard~are to perform the unique 3 function of the present invention. The translator 4 writing system 10 includes a data processing system 5 and a translator writing program stored within said 6 data processing system. The data processing system 7 includes a system bus, a maln memory 10a connected 8 to the system bus for storing a translator writing 9 program 10al (otherwise termed a compiling machine~ 10 and a compiler/interpreter system 10a2 (otherwise 11 termed a running machine), a processor 10b connected 12 to the system bus, an ATBNF data entry and storage 13 means 10c connected to the system ~us for storing a 1~
Backus-Nauer Form (BNF) definition of the user's 15 source code in software form, a user com~land input 16 means 10d connected to the system bus for entering 17 the user's source code, and a printer 10e connected 18 to the bus for printing a set of results~ A typical 15 data processing system which may be utilized to 20 perform the function of the data processing system 21 described above is set forth in a manual entitled 22 "IBM*System/370 Principles of Operation", developed 23 b~ International Business Machines Corp., CA22-7000. 2~

~eferring to Figure 2, a ~ore detailed 28 construction of the translator writing program 10al 29 of Figure 1 is illustrated. In Figure 2, the 30 translator writing program 10al comprises an ATBNF 31 processor 10alA, a code generator 10alB connected to 32 the processor 10alA, a "good" test case generator 33 10alC connected to the processor 10alA, and a "bad" 3~
test case generator 10alD connected to the processor 35 10alA. 36 As mentioned hereinabove, the user's source 38 code is represented b~ an input language description 39 * Trade mark . ,, .~

~23~fi3 of said source code, that is, by a Backus-Mauer ~orm (BNF) definition or said code. The language of the 2 BNF definition is unique and specific, and is 3 discussed in detail in a book entitled "A Computer 4 Generator" by William McKeeman, James Horning, and 5 David Wortman, published by Prentice Hall. The 6 language of the BNF definition is also discussed in 7 a book entitled "Compiler Construction for Digital 8 Computers" by David Gries, published by John Wiley 9 and Sons, Inc. 10 In Figure 2, the ATBNF data entry and storage 13 means lOc stores the BNF definition of the user's 14 source code in software-program form~ The user's 15source code, per se, is stored in a memory disposed 16 within the user command input means lOd of Figure 2. 17 A compiler (or interpreter) lOa2 receives the user's 18 source code and, in the case of a compiler, 19 transforms the source code into object code, the 20 object code being the "user results" 18 shown in 21 Figure 2. 22 The operation of the invention illustrated in 24 Figures l and 2 will be discussed in the paragraphs 25 below. 26 Refexring collectively to Figures 1 and 2, the 28 ~NF definition of the user's source code is entered 29 into the translator writing system lO via the ATBNF 30 data entry and storage means lOc and is stored 31 within the main memory lOa. The ATBNF processor 32 lOalA, a portion of the translator writing program 33 lOAl, receives the BNF definition and compiles said 34 definition thereby transforming said definitlon into 35 a form readable by the code generator lOalB. As a 36 result, a transformed BNF definition (or a 37 transformed grammar definition) is produced. The 38 code generator lOalB receives the transformed B~F 39 EN98~022 - 8 23~$63 definition from processor lOalA, and produces the translator pxogram. The translator program is 2 stored within the main memor~ lOa and forms a 3 portion of the compiler/interpreter system lOa2. 4 The compiler/ interpreter system lOa2 utilizes said 5 translator program to transform the user's source 6 code, entered via the user command input means lOd, 7 into object code. The object code is represented by 8 the l'user" results 18 of Figure 2. 9 The "good" testcase generator lOalC is 11 essentially a data base containing many example 12 program statements written in the user's source 13 language. The example program statements are 14 written in correct form and therefore represent 15 valid program statements. With respect to the 16 number and type of program statements contained 17 within the data base, every possible correct program 18 statement or language example occurs at least once. 19 The "bad" testcase generator lOalD is also a 21 data base, however, this d~ta base contains many 22 incorrect or otherwise invalid program statements 23 written in the user's source language. ~ith respect 24 to the number and type of program statements 25 contained within this data base, every possible 26 incorrect, invalid program statement or language 27 example occurs at least once. 28 When the translator program is stored within 30 the compiler/interpreter lOa2 portion of the main 31 memory lOa, the ATBNF processor lOalA instructs the 32 "good" testcase generator lOalC to interrogate and 33 test the translator program utilizing the stored 3~
correct program statements. The translator proyram 35 receives the correct program statements and 36 transforms the statements into object code. ~ set 37 of results are produced, illustrated as the "good" 38 results 20 shown in Figure 2 of the drawings. The 39 EN984022 _ 9 ~

~36~;3 user may then analyze the "good" results 20 to ensure that the translator program and the compiler 2 16 are operating properly. 3 The ATBNF processor lOalA then instructs the 5 'Ibad'' testcase generator lOalD to interrogate and 6 test the translator program utilizing the stored, 7 incorrect, invalid proyram statements. The 8 translator program attempts to transform the 9 incorrect program statements into object code. 10 However, in lieu of object ccde, the 11 compiler/interpreter system lOa2 generates a 12 multitude of error messages representative of the 13 invalid, incorrect program statements undergoing 14 compilation, the multitude of error messages being 15 illustrated as the "bad" results 22 in Figure 2 of 16 the drawings. The user may then analyze the "bad" 17 results 22 to ensure that all of the proper error 18 messages are being generated by the compiler lOa2 19 corresponding, respectively, to all of the 20 incorrect, invalid program statements. In this way, 21 it is possible to determine if the translator 22 program and the associated compiler/interpreter 23 system lOa2 are operating properly. 24 In the the following paragraphs, a further, 23 more detailed description of the construction and 29 operation of the translator writing program lOal 30 illustrated in Figures 1 and 2 will be presented. 31 However, in order to fully understand the 32 construction and operation of the translator writing 33 program lOal, it is necessary to understand the 34 meaning of various terms used by the ordinary person 35 skilled in the art of computer systems. 36 When a sentence is diagrammed, the structure or 38 syntax of the sentence is set forth. However, the 39 ~L2;23~3 diagrammed sentence does not set forth the meaning, or semantics, of the sentence itself. Such a 2 syn~actic description of the sentence is called a 3 grammar. ~s a general rule, in the diagrammed 4 sentence, a subject and predicate is utilized. Such 5 a general rule may be described by the following 6 rule which is described by the following 7 mathematical symbology: <sentence> ::= 8 <subject><predicate>, where ::= connotes "may be 9 composed of". The grammar of a sentence may contain 10 more than one such rule. Alternatively, if a 11 similar set of rules are devised (utilizing the 12 format of the above mathematical symbology~, 13 ~escribing a computer la~guage in source code ~orm, 14 these rules may be used to derive or produce the 15 source code of the computer language. These rules 16 are often called productions. The word "symbol" and 17 the word "token" are used synonymously. Each 18 represent an element of a finite, nonempty set of 19 elements. ~ sequence of symbols or tokens is called 20 a string. Given a particular rule of a grammar, 21 symbols appearing as a left part of a rule are 22 called nonterminal symbols. Other symbols are 23 called terminal symbols. For example, in the rule 24 <digit> ::- 3, the nonterminal symbol is "<digit~" 25and the terminal symbol is "3". The nonterminal 26 symbols are recognized by use of the bracket symbol 27 <.. >. If U = x, U = y, and U = z, a more simplified 28 expression may be written to convey the meaning of 29 these equalities: U ::- x ¦ y ¦ z . Utilizing this 30 expression, a grammar for a language may be written 31 in the following form: 32 <number> := <no> 34 <no> ::= <no> ~digit> ¦ <digit> 36 <digit> ::= 0 ¦ 1 ¦ 2 ¦ 3 1 4 1 5 1 38

3~3 The above form of the language is defined to be the Backus-Nauer Form (BNF). The example of numbers 2 above illustrates the need for transformations and 3 data ~ttribute specifications in the grammar 4 definition. As an example, the numbers in sequence 5 "2" and "5" are normally taken to be the number 6 I'25". Similarly, the association is valid only if 7 the characters involved are indeed numeric. Thus, 2 8 followed by 5 would be understood as 25; but, 2 9 followed by Z would not normally be a number 2Z. 10 Additionally, the numbers must be encoded into a 11 form the computer program can process. 12 The attribute information is specified in the 14 grammar definition by using the notation A(numeric) 15 which is a declaration that the data attribute 16 required at this point in the language must be 17 numeric~ 18 The conversion of two characters to a single 20 number recognizable by a computer is specified by 21 F(XXX) where XXX is the name of a routine to do the 22 conversion. The grammar for <number> modified to a 23 processable form becomes: 24 <number~ ::= F(ctr=0) <no> 26 ~no> ::~ <no> F(ctr2=ctr) <digit> A(num) 28 F(ctr=ctr2*10~ctr) ! <digit> A(num) 29 <digit~ ::= "0" F(ctr=0~ F~attr=num) ! "l"F(ctr=1) 31 F(attr=num) ! "2" F(ctr=2) F(attr=num) ! "3" 32 F~ctr=3) F(attr=num) ! "4" F(ctr=4) F(attr=num) ! 33 "5" F(ctr=5) F(attr=num) ! 34 The grammar thus modified is an ATBNF specification 36 of the number grammar that includes both attribute 37 specifications and functional transformation 38 (semantic) information- Note that a computer 39 3~

program is created from the definitlon that the value associated with the numeric character string 2 is in a variable "ctr". 3 For further information regarding the meaning 5 of the a~ove terms, reference is directed to the 6 book entitled "Compiler Construction for Digital 7 Computers"~ by David Gries, published by John Wiley and Sons, Inc. 9 The following represents essential elements o~ 11 the translator writing program lOal comprising the 12 translator writing system 10 of the present 13 invention: 14 (1) An abstract data structure of lists contains the 16 BNF-like language specifications. 1 (2) An abstract data structure of arrays contains 19 the intermediate relations of produces, follows, and 20 ends-with. These structures tell the translator 21writing system how tc produce the generated 22 translator program. 23 (3) An abstract data structure of queues and deques 25 contains the generated code strings for the 26 translator program and for the test cases. 27

(4) An abstract data structure of a stack oriented 29 machine serves as the implementation target of the 30 translator program. 31 The translator writing program lOal functions 33 in the following manner: The translator writing 34 system 10 is gi~en a set of productions representing 35 the BNF definition of the user's source code via the 36 ATBNF data entry and storage means lOc. The 37 productions include a syntax description of the 38 source code, the attributes constraints of the 39 EN984022 - 13 ~

~Z;23~ 3 symbols used in the productions, and the declaration of processing modules to be invoked (semantic 2 information) as the language is processed. The 3 ATBN~ processor lOal~ portion of the translator 4 riting program lOal reduces the complexity of the 5 BNF definition through a combina~ion of lanyuage 6 transformations and statement factoring techniques 7 thereby developing the transformed BNF definition 8 that is simpler to process. This trans~ormation 9 accounts for the presence of attribute and semantic 10 module specifications in the la~guage o~ the user's 11 source code. The simplified productions, consisting 12 of the transformed BNF definition, are read by the 13 code generator lOalB portion of the translator 14 writing program lOal. As a result, production 15 selection values are computed. The selection values 16 uniquely determine the production to be selected, 17 an~ consist of terminal characters in the language 18 and the definition of applicable attribute 19 constraints. The code generator lOalB generates a 20 translator program ~hat will process the user's 21 source code. There are five characteristics of the 22 generated translator program: 23 (1) Each production o~ the translator program 25 results in the creation of a block structured 26 procedure. A return statement, at the end of the 27 procedure, returns control to the invoking program. 28 (2) The production selection values involving 30 language terminals result in the creation of IF 31 statements that test the values in the character 32 string. 33 (3) The production selection values involving data 35 attributes, that must be satisfied as the language 36 is processed, result in the creation of IF 37 statements that test attribute values stored on an 38 attribute stack. 39 i3 (4) The portion of the translator program specifying nonterminals results .in CALLS to procedures having 2 an encoded name related to the production name. 3 l5) The portion of the language specification of the 5 translator program involving semantic routine 6 invocations are converted to CALL invocations of 7 modules to perform the operations specified. 8 After development of the translator program is 10 comple~e, the translator writing program lOal 11 creates two sets of test cases. The first set of 12 testcases, generated by the "good" testcase 13 generator lOalC, consists of those language 14 statements which are valid in the user's source 15 language speci~ied. Because the language involved 16 is normally unbounded in size, the generation 17 process is constrained to ensuring that every 18 language example occurs at least once. This set of 19 test cases is processed by the translator program. 20 If every test run is successful, the generated 21 translator program processes a language that 22 contains t~le specified source language as a subset. 23 The second set of test cases, generated by the "bad" 24 testcase generator lOalD, consists of language 25 statements which are not valid in the specified 26 source language. The testcase generation process is 27 constrained to ensure that every non-language 28example occurs at least once. This set of test 29 cases is processed by the generated translator 30 program. If every testcase in this set is rejected 31 by the translator program, a subset of the specified 32 non-language has been accurately rejected b~ the 33translator program. As a result of the two tests, 34 the translator program implements the speci~ied 35 source language and only the specified language. 36 In order to fully understand the structure and 38 functional operation of the translator writing 39 23~

program lOal, Figures 3a through 6b are provided for illustrating the structure and function of the 2 individual components which comprise the translator 3 writing program lOal, namely, the processor lOalA, the code generator lOalB, the "good" testcase 5 generator lOalC, and the "bad" testcase generator 6 lOalD. 7 Referring to Figures 3a through 3q, a detailed 9 flow diagram is illustrated representing the 10 function of the ATBNF processor lOalA portion of the 11 translator program lOal. In Figure 3a, an overall 12 flow diagram of the processor lOalA portion is 13 illustrated. Flow diagrams representing a further 14 breakdown of the processor lOalA portion of Figure 15 3a are illustrated in Eigures 3b through 3q. In 16 Figure 3a, the processor lOalA portion of the 17 translator writing program lOal functions in the 18 following manner, as indicated by the following 19 sequence of steps: the BNF de~inition of the user's 20 source code is received. As lndicated by block 31, 21 the relations "Corners" and "use" are established. 22 In block 33, Nth order recursions are removed. In 23 block 35, simple recursions are removed. In block 24 37, redundant code strings are removed. In block 25 39, the relation "Production produces" is computed. 26 In block 41, the relation "begins directly with" is 27 built. In block 43a, the transitive closure of BDW 28 is computed. In blocks 45a and 45b, the relations 29 "followed by" and "ends with" are sequentially 30 computed. In block 43b, the relation "end of" is 31-computed. In block 47, the relation "followed by" 32 is sequentially computed. In block 49, production 33 selectors are created. As indicated by block 51, if 34 a conflict exists, instances are computed and the 35 above process is repeated in sequence beginning with 36 the removal of simple recursions. If a conflict 37 does not exist, code is created, that is, the 38 E~984022 - 16 -:LZ;;~ 3 transformed BNF definition of the user's source code is created. 2 In Figure 3b, a flow diagram is illùstrated 4 representing the steps required to establish corners 5 and use, block 31 of Figure 3a, the first of the 6 above-mentioned functional steps associated with the 7 processor 10alA portion of the translator writing 8 program 10al. In Figure 3b, in block 31a, the step 9 "point to first production" is illustrated If all 10 productions are not processed, the steps indicated 11 in blocks 31b are implemented. If all productions 12 are processed, the step "compute transitive closure 13 'used in corner"', block 31c, is implemented. Yn 14 Figure 3c, a flow diagram is illustrated 15 representing the steps required to remove the Nth 16 ordex recursions, block 33 of Figure 3a, the second 17 of the above-mentioned functional steps. In Figure 18 3c, the step "point to first non-terminal" is first 19 implemented, as indicated by block 33d. If all 20 non-terminals are not processed, the steps indicated 21 in blocks 33e are implemented. If all non-terminals 22 are processed, the step "point to first production" 23 is implemented, as indicated by block 33f. If all 24 productions are not processed, the steps indicated 25 by blocks 33g are implemented. If all productions 26 are processed, three subroutines are called-up and 27 implemerted in sequence. The three sub-routines are 28 utilized in the process of removing the Nth order 29 recursions, that is, SORTXFM indicated by block 33a, 30 HOI.DXFM indicated by block 33b, and BUILDUSEC 31-indicated by block 33c. In Figure 3d, the BUILDUSEC 32 subroutine 33c and the SORTXFM subroutine 33a is 33 illustrated in flow-chart form. In Figure 3e, the 34 HOLDXFM subroutine 33b is illustrated in flow chart 35 form. 36 In figure 3e, the HOI,DXFM subxoutine 33b begins 38 by pointing to the first production 33bl. If all 39 ~L~2Z~ 3 productions are processed, end, block 33b2. If all productions are not processed, put production in 2 temporary area, block 33b3. If the production is 3 the required production, put production in the 4 output area, block 33b4 and step to the next 5 production, block 33b5. Repeat steps 33b3, 33b4, 6 and 33b5. If the production is not the required 7 production, but if it is used only one time, skip to 8 step 33b5. If it is not used only one time, point 9 at first production, 33b6, and ask "are all tokens 10 examined?", block 33b7. I~ all tokens are examined 11 and the production is too short, change to P---Null, 12 block 33b8, add result to output area, block 33b9, 13 and skip to step indicated by block 33b5. If the 14 production is not too short, add result to output 15 area, 33b9, and skip to step 33b5. If all tokens 16 are not examined, but the token is used one time, 17 substitute token use with definition, block 33blO, 18 step to next token, block 33bll, and sklp back to 19 block 33b7. If the token is not used one time, skip 20 to block 33bll (step to next token) and then skip to 21 block 33b7. 22 In Figure 3f, a flow diagram is illustrated 2~
representing the steps required to create production 25 selectors, block 49 of Figure 3a, one of the 26 ~unctional steps associated with the processor lOalA 27 portion of the translator writing program lOal. In 28 Figure 3f, the step "point to first production", 29 block 49a, is ~irst implemented. If all productions 30 are processed, the end of the subroutine is reached. 31 If all productions are not processed, the production 32 name and "rightpart" is extracted, block 49b. The 33 step "point at first token of rightpart" is 34 implemented, block 49c. If all tokens are 35 pr~cessed, steps 49d are implemented~ If not, steps 36 49e are implemented. In Figure 3g, a flow diagram 37 is illustrated representing the steps required to 38 compute instances, block 53 of Figure 3a, the step 39 ~L~;~6fi;~

performed if a conflict e~ists associated with the processor lOalA portion of the translator writing 2 program lOal. However, in order to compute 3 instances, three subroutines must be performed. Two 4 of these subroutines, the INSTANCE subroutine 53a 5 and the CHKCONFLICT subroutine 53b, are illustrated 6 in flo~^t-chart form in ~igures 3h and 3i of the 7 drawings, respectively. The other subroutine, 8 SORTXFM 33a, is shown in Figure 3d of the drawings. 9 Referring to figure 3h, th~ INSTANCE subroutine 11 begins by pointing to the first production, block 12 53al. If all productions are processed, end, block 13 53a2. If all productions are not processed, but the 14 production does not have a conflict, put production 15 in the output, block 53a3, step to the next 16 production, block 53a4, and repeat the question "are 17 productions processed?". If the production does 18 have a conflict, find the first non-terminal, block 19 53a5 and, if not found, put production in output, 20 block 53a6, and skip to block 53a4. If found, point 21 to first production, block 53a7. If all productions 22 are examined, skip to block 53a4. If all 23 productions are not examined, and the name of the 24 production is nonterminal, substitute definition, -25 block 53a8, put result in output, block 53a9, and 26 step to the next production, block 53alO. If the 27 name o~ the production is not nonterminal, step to 28 the next production, 53alO. 29 Referring to figure 3i, the CHKCONFLICT 31 subroutine begins by setting 1 to name of first 32 nonterminal, block 53bl. If all nonterminals are 33 e~amined, end, block 53b2. If all are not examined, 34 extract selectors for all occurences of production 35 with name 1, block 53b3. If any terminal is used 36 more than once, add 1 to list of conflict 37 productions, block 53b4, set 1 to name of next 38 nonterminals, block 53b5, and repeat the question 39 ~3~;3 "are all nonterminals examined?". If any terminal is not used more than o~ce, skip to step 53b5. 2 Referrin~ to figure 3j(a), a flow diagram of 4 the RECURS subroutine, step 35 shown in figure 3a, 5 i5 illustrated, this step performing the relation 6 "remove simple recursions". In figure 3j(aJ, block 7 35b indicates to point to the first production. If 8 all productions are processed, point to the first 9 production in the temp list, as indicated by block 10 35c. If all productions are not processed, get the 11 name of the first production, block 35d. If its not 12 left recursive, add the production to the end of the 13 temp list, block 35e, and step to the next 14 production. If the first production is left 15 recursive, but it is not a short production, put the 16 production at the front of the temp list and step to 17 the next production, blocks 35f and 35g. However, 18 if the first production is left recursive and it is 19 a short production, step to the next production, 20 block 35f. Following step 35c, if all productions 21 are processed, exit. If all productions are not 22 processed, remove the production from the templet. 23 If the production is left recursive, get temp name 24 T, block 35h, output production T---AT, output 25 T---null, block 35i, and perform an APPEND 26 subroutine, block 35a, wherein the remaining 27 productions in the temp list are corrected. If the 28 production is not left recursive, add production to 29 the end of output, block 35j, and determine if all 30 productions are processed. 31 Referring to figure 3j(b), the APP~ND 33 subroutine 35a is illustrated. Point to first 34 production, block 35al. If all productions are not 35 processed, name match X, replace with X---AT, and 36 step to the next production, blocks 35a2 and 35a3. 37 If all productions are processed, exit. 38 Referrin~ to figure 3k, a ~low diagram of the ~ACTOR subroutine, step 37 shown in figure 3a, is 2 illustrated, this subroutine performing the "remove 3 redundant code strings" relation. Point to the 4 first production and extract production. If the 5 production is empty, but all productions are not 6 processed, put production in comparison, compare 7 point = Q, and extract production, blocks 37a, 37b, 8 37c, 37d, 37e, and 37f. If production is not empty, 9 and all productions are processed, output comparison 10 and exit, blocks 37g and 37h. If all productions ll ~re not processed, the relation "anything compare" 12 is ~rue, and the relation "same as before" is also 13 true, output T---common part and extract production, 14 blocks 37i, 37j, 37k. If the relation "anything 15 compare" is not true, output comparison and put 16 production in compa~ison, block 37e. If the 17 relation "same as before" is not true, get temp 18 name, output T--common of compare, create unique 19 part of compare---compare, T, output T---common of 20 production, change length of common and extract 21 production, blocks 371, 37m, 37n, 37O, and 37p. 22 Referring to figure 3L, a flow diagram of the 24 subroutine COLLECTOP is illustrated, step 39 shown 25 in figure 3a, wherein the relation "production 26 produces'l is computed. Build initial array of 27 relatio~ "produces". Point to first production~ 28 block 39a. If all productions are processed, 29 compute transitive closure and exit, block 39b. If 30 all productions are not processed, record the named 31 production which produces the first token, step to 32 ne~t production, blocks 39c and 39d. 33 Referring to figure 3N, the subroutine CLOSUR~ 35 is illustrated, steps 43a and 43b shown in figure 36 3a. In these subroutines, the transitive closure of 37 BDW and the relation "end of" are computed. Let Z=X 38 and Y=Z, blocks 43(1] and 43(2). Compute Z=l+X(Y), 39 ~L2~

block 43~3). If Y=Z, exit. If Y is not equal to Z, let Y=Z and repeat steps. 2 Referring to figure 3M, the subroutine 4 suILDsDw~ step 41 shown in figure 3a, is 5 illustrated. This subroutine builds the relation 6 "begins directly with". Point to first production. 7 If all productions are not processed, block 41c, 8 record the named production which produces the first 9 token, block 41a, step to next production, block 10 41b, and repeat step 41c, otherwise exit, block 41d. 11 Referring to figure 3P, the subroutine BUILDEO, 13 step 45(b) shown in figure 3a, is illustrated. This 14 subroutine computes ~he "ends with" relation. In 15 this subroutine, point to the first production. If 16 all productions are not processed, record the named 17 production which ends with the last token, block 18 45(b)1, step to the next production, block 45(b)2. 19 If all productions are processed, exit, otherwise 20 repeat step 45(b~1. 21 Referring to figure 3Q, the subroutine BUILDFB, 23 step 45(a) shown in figure 3a, is illustrated. This 24 subroutine computes the relation "followed by 25 directly". Point to the first production. If all 26 productions are not processed, point at token 27 followihg name, block 45(a)1, and step to the next 28 production if the production is not followed by a 29 token, blocks 45(a)2 and 45(a)3, otherwise record 30 the token followed by successor, step to the next 31 tokenj and repeat step 45(a)2, blocks 45(a)4 and 32 45(a)5. If all tokens are processed, exit. 33 Referring to Figure 4a, an overall flow diagram 35 of the coae generator lOalB portion of the 36 translator writing program lOal is illustrated. The 37 functional step~ comprising this portion of the 38 translator writing program lOal include opening the 39 ~3~63 output ~ile, block 55, closin~ the output ~ile if all productions are processed, block 57, and 2 generating code ~or production if all productions 3 are not processed, block 59. Upon completion of 4 this last step, the output file is closed if all 5 productions are processed. The above-mentioned step 6invol~ing genera~iny code ~or production, bloc]c 59 7 in Figure 4a, is further subdivided into functional 8 steps, as illustrated in ~igure 4b of the drawings. g Referring to figure 4b, if the relation 11 "environment production" is true, endr otherwise if 12 first entry, set not first, blocks 59j, 59k, 59c and 13 59d. If not first entry, and production name prior 14 is true, or when set not ~lrst has been implemented, 15 ask "is recursion involved", block 59e and 59f. If 16 a recursion is involved, output return and proc end, 17 and output proc name. If recursion is not involved, 18 output proc name, blocks 59g and 59h. If goal 19 statement is not true, do GENIF subroutine, then do 20 GENCALL subroutine; however, if goal statement is 21 true, ~o to GENCALL and do GENCALL subroutine, 22 blocks 59i, 59a, and 59b. If prod name prior is not 23 true, block 59e, and recursive production is not 24 true, set print tab replacement and do GENCALL 25 subroutine, blocks 59L, 59m. However, if prod name 26 prior is not true, but recursive production is true, 27 do the `GENCALL subroutine. When the GENCALL 28 subroutine is complete, do the GENELSE subroutine 29 and end, block 59c. 30 Three subroutines are illustrated in Figure 4b, 32 namely, the GENIF subroutine 59a, the GENCALL 33 subroutine 59b, and the GENELSE subroutine 59c. 3~
These subroutines are further subdivided into 35 functional steps, as illustrated in Figures 4c, 4d, 36 and 4e, respectivelyO 37 ~2~3~

Referring to figure 4c, in the GENIF subroutine 59a, e~tract selection characters, block 59al. If a 2 recursion is involved, output do while construct and 3 end, blocks 59a2, 59a3, 59a4. If a recursion is not involved, output if construct, compute tab 5 displacement, and end, blocks 59a5, 59a6, and 59a7. 6 Referring to figure 4e, in the GENELSE 8 subroutine 59c, if a recursion is involved, end, 9 block 59cl and 59c2. If a recursion is not 10 involved, and the relation "goal symbol" is not 11 true, output "else call error", compute new tab 12 displacement, output final return end o~ procedurel 13 and end, blocks 59c3, 59c4, 59c5, 59c6, and 59c7. 14 If the relation "goal symbol" is true, output final 15 return end of procedure and end, block 59c3, 59c6, 16 and 59c7. 17 Referring to figure 4d, in the GENCALL 19 subroutine 59b, if "recursion or goal" is not true, 20 output do construct, and point to first token in 21 production, blocks 59bl, 59b2, and 59b3. If 22 "recursion or goal" is true, point to first token in 23 production, block 59b3. If all tokens are 24 processed, output "if attribute else errer"/ output 25 "end", and end, blocks 59b4, 59b5, 59b6, and 59b7. 26 If all tokens are not processed, and "language 27 terminal" is not true, and attribute test is not 28 true, output call of function and point to the next 29 token, blocks 59b8, 59b9, 59blO, and 59bll. If 30 language terminal is true, output "if char scan else 31 error" and point to the next production, blocks 32 59b8, 59bl2, and 59bll. If language terminal is not 33 true, but attribute test is true, compute tab 34 displacement and point to the next productlon, 35 blocks 59b8, 59b9, 59bl3, and 59bll. Repeat step 36 59b4. 37 ~2~

Referring to Figure 5, an overall flow diagram of the "good" testcase ge}lerator lOalC portlon of 2 the translator writing program lOal is illustrated. 3 The generation of testcases ~epends upon an 5 initialization process that uses the internal data 6 collected describing the language definition. For 7 example, selection values are used to determine 8 which productlon choice is to be used in the run 9 time environment of the compiler/interpreter. In 10 addition, four other data items are created which 11 pertain to productions, namely, a global usage 12 vector (UG) which describes the degree o~ usage 13 during the testcase generation process, a local 14 usage vector (UL) which describes the degree of 15 usage of a production during the generation of a 16 specific testcase instance, a production weight 17 vector (UW) which describes the degree to which a 18 particular production should or should not be used, 19 and a global failure usage vector (UF) which 20 describes the degree to which failure testcases have 21 been created for a particular production. Block 30 22 of Figure 5 represents an initialize step wherein 23 the vectors UG, UL, and UF are initialized to 24 zero(0). 25 Block 32 of Figure 5 requires the computation of 27 values for vector UW. The ATBNF pro¢essor lOalA 28utilizes the vector UW to limit the degree of 29 recursions resulting in replicated testcases, the UW 30 entry for a recursive production being equal to the 31 number of tokens (terminals, nonterminals, 32 attributes, and transformations). Nonrecursive 33 productions are given a UW entry of 1. In this way, 34 the number of testcases cxeated to verify the 35 implementation of a compiler/interpreter is kept to 36 a manageable size7 37 Block 34 requires the invocation of recursive process 5 with <goal> symbol. The successful 2 testcases are created by a recursive process that 3 starts scanning the productions beginning with the 4 <goal> symbol. 5 Block 36 requires scanning productions for symbols. 7 On each recursion, the list o~ all productions is 8 scanned to determlne which of them have matching 9 names. If a matching name cannot be found, an error 10 exists in the BNF language definition and the 11 testcase generation process stops, blocks 37. 12 Block 38 requires locating a first matching 14 production with the lowest global (UG) and lowest 15 local (UL) usage vectors. From the set of 16 productions identified, a production is selected 17 whose global and local usage vectors are a minimum. 18 If there are two such choices, the first encountered 19 is used. 20 Block 40 requires incrementing vector UG and vector 22 UL by the value of vector UW. The global and local 23 usages of the pxoduction are increased by the 24 corresponding entry in the vector UW and the new 25 production is scanned token by token. 26 Block 42 requires initializing the pointer to the 28 first token. If the token is an attribute or 29 transformation, the token is optionally placed in 30 the testcase specification. If the token is a 31 terminal, block 43(1), it is likewise placed in the 32 testcase specification. If the token is a 33 non-terminal, block 43(2), the recursive process is 34invoked using the new token as the starting point. 35 Block 44 requires stepping to the next token. The 37 recursive process of examining tokens and restating 38 scans continues until the end of a production is 39 EN984022 ~ 26 -~ ~3663 xeached. The local usage is reduced and the process r~sumes with the prior reference to the to]cen naming 2 the production. 3 When all recursions of the testcase generation 5 process are ccmpleted, it may happen that all 6 productions may not have used globally. In this 7 case, the testcase process resumes leaving the 8 entries of UG unchanged. This process of e~amining 9 UG and resuming continues until all en~ries of UG 10 are different from zero. 11 The fact that vector UG is nonzero for every 13 entry ensures that every production of the language 14 specification has been used at least once, and, at 15 the same time, ensures that the operating 16 environment for the production will work in the run 17 time environment. 18 Referring to Figures 6a and 6b, flow diagrams 20 of the "bad" testcase generator 10alD portion of the 21 translator writing program 10al are illustrated. 22 In Figure 6a, blocks 46 and 48 require the 24 initialization of vectors UG, UL and UF to zero and 25 the computation of values for UW. These functional 26 steps are the same as the steps associated with 27 blocks~30 and 32 of Figure 5. The comments made 28 above with respect to blocks 30 and 32 of Figure 5 29 apply to blocks 46 and 48 of Figure 6a~ 30 Block 50 requires the invocation of recursive 32 process 13 with the <goal> symbol. The failure 33 testcases are likewise created by a recursive 34 process that starts scanning the productions 3~
beginning with the <goal> symbol. 36 Block 52 requires the scanning of productions for 38 symbols. On each recursion, the list of all 39 ~3 productions is scanned to determine which ones (and options) have a matching name. I f a matching name 2 cannot be found, an error e~ists in the language 3 definition and the testcase generation process 4 stops. 5 Block 54 requires the locating of the first matching 7 production with the lowest global(UG) and the lowest 8 local(UL) usage. From the set of productions 9 identified, a production is selected whose global 10 and local usage is a minimum. If there are two such 11 choices, the first encountered is used. 12 In block 56, a question is asked whether productions 14 UF = 0. The vector representing failures is checked 15 to see if a production of this name has already been 16 used to create a failure case. If not, the vector 17 entry for the production is increased by the usage 18 weight, and a failure test case is created. 19 Block 58 requires the selection of an illegal 21 terminal. The failure testcase is created by 22 determining a character or attribute from the 23 production selectors that cannot occur in the 24 beginning position of the production. If such a 25 character or attribute exists, the character or 26 attribute is appended to an output line as an 27 additional failure testcase. If no such character 28 or attribute exists, the failing state is not 29 reached for this production category. 30 Block 60 requires the addition of UW to UG and UL. 32 The global and local usages of the production are 33 increased by the corresponding entry in the vector 34 UW and the new production is scanned token by token. 35 If the token is a transformation, the token is 36 optionally placed in the testcase specification. 37 3~i63`

In Figure 6b, block 62 requires invocation of process 13 with token. If the token is a 2 ~onterminal, block 61, the recursive process is 3 invoked using the new token as the starting point. 4 Block 6~ requires the selection of any rlonmatching 6 terminal or attribute. When the token is a terminal 7 character or attrihute, block 63, an attribute or 8 character that will induce an error is created~ If 9 the token is an attribute, the output line is 10 created with a valid character following the 11 attributeO 12 . .
Blocks 66 require adding a token to an output area 14 and reducing the vector UL by UWO The recursive 15 process of e~amining tokens and restarting scans16 continues until the end of a production is reached. 17 The local usage is reduced and the process resumes 18 with the prior reference to the token naming the19 production. 20 In Figure 6a, block 68 questions whether any vector 22 UF is zero. When all recursions of the testcase 23 generation process are completed, it may happen that 24 all productions may not have been used globally in 25 the failure testcase creation process (at least one 26 entry of UF is still 0). In this case, the test 27 case process resumes leaving the entries of UF 28 unchanged. The process of examining UF and resuming 29 continues until all entries of UF are different from 30 zero (0). 31 The fact that UF is nonzero for every entry33 ensures that every production of the language 34 specification has been used at least once, that the 35 processor supports only the language as specified, 36 and, at the same time, ensures that the operating 37 environment for the production will wor}; in the run 38 time environment in the presence of error inputs. 39 æ~36~3 With respect to the translator writing system 10 of the present invention, prior art translator 2 writing systems did not account for data attribute 3 specifications or their interactions in the grammar. 4 Prior art systems required manual placement of 5 semantic module invocations and provided no support 6 for the creation of testcases to check out and 7 verify the translator program implemen~ation in its 8 run time ~nvironment. The translator writing system 9 10 of the present invention, inclusive of the 10 translator writing program lOal, is constructed so 11 that is can be readily modified to create a parallel 12 interpreter/executor environment, and it contains 13 enough syntax, semantic, and attribute information 14 about the language in order to enable it to generate 15 application programs and operating systems once 16 their specifications have been transformed into a 17 language speciflcation in BNF form. 18 In the followiny paragraphs, a sample BNF 20 definition of a userls source code is presented. 21 The source language is the language of S~L. A 22 transformed BNF definition of the user's source code 23 is also provided as a result of the functions 24 performed by the ATBNF processor lOalA portion of 25 the translator writing program lOal in response to 26 the BNF definition. A generated translator program 27 is provided as a result of the functions performed 28 by the code generator lOalB portion o the 29 translator writing program lOal in response to the 30 transformed BNF definition. A set of sample llgoodl' 31 testcases are provided below for testing the 32 translator program. A set of sample l'bad" testcases 33 are also provided below for testing the translator 34 program. 35 The following program, illustrated in TABLE 1, 37 sets forth a sample set of language productions 38 ~3`~ 3 represe~ting a BNF defini~ion o~ a user's source code written in the language of SQL: 2 TAsLE 1 4 <goal> ~ query>F(XXXEXGOL) 6 ~QUERY~ ::= 8 <SELECTcL>~FROMCL~F(xxxOPwHR)<wElERECL>F(xXxcLWHR) , 9 ¦ ~SELECT CL><FROMCL> 10 <SELECTCL> ::= 'SELECT'F(XXXOPSEL) '*' 12 F(XXXSTKAS~F~XXXCLSEL) 13 <FROMCL> ::= 'FROM' F(XXXOPFRM)F(XXXSTKTN) 'ID' 15 F(XXXEXF~) 16 <~HERECL> ::= 'WHERE'F(XXXSVEID) 'ID' 18 F(XXXSTKID)F(XXXSTKOP), '=' A-~NUM)F(XXXSTKIN) 'INT' 19 F(XXXPOPOP), ¦ 'WHERE' F(XXXSVEID) 'ID' 20 F(XXXSTKID)F(XXXSTKOP), '=' A(STR)F(XXXSTKQS) 'QST' 21 F(XXXPOPOP) 22 The following program, illustrated in TABLE 2, 24 represents a sample transformed BNF definition of a 25 user's source code, written in the language of SQL, 26 generated by the ATBNF processor 10al of Figure 2, 27 in response to the input sample BNF definition 28 appearing in TABLE 1: 29 <GOAL> ::= 'SELECT' F(XXXOPSEL) '*' F(XXXSTKAS~ 33 F(XXXCLSEL), <T0034035> F(XXXEXGOL) 34 <WHERECL> ::= 'WHERE' F(XXXSVEID) 'ID' F(XXXSTKID) 36 F(XXXSTKOP) '=', <T0031~ 37 <T0034035> ::= 'FROM' F(XXXOPFRM) F(XXXSTKTN) 'ID' F~XXXEXFRM) <T0032> 2 <T0031> ::= A(NUM) E(XXXSTKIN) 'INT' F(XXXPOPOP) 4 <T0031> ::= A(STR) F(XXXSTKQS) 'QST' F(XXXPOPOP) 6 <T0032> ::= '"' <T0032> ::= F(XXXOPWHR) <WHERECL> F(XXXCLWHR) 10 The sample transformed BNF definition 12 illustrated in TABLE 2, generated by the ATBNF 13 processor 10alA, is the input to the code generator 14 10alB. The code generator generates a sample 15 translator program in response to the transformed 16 BNF definition. The sample translator program is 17 illustrated in APPENDIX A. 18 The translator writing program generates a 20 series of sample valid testcases for testing the 21 sample translator program. The sample valid 22 testcases appear in TABLE 3 below~ 23 3L~,~3 SELECT * FROM ID ; 3 SELECT * FROM ID WHERE ID = A(NUM) INT ;5 SELECT * FROM ID ; 7 SELECT * FROM ID WHERE ID = A(STR) QST ;9 The translator writing program generates a 11 series of sample unsuccessful or "bad" testcases for 12 testing the sample translator program. The _ 13 unsuccessful testcases appear in TABLE 4 below: 14 SELECT . 18 SELECT * 20 SELECT* PROM 22 SELECT*~FROM ID 24 SELECT* FROM ID ; 26 SELECT * QST 32 SELECT * FROM OST 34 SELECT * FROM ID QST 36 SELECT * FROM ID ; QST 38 ~3~

SELECT * FROM ID WHERE QST

SELECT * FROM ID WHERE ID QST 3 SELECT * FROM ID WHERE ID = A(BAD) OST 5 SELECT * FROM ID WHERE ID = A(NUM) QST 7 SELECT * FROM ID WHERE ID = A(NUM) INT QST 9 SELECT * FROM ID WHERE ID = A(STR) INT 11 SELECT * FROM ID WHERE ID = A(STR) QST QST 13 SELECT * F~OM ID WHERE ID = A(STR) QST ; QST 15 EN984022 - 3~ -~

~2~

APPENDIX A

Goal: t* PROCEDURE RECURSIVE */ 3 IF NXTSYMB = 'SELECT' 4 THEN CALL XXXSCAN; 5 ELSE CALL XXXERROR; 6 CALL XXXOPSEL; 7 IF NXTSYMB = '*' 8 THEN CALL XXXSCAN; 9 ELSE CALL XXXERROR; lQ
CALL XXXSTKAS; 11 CALL XXXCLSEL; 12 CALL T0034035; ~ 13 CALL XXXEXGOL; 14 RETURN; 15 WHERECL: /* PROCEDURE RECURSIVE */ 20 DO FOREVER /* START OF PRODUCTION WHERECL */ 21 IF (NXTSYMB = 'WHERE') 22 DO; 24 CALL XXXSCAN; 25 CALL XXXSVEID; 26 IF NXTSYMB = 'ID' 27 THEN CALL XXXSCAN; 28 ELSE CALL XXXERROR; 29 CALL XXXSTKID; 30 CALL XXXSTKOP; 31 IF NXTSYMB = '=' 32 THEN CALL XXXSGAN; 33 ELSE CALL XXXERROR; 34 CALL T0031; 35 RETURN; 36 END;

DO; 39 ~P~3~i~3 CALL XXXERROR;
RETURN; 2 END; 3 END; /* END OF PRODUCTION WHERECL */

T0034035: /* PROCEDURE RECURSIVE */ 9 DO FOREVER; /* START OF PRODUCTION T0034035 */ 10 r IF (NXTSYMB = 'FROM') 11 DO; ~ 13 CALL XXXSCAN; 14 CALL XXXOPFRM; 15 CALL XXXSTKTN; 16 IF NXTSYMB = ~ID~ 17 THEN CALL XXXSCAN; 18 ELSE CALL XXXERROR; 19 CALL XXXEXFPM; 20 CALL T0032; 21 RETURN; 22 END; 23 ELSE
DO; 25 CALL XXXERROR; 26 RETURN; 27 END; 28 END; /* END OF PRODUCTION T0034035 */ 29 T0031: /* PROCEDURE RECURSIVE */ 34 DO FOREVER; /* START OF PRODUCTION T0031 */ 35 ~ IF (0~=INDEX( ~ NUM ANY ~¦ATTRIBUTE¦¦~ I )) 36 i THEN 37 DO; 38 CALL XXXSTKIN; 39 EN984022 ~ 36 ~

~ 3 6 ~ 3 IF NXTSYMB = ~INT~
THEN CALL XXXSCAN; 2 ELSE CALL XXXERROR; 3 CALL XXXPOPOP;
RETURN; 5 END; 6 IF (0-=INDEX( STR ANY ~ ATTRIBUTE¦¦~ )) 8 THEN
DO; 10 CALL XXXSTKQS; 11 IF NXTSYMB = ~QSTI 12 THEN CALL XXXSCAN; . 13 ELSE CALL XXXERROR; 14 CALL XXXPOPOP; 15 RETURN; 16 END; 17 ELSE . 18 DO; 19 CALL XXXERROR; 20 RETURN; 21 END; 22 END; /* END OF PRODUCTION T0031 */ 23 T0032: /* PROCEDURE RECURSIVE */ 28 DO FOREVER; /*START OF PRODUCTION T0032 */ 29 IF (NXTSYMB = l;l) 30 DO; 32 RETURN; 33 END; 34 IF (NXTSYMB = 'WHERE') 36 DO; 38 CALL XXXOPWHR; 39 CALL WHERECL;

RETURN;
END; 4 ~O; 6 CALL XXXERROR; 7 RETURN; 8 END; g END; /* END OF PRODUCTION T0032 */ 10 ~2;2~ ;E;3 The invention being thus described, it will be obvious that the same may be varied in many ways. 2 Such variations are not to be regarded as a 3 departure from the spirit and scope of the invention 4 and all such modifications as would be obvious to 5 one skilled in the art are intended to be included 6 within the scope of the following claims. 7

Claims

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A translator writing system for developing a translator program capable of transforming a user's source code into object code, comprising:

means for introducing a program into said translator writing system, said program representing a summary of the pertinent characteristics associated with the user's source code; and developing means responsive to said program for developing said translator program.

2. The translator writing system of claim 1, wherein said summary of the pertinent characteristics associated with the user's source code represented by said program includes a set of attribute specifications associated with the language of said source code, said summary taking into account the interaction of the attribute specifications in the grammar of the language of said source code.

3. The translator writing system of claim 1, wherein said developing means comprises testing means for testing the developed translator program.

4. The translator writing system of claim 3, wherein the testing performed by said testing means comprises an interrogation of said developed translator program with a statement and an analysis of the results achieved as a result of the interrogation, said statement being a member of a data base comprising a plurality of statements.

5. The translator writing system of claim 4 wherein the plurality of statements of said data base represent every possible correct program statement of said user's source code.

6. The translator writing system of claim 5 wherein the plurality of statements of said data base further represent every possible incorrect, invalid program statement of said user's source code.

7. The translator writing system of claim 6, wherein said summary of the pertinent characteristics associated with the user's source code includes a set of attribute specifications associated with the language of said source code, said summary taking into account the interaction of the attribute specifications in the grammar of said language.

8. A translator writing system for developing a translator program capable of transforming a user's source code into object code, comprising:

means for introducing a program into said translator writing system, said program being a summary of the pertinent characteristics associated with the user's source code;

developing mean responsive to said program for developing said translator program, said developing means further including, a valid testcase generator means for testing said translator program utilizing a plurality of valid program statements corresponding to the user's source code, and an incorrect, invalid testcase generator means for testing said translator program utilizing a plurality of incorrect, invalid program statements corresponding to the user's source code, the plurality of valid program statements and the plurality of invalid program statements consisting of every possible valid and invalid program statement, respectively, associated with the user's source code.

9. A method of developing and testing a translator program, comprising the steps of:

developing a summary program summarizing the pertinent characteristics associated with a user's source code; and entering said summary program into a translator writing system, said translator writing system converting said summary program into said translator program and testing said translator program.

10. The method of claim 9, wherein the testing step performed by the translator writing system further comprises the steps of:

interrogating said translator program with every possible correct program statement in the language of said user's source code; and interrogating said translator program with every possible incorrect, invalid program statement in the language of said user's source code.