JP2004348759A - Information processing system corresponding to multiple model, and its method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an object program format capable of realizing execution performance equivalent to a model-specific object program and common for a plurality of models of computers, and to provide a machine language program creation method therefrom, in relation to a translation method from a source program to a machine language program in an electronic computer. <P>SOLUTION: A compiler 1001 translates a source program 1004 into an abstract object program (ArmCode) 1005 including an instruction word line of an abstract computer ARM having a plurality of registers, and an allocation direction of abstract registers. An installer 1015 converts an ArmCode 1009 into a machine language program 1011 of an execution computer 1012 based on specification information 1010 of the execution computer 1012 comprising a register use direction 1019, and a machine instruction selection rule 1020. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

The present invention relates to a method of translating a source program into a machine language program in an electronic computer, which uses an intermediate format (object program) common to a plurality of types of computers.

A method of executing a program described in a high-level language on a computer can be roughly classified into the following two methods, generally called a compiler method and an interpreter method.
(Compiler method) After converting a program described in a high-level language into a machine language program of a computer to be executed, the converted machine language program is directly executed.
(Interpreter method) A language (intermediate language) different from the machine language of the computer to be executed is set, and another program (interpreter) for interpreting and executing the intermediate language on the computer to be executed is prepared in advance. A program described in a high-level language is converted into an intermediate language program, and the converted intermediate language program is executed using an interpreter.

The advantage of the compiler system over the interpreter system is the high speed of program execution for the following reasons.
(1) In the interpreter system, in addition to execution of a machine language corresponding to an intermediate language, it is necessary to distribute to a process corresponding to each intermediate language, calculate an address of an operand, and the like.

On the other hand, since the machine language is directly executed in the compiler system, these are unnecessary.
(2) In the compiler system, it is possible to omit (optimize) processing in consideration of the context of the program and the characteristics of the computer to be executed. On the other hand, in the interpreter method, since the interpreter itself has versatility with respect to the intermediate language program, the interpreter only executes the intermediate language program as it is, and cannot omit processing in consideration of the context of the program. In addition, since the characteristics of the computer to be executed are not reflected in the intermediate language program, it is impossible to map a specific variable described in a high-level language to a register of the target computer, thereby increasing the processing speed. is there.

From the viewpoint of the operation form of a program when one program is repeatedly executed, in the conventional method,
(Operation method 1) The compiler method is adopted, and the machine language program after conversion is stored and directly executed repeatedly.
(Operation method 2) An interpreter method is adopted, an intermediate language program is stored and repeatedly executed by the interpreter.
Was either.

When one program is repeatedly executed, the compiler method is overwhelmingly adopted from the viewpoint of shortening the execution time of each program, but the following disadvantages also occur.
(Disadvantage 1) A compiler that converts a source program into a machine language program is required for each model, which increases the amount of compiler development and requires maintenance and expansion to be performed for each model. The overhead of expansion is large.
(Demerit 2) When the same program is executed by a plurality of models, compilation (conversion from a source program to a machine language program) is required for each model, and the overhead of managing the machine language program is large.
(Disadvantage 3) In an environment where multiple models are connected via a network, multiple machine language programs for the same program are required for each model, and there are problems with version management and disk space, and it is difficult to execute the same program in a distributed manner. is there.
(Disadvantage 4) In some systems actually operated, there is no source program, and only a machine language program is used. In such a system, it is difficult to transfer or change the constituent models. Although the advancement of hardware technology has facilitated the advancement of computer architectures, the inheritance of machine language programs imposes strong restrictions on architecture changes.

  In order to eliminate the disadvantages described above, an intermediate language program that does not depend on a specific computer is adopted as a storage operation form, and the intermediate language program is converted into a machine language program of the target computer for high speed execution. That is, a method that only takes advantage of each of the compiler method and the interpreter method may be adopted. However, at present, there is no concrete system adopting such a method.

The compiler method and the interpreter method are described in detail in Non-Patent Document 1.

"A. Aho, R. Seti, and J. Ullman: Compilers. Pronciples, Techniques and Tools, Addison-Wesly 1986"

  In order to use an intermediate language program that does not depend on a specific computer as a storage and operation mode of a program to be repeatedly executed, it is necessary that the execution speed is at a level equivalent to that of a machine language program using a conventional compilation method.

That is, in order to realize the above,
(1) The intermediate language program in the storage operation mode is not executed by the interpreter, but is converted into a machine language program and executed immediately before execution. (2) In the conversion into the machine language program, characteristics of a computer to be executed It is indispensable to carry out optimization in consideration of

  An object of the present invention is to provide an entire system for realizing the above, that is, to provide a specific format of an intermediate language for storage operation, convert it into a machine language program at the start of execution, and perform optimization. The point is to set a specific method.

The intermediate language designed for the interpreter system cannot be used as an intermediate language for realizing the above for the following reasons.
(1) Since the intermediate language format for the interpreter system does not assume the optimization by the interpreter, it does not include information necessary for the optimization to be performed when converting into a machine language program.
(2) Computers can be broadly classified into register machines having a finite number of registers and mainly performing operations on registers, and stack machines having an operation stack and mainly performing operations on stacks. At present, most of the computers that exist in the world are register machines. Many interpreted intermediate languages assume operations on the stack because of the ease of designing the intermediate language and the interpreter. It is not impossible to convert operations on the stack to operations between registers, but values on the stack are intended to be disposable. It is necessary to use it as repeatedly as possible. That is, it is very difficult to convert an intermediate language program like a stack machine into an efficient machine language program of a register machine.

Therefore, in a method in which an intermediate language program that does not depend on a specific computer is stored and operated and converted into a machine language program immediately before execution, the following requirements must be satisfied.
(1) As a target computer, a program sequence should be focused on a register machine, and the sequence of the program should be conscious of the existence of a register at an intermediate language program level. Also, at the time of conversion to the intermediate language program, feasible optimization has been implemented.
(2) It is possible to optimize the method of using registers when converting to a machine language program. That is, the use of registers is determined so as to minimize the number of issuance of each instruction of loading values into registers and storing values from registers, and the instructions can be deleted if unnecessary. In addition, the information necessary for these optimizations must be obtained from the intermediate language program.
(3) A specific sequence (multiple instructions) of the intermediate language program may be replaced by an instruction specific to the target computer. In such a case, it is generally more efficient to implement the processing using one machine language instruction. If the target computer has a machine language instruction corresponding to a plurality of intermediate language instructions, it must be able to generate a machine language program using it.

In the following, a program in a storage operation format (intermediate language) will be referred to as an object program, following a conventional compiler method.

1. System Configuration In the present invention, a system for converting a source program into a machine language program of an execution computer is configured by the following three subsystems.
(1) Compiler: A subsystem that generates an object program (abstract object program) in a format independent of the model of the target computer from a source program. (2) Linker: A plurality of abstract object programs generated by a compiler are converted into one abstract. Subsystem for linking to an object program (3) Installer: A subsystem for converting an abstract object program linked by a linker into a machine language program of an execution computer.
2. Format of Object Program In order to standardize the object program, in the present invention, an abstract computer (Abstruct Register Machine, hereinafter referred to as ARM) having a plurality of registers is set, and the instruction sequence is set to a common object program (hereinafter, abstract object). (Called a program).

The features of ARM are as follows.
(1) It has a plurality of abstract registers. (The number of registers is conceptually infinite, but practically limited by the format of the abstract object program.)
(2) Instruction functions include register-memory data transfer, register operations (four arithmetic operations, logical operations, shift operations, comparisons), and execution control (unconditional branch, conditional branch, subprogram call / return) .
(3) The memory address is represented by a symbolic name, not a numerical value.

Here, the reason why the instruction sequence of the abstract computer having the register is used as the basic part of the object program is as follows.
(Reason 1) In order to speed up the conversion from the object program to the machine language program of each execution computer, it is desirable to minimize the semantic gap between the object program and the machine language program. A computer widely used at present is a register machine having a plurality of registers. By setting an ARM having an instruction set having a semantic common part of an instruction set of a general register machine, overhead of semantic conversion is set. And speed up conversion to machine language programs.
(Reason 2) In a register machine, one of the keys to speeding up execution of a machine language program is effective use of registers. By using ARM as the target computer of the compiler, the compiler can generate an instruction sequence that makes full use of registers.

