Patent GB-1372430-A (GB)
Title: Process for producing a microprogramme or a soft interpreter for  a computer
IPC: G06F9/06
Filed: 1972-05-22
Abstract: 1372430 Microprogramming BURROUGHS CORP 22 May 1972 [28 May 1971] 23954/72 Heading G4A A microprogram for a digital computer in the form of for example punched tape or cards is produced by a machine implemented process, in accordance with the hardware and software specification of the computer. As described the characteristics and user programme of a "host" computer having disc storage and fast, e.g. semi-conductor, storage facilities are fed into a processor to select, from a library of micro instructions in a high level source language, instructions necessary to perform the functions required by the user programme. A pseudo level code is then generated by selecting micro code from pages in a generator code string file, each page corresponding to a function, the code being stored and subsequently converted to machine level code on a machine readable medium. Master library file.-The master library file comprise kernels, a kernel being a micro instruction, or a string of micro instructions or series of such strings which can be combined to form a macro instruction. Each kernel set, which is initially created manually and stored for example on punched card, includes (1) an identifying header, used for calling within the master library, (2) a latitude descriptor, specifying the degree of sensitivity of the kernel in respect of various parameters (e.g. time), (3) a conditional statement (in a high level programming language LIL especially adapted for performing the selection of the kernels) setting forth the conditions under which the kernel may be used and (4) a kernel body including statements (in a second high level programming language MIL) to perform the function-it may also include statements in the first programming language for example for controlling modification of a kernel. The library also includes a conditional file and a general directory to identify the location of the kernel sets.  Creating/updating of library.-Kernel sets and control sets, the latter being used to modify an existing kernel are read from punched cards and if a kernel set is sensed it is added to the library. Control sets are detected by a scan step resulting in a control routine at the end of which control is transferred back to the reader. When all the cards have been processed the kernels in the library are printed. Interpreter kernel library file.-To produce the required microprogram the kernel sets in the master library are sequentially examined to see if they include firstly any statements in the language LIL and secondly any statements in the language MIL. If there is a statement in LIL, the user specification is introduced from a module 50 (Fig. 4) to set up a test of whether there are any conditional statements in the kernel set, the kernel set being entered into the interpreter kernel file 52 only if the conditional statement is satisfied. If there are statements in MIL the kernel set is also entered into the interpreter library file. The user's specification cards take the form of punched cards of three different types specifying the hardware, software and S level commands of the user. The hardware specification forms may refer to for example a keyboard and specify (a) its existence, (b) whether it has a full capability or a partial capability and (c) in the case of the latter a list of its capabilities. The software specification forms specify the language required. The data on the hardware and software specification cards is stored in a matrix, each element of which corresponds to a specific hardware or software feature so that with the matrix filled with the specification of any particular user, the criteria for selection of the kernels is readily available The S level command form includes data indicating the operation to be performed and the priority value of the operation. They are used to form a table in a reserved area in the memory of the commands in the user's programme and to form a priority file. After the matrix, table and priority file have been filled the boundary between the interpreter and the user's programme in both the disc and fast access memories is established. A scanner and syntax module.-The free format source language of the kernel sets is reduced in a scanner and syntax module 60 into fixed format statement elements, the elements also being validated and any errors in the syntax being printed. The scanner examines the kernel statements character by character until a control character indicating the end of a word is encountered to produce various files such as an original variable file, a procedure declared file and a label file. If for example the statement reads "binary A (1), B (1)<SP>11</SP>; "move B to A", the space after the word "binary" is recognized as a control character and a reserved word table is searched to determine whether it is a verb, declaration or diagnostic. It is recognized as a declaration, resulting in the additional elements following "binary" being read, i.e. the word length and also other such information as the kernel identification. The variable A is then fetched and written into an original variable file if it has not been used previously. An index 64 is also prepared of the location of the variables in the file. The second variable B is similarly processed. Subsequent scanning recognizes the word "move" as a verb of class "0" i.e. one relating to, e.g. addition, subtraction or movement (other classes relate to such words as shift, begin, end) so that the variables required by the verb are fetched. A string file 62 is also prepared holding the functional statements in the kernels. Register analysis module.-A. register analysis module 66 assigns addresses in storage to the variables in the index 64, label file 74 and procedure file 76. Data is stored according to which of four classifications it belongs to, this being effected by four passes through the file, a different storage area being assigned to each class and the smallest space in the assigned area which will take the data being selected. An amplified data names file 68 stores the addresses at which the data is stored. String analysis module.-A string analysis module 70 is used to eliminate redundant micro instruction, e.g. branch generations following conditional statements. This is effected during four passes through the string elements file 62. The first pass detects conditional statements such as if A = B go to X, else go to Y and writes a special code into an amplified string file 72 to relocate the "go to" portion into the same string as the "if" portion. In the second pass more complex conditional statements of the type having several statements between the conditional clause and the final "else" are processed. In a third pass, redundant jumps included by the programmer when the processor instruction requires an execution time greater than the memory cycle are removed if they are followed by a jump instruction. In the fourth pass expressions such as "begin" and "end" which have been introduced for, e.g. debugging purposes are eliminated.  Code generator.-Micro code corresponding to the contents of the amplified string file 72 (which is written in MIL) is generated using a generator code string file 86 by code generator 80, to produce an interpreter code strings file 88. The code string file 86 comprises pages, each of which corresponds to a particular operation code, e.g. move, and carries a pointer value to identify the operation. It receives its input data in symbolic code from for example a disc memory. An element driver analyses the verbs in the amplified elements string to select the appropriate interpreter page of the file 86, control being then handed over to the interpreter page. The instructions on the pages are of two types, those that generate micro code and those that state the conditions under which the code is to be generated. When subsequent pages are required by an instruction the control is handed back to the driver to select the new page. A code emitter feeds the micro code output to the interpreter code strings file 88. If for example the amplified string is an instruction to move A to registers B or C a test is first made to determine the length of the variable so that the appropriate page, for moving a syllable digit or character, is selected. A sub routine is then set up to find if A is in either of the registers B or C and if it is no micro code is generated. If it is not appropriate micro code copies A into the register B. The code generator module 80 reads the amplified string elements file 72 twice, the first pass reading only straight line code and the second pass reading procedures. During the procedure pass a check is made to determine whether a label is associated with the instruction being processed and if so the sequence number of the interpreter code string is placed in the label table to enable future accessing of the label. The amplified string being processed is then held whilst the next string is read to effect a look ahead capability. A controller table is loaded with data means from the file 64 in the order of use required by the amplified string file. When the amplified data string includes for example a move instruction the micro code in the selected interpreter page is examined to determine by interrogating the controller which of a plurality of similar instructions is the one required, micro code representing the operation code for the instruction being read out. A test is next performed to determine if a source and sink register are present on the page and if so they are moved into a parameter table from which they are subsequently read to an output file. The actual data name is also read out. The micro code string is completed by including such details as the kernel identifier and whether a procedure operation has a local designation. The next micro code on the page is then processed until an instruction indicating the end of the g