GB1372430A - Process for producing a microprogramme or a soft interpreter for a computer - Google Patents

Process for producing a microprogramme or a soft interpreter for a computer

Info

Publication number
GB1372430A
GB1372430A GB2395472A GB2395472A GB1372430A GB 1372430 A GB1372430 A GB 1372430A GB 2395472 A GB2395472 A GB 2395472A GB 2395472 A GB2395472 A GB 2395472A GB 1372430 A GB1372430 A GB 1372430A
Authority
GB
United Kingdom
Prior art keywords
file
code
kernel
string
statements
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired
Application number
GB2395472A
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unisys Corp
Original Assignee
Burroughs Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Burroughs Corp filed Critical Burroughs Corp
Priority to IN2181/72A priority Critical patent/IN137925B/en
Publication of GB1372430A publication Critical patent/GB1372430A/en
Expired legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)

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
GB2395472A 1971-05-28 1972-05-22 Process for producing a microprogramme or a soft interpreter for a computer Expired GB1372430A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
IN2181/72A IN137925B (en) 1972-05-22 1972-12-18

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14780171A 1971-05-28 1971-05-28

Publications (1)

Publication Number Publication Date
GB1372430A true GB1372430A (en) 1974-10-30

Family

ID=22522948

Family Applications (1)

Application Number Title Priority Date Filing Date
GB2395472A Expired GB1372430A (en) 1971-05-28 1972-05-22 Process for producing a microprogramme or a soft interpreter for a computer

Country Status (1)

Country Link
GB (1) GB1372430A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2127188A (en) * 1982-06-14 1984-04-04 Tektronix Inc Software/hardware integration control system
CN116275587A (en) * 2023-04-17 2023-06-23 霖鼎光学(江苏)有限公司 Control system for laser cutting of workpiece

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2127188A (en) * 1982-06-14 1984-04-04 Tektronix Inc Software/hardware integration control system
CN116275587A (en) * 2023-04-17 2023-06-23 霖鼎光学(江苏)有限公司 Control system for laser cutting of workpiece
CN116275587B (en) * 2023-04-17 2023-10-27 霖鼎光学(江苏)有限公司 Control system for laser cutting of workpiece

Similar Documents

Publication Publication Date Title
US4330822A (en) Recursive system and method for binding compiled routines
US5668969A (en) Address selective emulation routine pointer address mapping system
EP0785510B1 (en) Program debugging system for debugging a program having a graphical user interface
US5418954A (en) Method for preparing and dynamically loading context files
US3293616A (en) Computer instruction sequencing and control system
US3510847A (en) Address manipulation circuitry for a digital computer
US5062039A (en) Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces
US3699528A (en) Address manipulation circuitry for a digital computer
US3737864A (en) Method and apparatus for bypassing display register update during procedure entry
US5379407A (en) Error handling in a state-free system
US6968428B2 (en) Microprocessor cache design initialization
Halpern XPOP: a meta-language without metaphysics
GB1372430A (en) Process for producing a microprogramme or a soft interpreter for a computer
US5129081A (en) System for processing data using logic language
US6286136B1 (en) Compile processing apparatus and method and program executing apparatus and method
US6721937B2 (en) Method and system for automated processor register instantiation
Hansen et al. The Cobol compiler for the Siemens 3003
Freeman Macro language design for System/360
JPS61148536A (en) Information processing system
JPH083801B2 (en) System allocator for a reduced processor that evaluates programs stored as binary directed graphs using frequency-free functional language code
Mock Logical organization of the PACT I compiler
JPS5894041A (en) Debug backup device for high-class language
KR20020021083A (en) System for generating optimized computer data field conversion routines
Griffith An intrinsically addressed processing system
Marcotty et al. The systems programming language, Malus

Legal Events

Date Code Title Description
PS Patent sealed
732 Registration of transactions, instruments or events in the register (sect. 32/1977)
PCNP Patent ceased through non-payment of renewal fee