The abstract object program is composed of the following.
(A) ARM instruction string (b) Pseudo code (label (branch, entry, variable, constant) definition, embedded information for optimization, embedded information for source level debugging)
(C) Generation control indicator (instruction of allocation / release of abstract register, selection of ARM instruction string based on allocation status of abstract register)
(D) Dictionary of variable names and procedure names for source-level debugging For abstract registers, the type of register is specified by a generation control indicator. What does it correspond to in a specific computer? Do not specify until. By doing so, the registers in the abstract object program are surfaced in a form independent of the machine type.
3. Execution Computer Specification The following two are set in the installer to generate a machine language program of the execution computer from the abstract object program.
(I) Specifying register use of execution computer (type and number of usable registers)
(Ii) Conversion rule from ARM instruction string pattern to execution computer instruction string pattern In the above description, the ARM instruction string pattern and the execution computer instruction string pattern are each composed of a plurality of instructions. You.

Here, the reason why the ARM instruction and the instruction of the execution computer are not made to correspond one-to-one is as follows.
(Reason 1) The instruction set of the ARM is not a strictly common part of the instruction set of the actual machine. Therefore, there is a case where the corresponding instruction of ARM does not exist in the instruction of the execution computer. In this case, it is necessary to implement one ARM instruction with several instructions of the execution computer.
(Reason 2) Contrary to the above, the execution computer may include an instruction corresponding to an instruction sequence of several ARM instructions. (Example: register-memory operation instruction, etc.) Generally, the execution speed is improved by reducing the number of instructions of the execution computer, and such a case is realized by one instruction.
4. Method for converting an abstract object program into a machine language program of an execution computer The installer has a table (hereinafter, register management table) for managing the correspondence between the abstract registers of the ARM and the real registers of the execution computer, and operates as follows. .
(1) Attempt to associate an abstract register with a real register according to an abstract register assignment instruction in an abstract object program. Within the range described in the register use specification of the execution computer specification, if there is a real register that does not correspond to another abstract register, that is, if there is a register that is not empty, the real register and the designated abstract register are made to correspond. .
(2) The association between the abstract register and the real register is released according to the register release instruction in the abstract object program.
(3) Using the generation control indicator in the abstract object program, check whether the abstract register corresponds to the real register and select an ARM instruction string.
(4) Applying a conversion rule from an ARM instruction string pattern in an execution computer specification to an execution computer instruction string pattern to the ARM instruction string selected in (3) to generate an instruction string of the execution computer And replacing the abstract register number with the actual register number.
(5) In the instruction word string of the execution computer generated in (4), the memory address is converted from a symbol name to a numerical address.

(1) The compiler can optimize the use of abstract registers and the real register allocation function of the installer can generate a machine language instruction sequence that effectively uses the registers of the execution computer. (2) The execution computer can use the instruction word pattern replacement function of the installer. You can use the high-performance instructions provided by.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 shows an example of the configuration of a system for translating a source program into a machine language program according to the present invention.

  The translation system includes subsystems of a compiler 1001, a linker 1002, and an installer 1003.

  The compiler 1001 inputs a source program 1004, performs syntax analysis, semantic analysis, optimization at a source program level described later, and the like, and outputs an ArmCode program 1005, which is an abstract object program. Since ArmCode is one of the features of the present invention, the specification of ArmCode will be described later in detail with reference to FIGS. In this connection, the configuration of the compiler will be described later with reference to FIG. 2, and the optimization processing in the compiler will be described later with reference to FIGS.

  The linker 1002 inputs the ArmCode program 1005 generated by the compiler from the source program 1004, the ArmCode program 1007 similarly generated by the compiler from another source program 1006, and the ArmCode program library 1008, and executes the routine reference relation between the programs. It resolves, resolves the variable / constant reference relationship, integrates the data area, and integrates the instruction area, and outputs the combined ArmCode program 1009. The functions of the linker itself are equivalent to some of the functions of the linkage editor of a conventional object program that regards ArmCode as a normal machine language, and will not be described in detail below.

  The installer 1003 inputs the combined ArmCode program 1009, and uses the register use specification 1019 and the machine instruction selection rule 1020, which are the specification information 1010 of each target computer, to perform actual register allocation, machine instruction selection, and model-dependent optimization. Then, the machine language program 1011 is expanded on the memory of the computer A 1012. The processing in the installer is also a feature of the present invention, and will be described later in detail with reference to FIGS.

  The computer A 1012 executes the machine language program 1011 generated above.

  When the ArmCode program 1014 generated from the source program 1013 by the compiler 1001 does not need to be combined with another ArmCode program or the ArmCode program library 1008, the installer 1003 directly inputs the ArmCode program 1014 and outputs it to the machine language program. Can be expanded.

  The installer 1003 generates a machine language program for the computer A. The installer 1015 generates a machine language program for the computer B 1017 using the specification information 1018 of the computer B. Therefore, in the present system, machine language programs (machine language programs 1011 and 1016) for a plurality of computers (computers A1012 and B1017) are generated from the same combined ArmCode program 1009, and the programs are generated by each computer. Can be performed.

  An example in which machine language programs of a plurality of computers having different specifications are generated from the same ArmCode program will be described later with reference to FIGS.

  FIG. 2 shows an embodiment of the abstract register machine compiler according to the present invention. The source program 3102 is first subjected to syntax analysis and semantic analysis by the syntax and semantic analysis unit 3104 of the compiler 3100 and converted into an intermediate language 3106, and information of various symbols used in the source program is described in the symbol table 3108. . The intermediate language 3106 is subjected to control flow analysis and data flow analysis by the intermediate language optimizing unit 3110 to perform global optimization, and an ArmCode (Abstract register machine Code) before optimization as a sequence of abstract register machine instructions. A column 3112 is generated. After that, an abstract register instruction optimization process 3114 is performed to generate an abstract object program 3116 as an optimized abstract register machine instruction sequence. For methods of syntax analysis, semantic analysis, control flow analysis, data flow analysis, and global optimization, see AV Aho, R. Sethi, JD Ullman, Compilers Principles, Techniques, and Tools (Addison-Wesley Publishing Co., 1986). ). The process of optimizing the abstract register instruction will be described later.

  One of the features of the present invention lies in the structure of the abstract register machine instruction ArmCode. ArmCode has a configuration and contents suitable for the processing intended in the present invention, that is, processing for converting an object program into machine instructions adapted to a target model at the time of loading at a high speed.

  This system of abstract register machine instructions can be commonly applied to many reduced instruction set computers, that is, RISC machines, and is called ArmCode-R (Abstract Register Machine Code for RISC machines).

It is suitable for computers with the following features:
(1) The operation is performed only between registers.
(2) Perform memory access only with Load / Store type instructions.
(3) It has a base register.
(4) The number of registers available for operation is not small (16 or more).
(5) It has an embedded constant.
(6) All instructions are represented by one word (32 bits).

Each instruction of ArmCode-R is not a machine instruction of a specific computer itself, but can be easily converted into it. The expression format of the instruction has the following features.
(1) Registers are represented not as physical registers but as abstract registers.
(2) The memory is represented by symbolic names instead of numerical addresses.
(3) Memory is addressed in byte units.
(4) The instruction length is fixed.
In the following, when simply referred to as ArmCode, it represents ArmCode-R.

  FIG. 3 shows the correspondence between the ArmCode program in FIG. 1 and the machine language program of the concrete computer. As described above, the source program 2910 is translated and combined by the compiler and the linker 2912, and is converted into the abstract object program 2920. This abstract object program is represented as a sequence of ArmCode, which is an instruction of the abstract register machine.

  The instruction of the abstract register machine is a model computer instruction common to many current computers, and the representative items included in each instruction are an abstract operator 2921, an abstract register specification 2923, and a memory / constant specification. 2925. The abstract operator represents an instruction universally provided in many computers, such as a load and a store for instructing data transfer between a memory and a register, and addition and subtraction as an arithmetic operation. The abstract register designation indicates a register of the abstract register machine, and there is no limitation on the number of used registers as in an actual register. The designation of the memory and the constant 2924 can be handled in the same manner as the memory and the constant in a real computer, except that the address and the size of the value are not limited.

  The abstract register machine instruction sequence 2920 is converted into a machine language instruction sequence of a target model by an installer created for each model. For example, the abstract register machine instruction sequence 2920 of FIG. 3 is converted into a machine language instruction sequence 2950 for model A when the installer 2930 for model A is used, and is converted to a machine language instruction sequence 2950 for model C when used. It is converted into a machine language instruction sequence 2960. The instruction of the abstract register machine and the instruction of the concrete computer do not always correspond one-to-one, but in general, an instruction sequence composed of m instructions of the abstract register machine becomes an instruction sequence composed of n instructions of the concrete computer. Is converted. The operator, register designation, and memory / constant designation included in each machine language instruction are unique to the model. For example, the operator 2951, the register specification 2953, and the memory / constant specification 2955 of the machine language program 2950 for the model A are specific to the model A, and the operator 2961 and the register of the machine language program 2960 for the model B are unique. The designation 2963 and the memo / constant designation 2965 are unique to the model B.

  The abstract register machine instruction ArmCode includes an instruction to be actually executed by the computer and a machine language generation instruction describing its structure, and a generation control statement for controlling the generation of the machine language. For example, it takes the following form.

alloc (Ar10, RcArith, alc10, 5, 0, 0xc0000000);
if (alc10) {
Load RegMd Ar10 Vbase OdDisp v;}
Add RegCon Ar11 Noreg OdCi 6;
There are the following types of machine language generation instructions. In an abstract object program, they are written separated by semicolons.
(1) Machine language instructions (Load4, Store4, Add, Sub, etc.)
(2) Pseudo-instructions indicating the structure of the program (Start / Pend, Block / End, Stmt, etc.)
(3) Pseudo-instructions indicating symbol names (Entry, External, Label, Name, etc.)
(4) Pseudo-instructions that specify memory (Dword, Dconst, Daddr, etc.)
(5) Pseudo-instructions that specify symbol information for debuggers, etc. (Sinf, etc.)
As shown in FIG. 4, the generation control statement includes a conditional statement 3120, an assignment statement 3122, and a function reference statement 3124, in which an expression including a constant and a simple variable can be used. As the generation control function, the following can be used as shown in 3124.
(1) alloc (abstract register name, register type, decision variable, instruction number, conserved number, priority)
Requests assignment of a physical register of the type specified by the second argument to the abstract register specified by the first argument. The instruction number is the sequence number of the register use instruction preceding the allocation request, and the preserved number represents the number of registers to be preserved even after the allocation. The priority is the priority of register allocation. The value of the determination variable of the third argument is 1 if the physical register can be allocated at the time of the allocation request, and becomes 0 if the physical register cannot be allocated.
(2) free (abstract register name)
Releases the physical register for the abstract register specified by the argument.

  The priority of register allocation is represented by a bit vector. A serial number is assigned to an instruction using an abstract register, and a vector having p-1 0s followed by 1 is associated with an instruction used p points ahead of the local point. It is assumed that the priority is higher when the bit vector is regarded as an unsigned integer value and is larger. Therefore, the priority of the abstract register used immediately after is higher than that used later. When used at a plurality of locations, a vector obtained by ORing these bit vectors is associated. If one local point advances, the bit vector is shifted left by one. At the time of left shift, bits overflowing to the left are discarded, and 0 is added to the right end. Therefore, the priority of the abstract register is highest immediately before the use position and decreases after passing the use position.

  The bit vector indicating the priority is not limited to one bit for one instruction. The sequence of instructions that use abstract registers or the sequence of machine-language instructions are divided into fixed-length sections, and one bit is assigned to each section, and the abstract register of interest is used in that section. If it is 1, it may be 0, and if it is not used, it may be 0. In this manner, the register use status of a long instruction sequence can be expressed by a short bit vector. If the length of the section is 1, the correspondence described above will be obtained.

  The registers used throughout the loop are arithmetically added to the bit vector shifted to the right by a (fraction of) length adjustment, assuming they are also used a distance of (the fraction of) the length of the loop. And set it as a bit vector representing the priority.

  The alloc function that allocates physical registers to abstract registers specifies this priority. If the priority is within the number of available physical registers, it is allocated, otherwise it is not allocated. Since the priorities of the abstract registers previously allocated rise when the use position is approaching and decrease when the use positions pass, the priorities of the other registers at the allocation point are determined to be allocated or not. Abstract registers with low priority and overflow are allocated to memory. The priority will be described later in more detail with reference to FIG.

  The instruction format of ArmCode-R is shown in FIG. Each instruction 3130 of the ArmCode-R comprises an operator 3132, an address mode 3134, a first operand 3136, a second operand 3138, and a third operand 3140. They represent the following:

Operator Instruction name Address mode Operand form
Category First operand Register R1, Literal c1
Or ArmCode address c1
Third operand memory address, displacement d3,
Literal c3, label c3,
ArmCode address c3, etc. Here, each operand 3136, 3138, 3140 is represented as shown in FIG. 4 (see the specification of the machine language generation instruction):
Register Abstract register number Memory address Absolute address, or the position in the symbol table that represents the variable name, or
Abstract register number indicating the address in memory Numeric value indicating displacement with respect to the displacement base register Literal Integer constant (numeric value, character code, or
(Character table and annotation table position)
Item number of label level table LBL
ArmCode address Position of one instruction of ArmCode The third operand is expressed as a combination of a small item indicating the type of the operand and a small item indicating the operand as follows.

Odsym s3 Symbol table entry s3
OdLab c3 Label List (LBL) Items c3
Odci c3 Scalar constant in instruction c3
OdCL c3 In-memory scalar constant denoted by c3
OdCS c3 String constant c3
OdGvar s3 Temporary variable s3 generated by the compiler
OdDisp c3 Displacement c3
OdNo Null Represents the absence of the third operand. The first operand 3136 indicates the storage location of the result for load or arithmetic instructions, and the register for storing data to be stored for store instructions. In the case of the conditional branch instruction, a register holding data to be subjected to the condition determination is shown.

  The address mode 3134 indicates the number of valid operands and their roles.

  FIG. 6 shows a possible combination of the address mode 3134 of FIG. 5, the first operand (operand 1) 3136, the second operand (operand 2) 3138, and the third operand (operand 3) 3140. For each address mode 3170 such as RegMI, the role of operand 1 (3172), operand 2 (3174), and operand 3 (3176) is shown. A blank indicates that the operand is not valid. If the operand is just a register, use or set the value of that register. If the operand is a constant, use that value. If the operand is an address register, the contents of the address register are regarded as a memory address and the operand is accessed. If the operand is specified by the base register and the displacement, the number obtained by adding the contents of the base register and the displacement is accessed as the memory address of the operand. In the address mode RegRCC, the constants c3 and c4 are packed in the third operand as being positive integers of 255 or less.

  FIGS. 7 to 12 show the specifications of the machine language generation instruction. The meanings of the symbols used there are as follows.

a: Street address or constant a. When expressing an address, a may be a numerical value c representing an absolute address or a numerical value s representing a position in a symbol table.

[a]: Contents of register or memory at address a
a ^: Register or memory pointed to by the contents of address a (the contents of a are used as addresses)
(): Treats as one symbol in parentheses
->: Assign to right register or variable
<-: Assignment load instruction 3210 to the left register or variable includes the following. (FIG. 7)
Load One word data indicated by operands 2 and 3
Load operand 1 register.

LoadB 1-byte data indicated by operands 2 and 3
Load the register of operand 1 right-justified.

Processing by mode:
RegReg R1 <-[R2]
RegMI R1 <-[R2 ^]
RegMR R1 <-[([R2] + d) ^]
RegMD R1 <-[d]
RegCon R1 <-c3
RegAdr R1 <-[R2] + d
Store instructions 3220 include: (FIG. 7)
Store One word of operand 1 data
Store at the location indicated by operands 2 and 3.

StoreB The rightmost 1-byte data of operand 1
Store at the location indicated by operands 2 and 3.

Processing by mode:
RegReg [R1]-> R2
RegMI [R1]-> R2 ^
RegMR [R1]-> ([R2] + d) ^
RegMD [R1]-> d
The integer type binary arithmetic operation instruction 3230 includes the following. (FIG. 7)
Add Add operand 2 to operand 1;
Put the result in operand 1.

              The carry becomes 1 or 0 according to the overflow.

Sub Subtracts operand 2 from operand 1 and
Put the result in operand 1.

carry is 1 if operand 2 is greater than operand 1,
Otherwise it is 0.

Mult Operand 1 is multiplied by operand 2,
Put the result in operand 1.

Div Divides operand 1 by operand 2,
Put the quotient in operand 1.

    UnsAdd Same as Add except that the calculation is unsigned.

    UnsSub Same as Sub except that calculation is performed without sign.

    Same as Add except that it is added together with AddC carry.

    Same as Sub except that subtraction is performed in conjunction with SubB borrow.

Processing by mode:
RegReg ([R1] op [R2])-> R1
RegCon ([R1] op c3)-> R1
Here, op is an operator real type binary arithmetic operation instruction 3240. (FIG. 8)
AddR Adds operand 2 to operand 1 and
Put the result in operand 1.

SubR Subtracts operand 2 from operand 1.
Put the result in operand 1.

MultR Operand 1 is multiplied by operand 2,
Put the result in operand 1.

DivR Divides operand 1 by operand 2,
Put the quotient in operand 1.

Processing by mode:
RegReg ([R1] op [R2])-> R1
RegCon ([R1] op c3)-> R1
Where op is an operator.
Binary logical operation instructions 3250 include: (FIG. 8)
And Operand 2 with operand 2
Put the result in operand 1.

Or Operand 2 with operand 2
Put the result in operand 1.

Xor Operand 2 to operand 1
Put the result in operand 1.

Processing by mode:
RegReg ([R1] op [R2])-> R1
RegCon ([R1] op c3)-> R1
Where op is an operator.
The unary operation instructions 3260 include the following. (FIG. 8)
Negate Inverts the sign of operand 1 and places the result in operand 1.

    Not Operand 1 is bit-inverted and the result is placed in Operand 1.

Processing by mode:
Reg1 Operates on the contents of operand 1 and leaves the result in operand 1.
Compare instruction 3270 includes: (FIG. 8)
Compar Compares the contents of operands 1 and 2 and sets a condition code.

Processing by mode:
RegReg Gt if [R1]> [R2], Eq if [R1] = [R2], Lt if [R1] <[R2].

Gt if RegCon [R1]> c3, Eq if [R1] = c3, Lt if [R1] <c3.
Conditional test instructions 3280 include: (FIG. 8)
If TZero mode Reg1 0, condition code is Eq,
Otherwise, it is Ne.

The bit position indicated by the third operand c3 of TBit mode RegCon [R1] is
If 0, the condition code is Eq; if 1, the condition code is Ne.
The conditional branch instruction 3290 includes the following. (FIG. 9)
If the BrEq condition code is Eq, jump to the position specified by the operand.

If the BrNe condition code is not Eq, jump to the position specified by the operand.
Huh.

    If the BrGt condition code is Gt, jump to the position specified by the operand.

If the BrGe condition code is Gt or Eq, the position specified by the operand
Jump to.

If the BrLe condition code is Lt or Eq, the position specified by the operand
Jump to.

    If the BrLt condition code is Lt, jump to the position specified by the operand.

          In any of the above cases, if the condition is not met, the process proceeds to the next instruction.

Mode
The position indicated by the Const label table LBL [C3] is the instruction address of the jump destination.

RegR [R2] + d is the instruction address to jump to.
The unconditional branch instruction 3300 has the following functions. (FIG. 9)
Jump Jump to the position specified by the operand.

Processing by mode
The position indicated by the Const label table LBL [C3] is the instruction address of the jump destination.

RegR [R2] + d is the instruction address to jump to.
The subprogram reference instruction 3310 has the following functions. (FIG. 9)
Call After recording the return address, the subprogram specified by the operand
Jump to

Processing by mode
RegMR Put the return address in R1 and jump to [R2] + d.

Register the return address of RegMD into R1 and jump to the subprogram address indicated by LBL [c3].
Huh.

Reg1 After stacking the return address, jump to address [R1].
Return instruction 3320 has the following functions. (FIG. 9)
Return recorded by Call from the subprogram specified by the Return operand
Jump to the house number.

Processing by mode
Jump to the return address recorded in Reg1 R1.

Retrieve the return address stuck by Reg0 Call by LIFO method and go there
jump.
Shift instructions 3330 include: (FIG. 10) In each case, the content of the first operand R1 is shifted left or right by the number n indicated by the second or third operand.

    ShiftL Shift R1 left by n bits. The right n bits are 0.

    ShiftR Shift R1 right by n bits. The left n bits are zero.

Processing by mode
RegCon R1 is the target register and c3 is the number of shift bits.

RegReg R1 is the target register and [R2] is the number of shift bits.
The rotation instructions 3340 include: (FIG. 10) In each case, the content of the first operand R1 is rotated left or right by the number n indicated by the second or third operand.

    RotL Rotate R1 left by n bits.

    RotR Rotate R1 right by n bits.

Processing by mode
RegCon R1 is the target register, c3 is the number of rotation bits.

RegReg R1 is the target register and [R2] is the number of rotation bits.
The bit manipulation instructions 3350 include: (FIG. 10)
GetBit RegCC R1 c3 bit data starting from c2 bit
Right-justify and enter R1. The left part of R1 is 0.

GetBit RegRCC c2 bit data starting from c2 bit of R2
Right-justify and enter R1. The left part of R1 is 0.

PutBit RegRCC R1 right c4 bit length data
In the field of c4 bit length starting from c3 bit of R2
Put in. The contents of the other bit fields are unchanged.
The data conversion instruction 3360 includes the following. (FIG. 10)
ItoR RegReg Converts the contents of R1 from integers to real numbers and puts them in R2.

    RtoI RegReg Converts the contents of R1 from a real number to an integer and places it in R2.

Convert the contents of ItoD RegReg R1 from integers to long precision real numbers and put them in R2.
You.

DtoI RegReg Convert the contents of R1 from a long-precision real number to an integer and place it in R2.
You.
The state switching instruction 3370 includes the following. (FIG. 11)
SaveSt RegMR Saves the current processor state to memory.

(Save information: program counter, status code, mask, etc.)
According to the information stored in LoadSt RegMR memory,
Recover the processor state.
The no-operation command 3380 is as follows. (FIG. 11)
Nop Reg0 Do nothing. A machine instruction occupies one word.
Pseudo-instructions 3390 representing the program structure include: (FIG. 11)
Start Cont1 OdSym s3 Object start pseudo with name (in symbol table)
order
SubP Cont1 Indicates the start of the subprogram indicated by Odsym s3.

Block Cont0 Block start
End Cont0 Block end
Loops Cont1 OdLab LBL [c3]
Indicates the beginning of the statement.

Loope Cont1 OdLab LBL [c3]
Indicates the end of the statement.

Pend Cont0 End of subprogram or unit
(End is followed by Define Storage and Define Constant,
(Pend is added at the end)
Stmt Cont1 Indicates the start position of the sentence whose sentence number is OdCic3.
Pseudo-instructions 3400 for specifying symbolic names include: (FIG. 11)
Entry Cont1 Pseudo-imitation that shows the name (in the symbol table) indicated by OdSym s3 as the entry name
Command
Extern Cont1 Indicates that the name (in the symbol table) indicated by OdSym s3 is an external name
Pseudo instruction
When Label Cont1 OdLab c3 is an LBL table number (user label) with a symbol table,
A pseudo-instruction that defines the name of the symbol table as a label name.

When c3 is n of the LBL table number (generated label) without a symbol table,
A pseudo-instruction that defines the generated label name \ n as a label name.

When Label Cont1 OdCL c3 is the LRG table number m indicating the memory constant,
A pseudo-instruction that defines the constant name \\ Cm as a label name.

Label Cont1 When OdGvar s3 is a symbol table number k representing a generated variable,
Pseudo-instruction that defines generated variable name \\ Tk as a label name.

Name Cont1 OdSym s3 shows the name (in the symbol table) with the previous OpLabel name.
The pseudo instruction 3410 for specifying the instruction memory to be EQUed includes the following. (FIG. 12)
Dconst Cont1 Constant definition with OdCic3 as an integer constant value
Dconst Cont1 Constant definition that regards OdCS c3 as one word character string
Dconst Cont1 Constant definition with OdCS c3 as one word character string constant
Dword Cont1 OdCi c Define Storage instruction that takes 3 words of memory
Define Address for the name (in the symbol table) indicated by Daddr Cont1 OdSym s3
MCode Cont1 OdCic The pseudo-instruction 3420 that specifies the symbol information for the instruction debugger or the like that generates the machine language MRT [c3] indicated by OdCic c3 is as follows. (Figure 1
2)
PInf Cont1 Indicates the information of the program characteristic information table at the position indicated by OdCic3.
You.

    Indicates the symbol information at the position indicated by SInf Cont1 OdCic3.

  FIG. 13 is an example of a source program 3102 that is input to the compiler shown in FIG. It is composed of a declaration statement 3610 specifying a global variable, a specification 3614 of a function name, a declaration 3616 of a local variable in a function, a sequence of executable statements starting from 3620, and the like. Numbers such as 1 at the beginning of 3610 and 10 at the beginning of 3620 indicate the sentence number of each sentence. FIGS. 14 to 16 show examples in which this source program is converted into a column of ArmCode. In this case, the optimization processing has not been performed yet.

  The pseudo-instruction 3700 for specifying symbolic information corresponds to the declaration statement 3610 of the source program, and 3702 similarly corresponds to 3616. The column of ArmCode starting from 3710 corresponds to the column of executable statements starting from 3620 of the source program.

  The priority of the register will be specifically described with reference to FIGS. Instructions that use the abstract register in this ArmCode are instructions such as 3720, 3722, etc., which are marked with * at the beginning. The 3710 alloc instruction requests the allocation of a physical register to an abstract register called Vbase, and specifies 0x62489700 + 0x00224897 as its priority. The register Vbase is used in the instructions 3722, 3734, 3758, 3770, 3790, 3828, 3846, 3850, 3856, and 3860, and these are counted as the number of the abstract register use instruction from the position 3710 where alloc is located. If a bit vector is created with 1 used and 0 not used, it becomes 01100010010010001001011100000000 as shown by 3910 in FIG. The hexadecimal representation of this is 0x62489700 in 3710. In the programs of FIGS. 14 to 16, there is a loop returning from the 3868 instruction to the 3728 instruction, and among them, there are 23 instructions using the abstract register. In this embodiment, the number of instructions that use the abstract register in the loop is divided by 3 and rounded up if there is a remainder, and is used as a priority adjustment number for the loop. The Vbase bit vector used in the loop is 00100010010010001001011100000000 with the second bit of 3910 set to 0, and dividing this by 23 and rounding it up and shifting it to the right by the number 8 gives 00000000001000100100100010010111 as 3912. The value expressed in hexadecimal is 0x00224897.

  Accordingly, the priority at the time of Vbase allocation request is a number 0x62489700 + 0x00224897 obtained by adding both as unsigned integers, as shown at 3710 in FIG. Similarly, the priority of 3718 to Ar5 and the like is calculated as indicated by 3918 and 3920.

  The priority of register allocation is not fixed, but shifts to the left as the position of the instruction of interest advances, as described above. Therefore, at the position 3732 at the beginning of the loop, since two register use instructions are exceeded, the register priorities of Vbase and Ar5 are shifted left by two as shown in 3914 and 3918 of FIG. The priority is 0x89225C00 + 0x0089225C, and the priority of Ar5 is 0x44110000 + 0x00441100 as shown in 3922 and 3924. This is compared with Ar6 priority 0xE0000000 which is required to be allocated in 3732.

  FIG. 18 is a flowchart showing a procedure for creating the above-mentioned register assignment priority bit vector. When the priority bit vector of the register r is represented by Pr, it is reset first (step 3930). Then, the next ArmCode is fetched (step 3932). If it is not the start of the loop (step 3934), it is checked whether or not it is a register use instruction (step 3936). The bit vector is shifted one bit to the left (step 3938). If the register r is used (step 3940), the rightmost bit of Pr is set to 1 (step 3942). If the register r is not used, the rightmost bit of Pr is one bit. Is set to 0 (step 3943). If the next ArmCode instruction is the end of the loop or the instruction to release the register r, the calculation of the priority bit vector for r is terminated (step 3944). Otherwise, the processing is repeated from the retrieval of the next ArmCode instruction.

  If the retrieved ArmCode is a loop start instruction (step 3934), the priority bit vector in the loop of the register r is represented by Lr, and Lr is calculated in the same procedure as in steps 3930 to 3944. calculate. The Lr obtained in this manner is adjusted by dividing the number of instructions using abstract registers in the loop by 3 and shifting Lr to the left by the rounded-up number if there is a remainder (step 3947). The result is added to the priority bit vector Pr of the instruction sequence including the loop (step 3948). In this way, the allocation priority bit vector Pr for one abstract register r is calculated. This process is executed for each abstract register.

FIG. 19 is an embodiment showing one stage of object optimization for improving the efficiency in executing the abstract register machine instruction ArmCode. First, the ArmCode column is divided at control inflow points and branch points, and divided into a number of basic blocks (step 3952).
Each basic block is characterized in that it is always executed in a straight line from the first instruction to the last instruction. In FIGS. 14 to 16, 3712 to 3722, 3724 to 3748, 3750 to 3778, and the like are one basic block, respectively, and at the beginning of each basic block, a generation control instruction bblock indicating their connection relation is attached. If a certain basic block b is always executed immediately after another basic block a is executed, a series of basic blocks which can be repeatedly connected to b after the basic block a is expanded to an extended basic block. I will call it. In the basic blocks starting from 3724, 3750, and 3780, the last one is executed immediately after the previous one is executed. It is. A basic block that cannot be extended because a preceding basic block or a subsequent basic block cannot be uniquely determined, such as a basic block starting from 3840, is considered as one extended basic block by itself. Next, the common expression is deleted in the extended basic block. Therefore, starting from the first extended basic block (step 3954), a common expression in the extended basic block is extracted (step 3956), and the subsequent common expression is replaced with a register or a variable representing the result of the common expression. (Step 3958). This is repeated until the last extended basic block is reached (steps 3960 and 3962). This can be achieved by applying the method described in the book by Aho, Sethi and Ullman to ArmCode.

  FIGS. 20 to 21 show an abstract register instruction sequence obtained by converting the instruction sequences of FIGS. 14 to 16 by performing such processing and the optimization processing described later. The above-described optimization processing will be described using a specific example with reference to FIGS. 14 to 16 and FIGS. The instruction sequence 3758, 3760 for calculating the value of the abstract register Ar8 and the instruction sequence 3790, 3792 for calculating Ar12, and the instruction sequence 3828, 3830 for Ar15 in FIGS. 14 to 16 are the same as the instruction sequence 3734, 3736 for Ar6. The instruction 3764 for Ar9 is the same as the instruction 3740 for Ar7. Similarly, Ar13 is the same as Ar11, and Ar15 and Ar16 are the same as Ar5. Thus, in FIGS. 20 and 21, these abstract registers have the same value, such as reusing AR6 and AR11 at 4098, reusing AR7 at 4076, and reusing AR5 at 4108, 4110, and 4112. It has been replaced with an abstract register, and the instruction sequence for the values of AR8 and AR12, AR15, AR9, AR13, AR15, and AR16 has been deleted. With this replacement, the use frequency and use position of the abstract registers change, so the allocation priority of each abstract register also changes. An alloc instruction such as 4028 in FIGS. 20 and 21 also indicates this.

  In FIGS. 20 and 21, the in-loop invariant expression is further moved out of the loop and the branch optimization is performed on the ArmCodes of FIGS. FIG. 22 is a flowchart showing the process. After detecting a loop by flow analysis (step 4202), starting from the inner loop (step 4204), detecting an invariant in the loop (step 4206), and moving it immediately before the start of the loop (step 4208), Avoids doing the same calculation over and over. This is repeated up to the outermost loop (steps 4210 and 4212). Since the values of Ar10, Ar11, and Ar17 in FIGS. 14 to 16 do not change in the loop starting at 3728 and ending at 3874, the instruction sequences 3770, 3786, and 3860 for calculating them are moved before the loop. These are 4038, 4044, and 4050 in FIGS.

  In FIGS. 14 to 16, since the branch destination L3 (3806) at BrGe at 3778 has an unconditional branch instruction (3808) to L5, by setting the branch destination of this BrGe to L5, The unconditional branch instruction (3808) can be deleted. Since the jump destination L4 (3812) of the jump of 3802 also has an unconditional branch instruction (3814) to L5, by setting the jump destination of this jump to L5, the unconditional branch instruction (3814) at L4 Can also be deleted. ArmCode shown in FIG. 20 and FIG. 21 is a result obtained by increasing the efficiency of the instruction sequence in the abstract register machine in order to improve the execution efficiency.

  Next, a method of generating a machine instruction sequence of an actual computer from the abstract register instruction sequence (ArmCode-R instruction sequence) thus created will be described.

  FIG. 23 shows the types of physical registers in a certain model A. Reference numeral 4260 indicates that the physical registers that can be used as the arithmetic operation RcArith are the 8th to 23rd registers. Similarly, RcAddr at 4262 indicates a register that can be used for address calculation, RcSect at 4264 indicates a register that can be used to indicate the start position of a section, RcReturn at 4266 indicates a register used to return from a subprogram, and RcFuncval at 4268 Is a register that can be used to store function values, 4270's RcParm is a register that can be used to store arguments, 4272's RcNosave is a register that is not saved or restored when referring to subprograms, 4274's RcTemp is a temporary register, 4276's RcFixed is The fixed-purpose register, RcAny in 4278, represents all registers to be assigned.

  FIG. 24 shows a part of the correspondence between the physical registers of the model A and the abstract registers. Although any number of abstract registers 4280 can be used, the number of physical registers 4282 of model A is limited to 32. When the abstract register 4284 for storing the function value is represented by Funcval0 and Funcval1, it is associated with the physical registers 2 and 3 (4290, 4291). Assuming that Param0, Param1,... Param p are used as the abstract registers 4285 for storing arguments, they are associated with physical registers 4 to 7 (4291, 4292). If Ar0, Ar1,... Ar q are used as abstract registers 4286 for arithmetic operations, they are associated with physical registers 8 to 23 (4292, 4294). If Addr0, Addr1,... Addrr are used as abstract registers 4287 for address calculation, they are associated with physical registers 16 to 23 (4293, 4296). If Sect0, Sect1,... Sects are used as the abstract register 4288 indicating the section start position, they are allocated to the physical registers 20 to 23 (4295, 4297). Here, the number of abstract registers for arguments p + 1, the number of abstract registers for arithmetic operations q + 1, and the like are not limited by the number of physical registers, but can be used as many as required by the source program. I have. How this abstract register is assigned to the physical register of the target model will be described later with reference to FIGS.

  FIG. 25 is a diagram illustrating a method of performing machine language generation by pattern matching. In this system, a pattern matching section 4556 and a machine instruction selection rule table 4630 are provided. When an abstract register machine instruction sequence 4640 is provided to the section 4556, a machine language program 4650 is generated. In the machine instruction selection rule table 4630, an input pattern and an output pattern corresponding to the input pattern are entered. Assuming that one instruction 4602 is extracted from the instruction sequence 4640 of the abstract register machine, a match is found in the input pattern of the machine instruction generation rule. In this example, since the input pattern i of the i-th generation rule 4632 matches, the replacement is performed according to the corresponding generation pattern i, and the machine instruction 4652 is generated. At this time, processing such as replacing the abstract register with a physical register or changing the generation method in accordance with the situation before and after is performed, which will be described later with reference to FIGS. 29 to 35.

  FIG. 26 shows a part of a machine instruction selection rule for model A. This takes a form in which the method of generating a machine language instruction corresponding to the instruction sequence of the abstract register machine shown in 4300, 4312, or the like is represented in a form close to that of the C language by enclosing it in parentheses. The | symbol at the head of 4312, 4316, etc. is a symbol indicating the case of an instruction sequence. The operands Reg1 and C, V, etc. of the abstract register machine are represented as $ Reg1, $ C, $ V, etc. in {}.

  More specifically, the first 4300 indicates the generation method of the machine instruction of the model A for the abstract register machine instruction for loading a constant by a sequence of statements in {} starting with 4302. In this case, if the constant is 0 or more and less than 65536, a machine instruction is generated in accordance with the designation of 4304, and otherwise, a machine instruction is generated in accordance with the specifications of 4308 and 4310. The machine instruction 4500 in FIG. 28 is generated by applying this rule to the instruction 4030 in FIG. In this example, as a result of register allocation, as shown at 4400 in FIG. 27, physical registers $ 08 and $ 17 are allocated to the abstract registers Ar5 and $ 6, respectively.

If there are not the required number of physical registers, the physical registers are not allocated when requested by alloc, and the allocation process is performed again when they are actually used. At 4046 in FIG. 20, a physical register allocation request is issued to the abstract register Ar17. Here, the number of registers to be preserved after allocation is specified as 2, and the priority is not so high. If the assignment could not be made, the condition of 4048 would not be satisfied, so that no load instruction was generated at 4050, and it was recorded that Ar17 represents the value of the variable n. At the 4112 comparison instruction that uses Ar17, since no physical register has been allocated yet, the register allocation process is executed again when processing this abstract register instruction, and at this point Ar17 has the highest priority Therefore, the assignment is executed, and a load instruction for setting the value is also generated. Assuming that the physical register $ 09 is allocated to Ar17 in this example, an instruction to load the value of the variable n is generated according to the record in 4046. As a result, 4526
sub $ 24, $ 08, $ 12
Instead of the instruction
lw $ 09, n ($ 16)
sub $ 24, $ 08, $ 09
Are generated. When an abstract register to which no physical register is assigned is used, a physical register is assigned to the abstract register and a value is set there. This is because the function gen used in 4304 of the machine instruction selection rule shown in FIG. Do with.

In this way, the installer for model A generates the machine language program for model A from the abstract object program. At this time, the optimal instruction sequence is selected and the physical registers are optimally used in accordance with the target computer. In this example, the instruction sequence to be generated is changed according to the size of the constant in the generation rule 4302 in FIG. 26, or the abstract register is associated with the type and number of usable physical registers, and the value is set once. We try to use physical registers such as $ 11 as many times as possible. After conversion into machine language, if there is a common expression that accompanies a model-specific expression, optimization processing such as deleting the recalculation is performed. The processing is the same as that described in FIG. is there.

  FIG. 29 is a flowchart showing a process of generating a machine language. After the initial setting (step 4552), one ArmCode instruction constituting the abstract object program is extracted (step 4554), and which of the patterns in the ArmCode sequence described in the machine language selection rule as shown in FIG. Is performed (step 4556). If there is no pattern that matches the read portion, the collation state at that time is recorded (step 4560), and the process proceeds to the next ArmCode instruction fetch. If there is a matching pattern, preparation for generation processing is prepared in accordance with the description of the machine language generation for the pattern (step 4562), and if the described contents require register allocation, the processing is performed (step 4564). If the request requires memory allocation, the process is performed (step 4566). If the request requires generation of specific machine instructions, the process is performed (step 4568), and control information relating to debug information and the like is requested. If these are required, they are added to the machine language program (step 4570), and if they require setting of generation control information related to register allocation, memory allocation, or selection of an instruction to be generated, these settings are made (step 4572). ). Then, the process repeatedly proceeds to the next sentence described in the description of the machine language generation (step 4576). When the end of the operation described there is reached (step 4574), the generation process for this pattern is cleaned up. (Step 4578), the matching state is changed to match the current state (Step 4580), and the process returns to the pattern matching processing. If it is found that all of the abstract object programs have been processed, the generation of the machine language is terminated (step 4582).

  FIG. 30 is a diagram showing the internal structure of an installer for generating a machine language from ArmCode as described above. The installer 4530 generates a machine language 4549 from the ArmCode column 4531 and the machine instruction generation rule 4532 of the model. The collation basically takes a form using a state transition table. Therefore, the machine instruction generation rule 4532 is temporarily converted into the state transition table 4535 by the state transition table creation program 4533. This state transition table 4535 is a table showing an action to be executed and a state number to be changed next for a combination of each ArmCode and a state number as input. In the part for performing pattern matching based on the state transition, an appropriate routine among the action routines 4538 is selected and executed from the input ArmCode and the state at that time according to the state transition table. The state stack 4544 records the state transition history at that time. The register use specification table 4546 records the register use specification specific to the target model, and the register correspondence table 4548 records the correspondence between the abstract registers and the physical registers in the program being processed.

  FIG. 31 shows the types of physical registers in a certain model B having a different instruction system from the model A described above. Reference numeral 4600 indicates that the physical registers that can be used as the arithmetic operation RcArith are registers 1 to 7 and 16 to 23. Similarly, RcAddr of 4602 indicates a register that can be used for address calculation, and RcTemp of 4614 indicates a register that is temporarily used. Is specified.

FIG. 32 illustrates a part of the correspondence between the physical registers of the model B and the abstract registers. As in the case of the model A, any number of abstract registers 4620 can be used, but the number of the physical registers 4622 of the model B is limited to 32. When the abstract register 4624 for storing the function value is represented by Funcval0 and Funcval1, it is associated with the physical registers 8 and 9 (4631, 4632). Assuming that Param0, Param1,... Param p are used as the abstract registers 4625 for storing arguments, they are associated with the physical registers 24 to 29 (4633, 4634).
If Ar0, Ar1,... Ar q are used as abstract registers 4626 for arithmetic operations, they are mapped to physical registers 1 to 7 and 16 to 23 (4635, 4636, 4637, 4638). Similarly, Addr0, Addr1,... Addrr as abstract registers 4627 for address calculation are associated with physical registers 1 to 7 and 16 to 23 (4639, 4640, 4641, 4642).

  FIG. 33 shows a part of a machine instruction selection rule for model B. 4700 shows how to generate a machine instruction for an ArmCode instruction to load a constant, 4712 is a machine instruction for loading from memory, and 4716 is a method for generating a machine instruction for an ArmCode instruction sequence that puts the result of adding the registers Reg1 and Reg2 into Reg3. Indicates the machine instruction selection rules necessary for converting the abstract object program of FIG. 20 to the machine language program of FIG. 21. FIG. 34 shows the correspondence between the abstract registers and the physical registers of the model B in the programs of FIGS. 20 to 21 by 4780 or the like, and is a result of register allocation by generation control instructions such as alloc and free. .

  The machine instruction 4800 of FIG. 35 is generated by applying the rule 4700 of FIG. 33 to the instruction 4030 of FIG. 20, and the machine instruction of FIG. 35 is obtained by applying the rule 4722 to the instruction 4032 of FIG. 4802. Thus, the installer for model B generates the machine language program for model B in FIG. 35 by applying the rules in FIG. 33 to the abstract object programs in FIGS.

  As described above, from the same abstract object program, the installer for model A generates a machine language program for model A, and the installer for model B generates a machine language program for model B. In this embodiment, the machine instruction selection rule and the physical register use designation are different between the two installers, but the processing contents shown in FIG. 29 are the same.

  According to this embodiment, most of the optimization processing relating to global optimization and register allocation is performed by a compiler independent of the target model, and information on flow analysis and register allocation by the compiler is installed. Therefore, the installer can generate a machine language program with high execution efficiency without performing much complicated processing. Therefore, even if a machine language program for a target model is generated from a model-independent abstract object program by the installer every time the program is started, the execution efficiency or the processing time by the installer may not be a problem. Absent.

  If the software is distributed in the form of the abstract object program of the present embodiment, the same abstract object program can be distributed to a plurality of models, and there is no need to adjust or recompile the software for each model. And management becomes remarkably easy.

  Further, according to the present embodiment, the abstract object program is divided into finer processing operations than the source program, and its structure and description order are different. Is almost impossible to restore. Therefore, if the software is distributed to users in the form of an abstract object program, the same program can be executed by a plurality of models while the implementation method and algorithm of the software included in the source program are kept secret. The change can be realized on the user side.

  By using the installer of the present invention, the same source level debugging system can be used in a plurality of types of systems. The embodiment will be described below with reference to FIGS.

  FIG. 36 is a block diagram of a debugging system to which the installer of the present invention has been applied. The debugger 5100 is used to debug the abstract object program 5102 created by compiling the source program 5101. The installer 5103 is used to convert an abstract object program into a machine language program 5107. The main storage device 5104 is used to store a machine language program 5107 and a debug information table 5108. The display device 5105 is used to display the result to the user, and the input device 5106 is used to receive the input from the user.

FIG. 37 is a flowchart showing the operation of the debugger. First, the abstract object program 5102 is read (step 5120). Since the abstract object program includes source information indicating a position on the source program, a source / abstract object correspondence table is created based on the source information (step 5121). Next, an installer is executed by using the read abstract object program as an input, and a machine language program is created on the main storage device (step 5122). At this time, an abstract object / machine language correspondence table is created for associating the abstract object program with the machine language program (step 5123). In this embodiment, the source / abstract object correspondence table and the abstract object / machine language correspondence table are combined into one table (source / abstract object / machine language correspondence table). This table is included in the debug information table 5108. Next, the user inputs a necessary debugging command (step 5124), and branches according to the type of the command (step 5125). In the case of a display command, display processing is performed (step 5126), in the case of a breakpoint setting command, breakpoint setting processing is performed (step 5127), and in the case of an execution command, execution processing is performed (step 5128), and the processing ends. After that, repeat from step 5125. These command processes will be described in detail with reference to FIGS. If the input command is an end command, the process ends.

  FIG. 38 shows an example of the display command. This example is a command for displaying the value of the variable i, and includes a display command name 5131 and a variable name 5132.

  FIG. 39 is a flowchart of the display process, which details the process of step 5126 in FIG. 37. First, the variable name in the display command is extracted (step 5133). Next, using a source / abstract object / machine language correspondence table (hereinafter, also simply referred to as a correspondence table), the variable is converted into an address on the main memory where the content of the variable is stored (step 5134). Next, the content of the address obtained in step 5134 is read from the main memory (step 5135), the read content is converted according to the data type of the variable, and displayed on the display device (step 5136).

  FIG. 40 shows an example of the breakpoint setting command. This example is a command for setting a breakpoint in the statement of statement number 10 of the source program, and includes a command name 5141 and a statement number 5142.

  FIG. 41 is a flowchart of the break point setting process, and details the process of step 5127 in FIG. First, the statement number in the command is extracted (step 5143). Then, a flag indicating that a breakpoint is set at the statement number in the correspondence table is turned on (step 5144).

  FIG. 42 shows an example of the execution command. This is a command for executing the program, and consists only of the command name 5151.

  FIG. 43 is a flowchart of the execution process, which details the process of step 5128 in FIG. First, only one instruction is executed (step 5152). This is possible by running the CPU in a mode such that each time one instruction is executed, a trap is taken and control returns to the debugger. Next, the address of the instruction is extracted (step 5153). This is possible by reading the contents of the program counter and the like. It is checked by using the correspondence table whether a breakpoint is set at the address taken last, and if not set, the processing is repeated from step 5152, and if set, the processing is ended (step 5154).

  FIG. 44 shows an example of a source program to be debugged. Here, the statement number 5160 of each statement and the description 5161 of the source program of the statement are shown. Statement numbers are not included in the actual source program. In the following description of the present embodiment, this source program will be used as an example.

  FIG. 45 is a diagram showing an example of the source / abstract object / machine language correspondence table. The correspondence table includes (a) a statement information table and (b) a variable information table. The statement information table has four fields: a source program statement number 5170, an abstract object program instruction address 5171, a machine language program instruction address 5172, and a breakpoint setting flag 5173. For example, in the entry 5174, the statement of statement number 10 of the source program becomes an instruction located at the address “0000060” in the abstract object program, and becomes an instruction located at the address “0000040” in the machine language program. Indicates that a breakpoint has been set.

  The variable information table has five fields of a variable name 5175, a variable type 5176, a type 5177, a line number 5178, and a machine language address 5179. The variable name 5175 indicates the variable name in the source program, the variable type 5176 indicates the local variable / global variable, the type 5177 indicates the data type of the variable, and the statement number 5178 indicates the position in the source program where the variable is declared. The machine language address 5179 indicates address information of the variable on the machine language program. In the case of a local variable, an offset from a frame pointer is shown, and in the case of a global variable, an offset from a variable area base address is shown. For example, entry 5180 indicates that the variable i is a local variable, the type is int, it is located at statement number 4 of the source program, and the offset from the frame pointer is -4 on the machine language program. .

  As can be seen from the above description, the debug system of the present embodiment includes an installer that converts a model-independent abstract object program into an executable machine language program. This has the effect that debugging can be performed.

  By using the installer of the present invention, it is possible to provide a system in which an abstract object program is supplied by an IC card or a CD-ROM or the like and can be immediately executed without depending on a machine. For example, by installing a game program in an IC card and installing an installer in each machine, the same game can be executed on different machines (IC card devices). Hereinafter, such an embodiment will be described with reference to FIGS.

  FIG. 46 is a block diagram of an IC card device incorporating the installer of the present invention. This IC card device includes a control device 5000, a main storage device 5002, an IC card reading / writing device 5005, a keyboard 5006, and a display device 5007. The control device 5000 has a built-in CPU 5001. The main storage device 5002 includes an installer 5003. The IC card 5008 is connected to an IC card device through an IC card reading / writing device 5005. The program in the IC card is stored in the main storage device as a machine language program 5004 by the installer.

  FIG. 47 is an external view of the IC card device. Input from the user is performed through the keyboard 5006, and a response to the user is displayed on the display device 5007. The IC card is inserted from the IC card insertion slot 5009.

  FIG. 48 is a plan view of the IC card 5008. Data is exchanged between the IC card and the IC card reading / writing device through the contact point 5010. The storage element 5011 stores an abstract object program 5012 to be executed by the IC card device and data 5013.

  FIG. 49 is a flowchart for executing the abstract object program built in the IC card. First, the IC card 5008 is inserted into the IC card insertion slot 5009 (step 5020), and the abstract object program and data contained in the IC card are read (step 5021). Next, the control unit 5000 starts the installer with the read abstract object program as an input (step 5022). As a result, an executable machine language program 5004 is created in the main storage device, and the program is executed (step 5023). As a result of the execution, if necessary, the result data is written into the IC card (step 5024), the card is returned (step 5025), and the process is terminated.

  FIG. 50 is a diagram showing a state in which an abstract object program in the same IC card is executed between IC card devices having different CPUs. Here, an IC card device A and an IC card device B each including a CPU-A 5038 and a CPU-B 5039 having different instruction systems in the control device are used as examples. When used in the IC card device A, the abstract object program in the IC card 5008 is converted by the installer A5034 into a machine language program A5036 consisting of the machine language of the CPU-A. On the other hand, when used in the IC card device B, it is converted into a machine language program B5037 consisting of the machine language of the CPU-B by the installer B5035.

  In this embodiment, an IC card is used as a medium for storing an abstract object program. However, the present invention is not limited to this, and can be applied to a system using a CD-ROM or a floppy (registered trademark) disk.

  FIG. 51 is an embodiment showing the sharing of an ArmCode program on a heterogeneous computer connected to a network.

  A file server 1102 and an execution computer system (here, a computer system A 1103 and a computer system B 1104) are connected to the network medium 1101.

  A disk device 1105 is connected to the file server, and the file server 1102 provides a file on the disk device 1105 to the execution computer.

  Each execution computer system accesses a file on the disk device 1105 using its own remote file management program (1106, 1107). Further, each execution computer system includes an installer (1108, 1109) for converting an ArmCode program into a machine language program of each model.

  When executing the ArmCode program 1110 on the disk device 1105 in each execution computer system, the computer system A 1103 converts the ArmCode program 1110 obtained through the remote file management program 1106 into a machine language program 1111 by the installer 1108, and executes the program. . Similarly, the computer system B generates a machine language program 1112 and executes it.

  As described above, the same ArmCode program 1110 can be executed by a plurality of types of computers on the network, and the object program can be shared.

In a conventional system, object programs cannot be shared between different models, and it is necessary to maintain an object program having the same function for each model. For a certain function, the following merits arise by unifying the object program file required for each model into the ArmCode program file as described above.
(1) The file capacity of the entire network is reduced.
(2) Bug fixes and function enhancements only need to be performed for ArmCode programs.
Since it is not necessary to perform this for a plurality of object programs at the same time, the trouble of version control of the object programs is greatly reduced.

  FIG. 52 shows an embodiment in which a computer system operated by the ArmCode program is replaced with another computer system.

  In the computer system A1201, ArmCode is used as a storage format on the disk device 1202 for a machine language program running thereon. That is, when a certain function is realized by the computer system A 1201, the ArmCode program 1204 on the disk device 1202 corresponding to the function is converted into a machine language program 1205 by the installer 1203 and executed.

  Such a computer system can be easily replaced with another computer system having an installer.

  The computer system B 1206 includes an installer 1208, and can convert an ArmCode program on the disk device 1207 into a machine language program and execute it. In order to replace the computer system A 1201 with the computer system B 1206, it is only necessary to copy the ArmCode program 1204 on the disk device 1202 to the disk device 1207. That is, when a certain function realized by the computer system A 1201 is realized in the computer system B 1206, the copied ArmCode program 1204 on the disk device 1207 corresponding to the function is converted into a machine language program 1209 by the installer 1208. Convert and execute.

As described above, the use of ArmCode as a program storage format on a disk has the following advantages.
(1) It is possible for the user to reduce the time and effort required for migrating the computer, such as recompiling the source program and recreating the program, thereby reducing the time required for migration.
(2) For the manufacturer, the machine language can be set without being aware of the portability,
Computer systems can be designed in a direction that maximizes the performance of the system.

Machines that can be executed on each computer with different specifications by optimizing the process of compiling source programs into machine language programs using an intermediate format (object program) common to multiple types of computers It is possible to generate a language program and its usefulness is high.

FIG. 1 is a diagram showing a configuration of an embodiment of a system for translating a source program into a machine language program according to the present invention. FIG. 3 is a diagram showing a configuration of a compiler that generates an abstract object program as a sequence of abstract register machine instructions from a source program. FIG. 4 is a diagram illustrating a relationship between an abstract register machine instruction and a machine language. FIG. 11 is a diagram illustrating types of generation control statements included in an abstract register machine instruction. FIG. 4 is a diagram showing a format of each abstract register machine instruction. FIG. 4 is a diagram showing a relationship between an address mode and an operand of an abstract register machine instruction. FIG. 11 is a diagram (part 1) illustrating specifications of a machine language generation instruction included in an abstract register machine instruction. FIG. 11 is a diagram (part 2) illustrating specifications of a machine language generation instruction included in an abstract register machine instruction. FIG. 10 is a diagram (part 3) illustrating the specifications of the machine language generation instruction included in the abstract register machine instruction. FIG. 14 is a diagram (part 4) illustrating specifications of a machine language generation instruction included in an abstract register machine instruction. FIG. 15 is a diagram (part 5) illustrating the specifications of the machine language generation instruction included in the abstract register machine instruction. FIG. 15 is a diagram (part 6) illustrating the specifications of the machine language generation instruction included in the abstract register machine instruction. FIG. 3 is a diagram illustrating an example of a source program that is input to the compiler of FIG. 2; FIG. 14 is a diagram (part 1) illustrating an example of generation of an abstract object program corresponding to the source program of FIG. 13, which has not been optimized yet; FIG. 14 is a diagram (part 2) illustrating an example of generation of an abstract object program corresponding to the source program of FIG. 13, which has not been optimized yet; FIG. 14 is a diagram (part 3) illustrating an example of generation of an abstract object program corresponding to the source program of FIG. 13, which has not been optimized yet; FIG. 17 is a diagram illustrating a process of calculating the priority of register allocation in the abstract object program of FIGS. 14 to 16; 4 is a flowchart showing a priority bit vector creation procedure in the compiler of FIG. 4 is a flowchart showing a process of deleting a common expression in the optimization processing in the compiler of FIG. FIG. 14 is an example of an abstract object program corresponding to the source program of FIG. 13 and is a diagram (part 1) illustrating an abstract register machine instruction sequence after performing an optimization process. FIG. 14 is an example of an abstract object program corresponding to the source program of FIG. 13 and is a diagram (part 2) illustrating an abstract register machine instruction sequence after performing an optimization process. This is a flowchart of a process for moving an invariable expression in a loop in the optimization process. FIG. 3 is a diagram illustrating the use of each physical register in a model A. FIG. 3 is a diagram illustrating correspondence between an abstract register and a physical register. It is a figure showing conversion to a machine language by pattern collation. FIG. 6 is a diagram illustrating a part of a machine instruction selection rule for a model A. FIG. 22 is a diagram illustrating a physical register allocation state in the model A for the abstract object program of FIGS. 20 to 21. FIG. 22 is a diagram showing an example of a machine language program generated by the installer for model A from the abstract object program of FIGS. 20 to 21. This is a flowchart showing the internal processing of the installer. It is a figure showing the structure and input / output of an installer. The figure shows the use of each physical register in model B. FIG. 22 is a diagram illustrating a physical register allocation status in the model B for the abstract object program of FIGS. FIG. 6 is a diagram illustrating a part of a machine instruction selection rule for a model B. FIG. 21 is a diagram illustrating a physical register allocation state in the model B for the abstract object program of FIGS. FIG. 21 is a diagram illustrating an example of a machine language program generated by the installer for model B from the abstract object program of FIGS. 19 and 20. It is a block diagram of a debugging system to which the installer of the present invention is applied. 6 is a flowchart illustrating an operation of the debugger. It is a figure showing an example of a display command. It is a flowchart of a display process. It is a figure showing the example of a breakpoint setting command. It is a flowchart of a breakpoint setting process. It is a figure showing an example of an execution command. It is a flowchart of an execution process. FIG. 4 is a diagram illustrating an example of a source program to be debugged. It is a figure showing an example of a source / abstract object / machine language correspondence table. FIG. 2 is a block diagram of an IC card device incorporating the installer of the present invention. It is an external view of an IC card device. It is a top view of an IC card. 5 is a flowchart for executing an abstract object program stored in an IC card. FIG. 3 is a diagram illustrating a state in which a program in the same IC card is executed between IC card devices having different CPUs. FIG. 11 is a diagram illustrating an example of sharing of an ArmCode program on a heterogeneous computer connected to a network. FIG. 10 is a diagram illustrating an example of replacing a computer system operated by an ArmCode program with another computer system.

Explanation of reference numerals

1001 Compiler 1002 Linker 1003 Installer of Computer A 1004, 1006, 1013 Source program
1005, 1007, 1014 ArmCode program (abstract object program)
1008 ArmCode program library 1009 Combined ArmCode program 1010 Specification information 1011 of computer A Machine language program 1012 of computer A Computer A
1015 Installer of computer B 1016 Machine language program of computer B 1017 Computer B
1018 Specification information of computer B 3100 Compiler 3102 Source program 3104 Syntax / semantic analysis unit 3106 Intermediate language 3108 Symbol table 3110 Intermediate language optimization unit 3112 ArmCode before optimization
3114 Abstract register instruction optimization unit 3116 Abstract object program as abstract register machine instruction sequence

Claims (6)

A compiler that is executed by a computer having a CPU and a memory, and converts a source program into an abstract object program that is independent of a model of a target computer and includes an instruction sequence for an abstract register machine that defines a plurality of abstract registers. In the compiler to translate,
Means for performing the optimization process for the abstract register machine to generate the abstract object program;
Means for causing the abstract object program to include a generation control instruction used for optimization processing when converting the abstract object program into a machine language program;
A compiler comprising:   2. The compiler according to claim 1, wherein the generation control instruction sets the priority of register allocation to one of operands.   3. The compiler according to claim 2, wherein the priority of the register allocation is based on a position where an abstract register machine instruction using a target abstract register appears. An installer executed by a computer having a CPU, a memory, and a plurality of real registers,
Means for receiving an abstract object program in the form of an intermediate language program that does not depend on the type of a computer, the abstract object program having a generation control instruction used for optimization processing when converting the program into a machine language program;
Means for generating a machine language program by performing optimization processing for the computer with reference to the generation control instruction included in the received abstract object program.   5. The installer according to claim 4, wherein the generation control instruction sets the priority of register allocation to one of operands. 6. The installer according to claim 5, wherein the register allocation priority is determined according to a position where an abstract register machine instruction using the target abstract register appears.

Images