US20040194071A1 - Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method - Google Patents

Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method Download PDF

Info

Publication number
US20040194071A1
US20040194071A1 US10/819,595 US81959504A US2004194071A1 US 20040194071 A1 US20040194071 A1 US 20040194071A1 US 81959504 A US81959504 A US 81959504A US 2004194071 A1 US2004194071 A1 US 2004194071A1
Authority
US
United States
Prior art keywords
register
variable
program
unit
compiling
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.)
Abandoned
Application number
US10/819,595
Inventor
Akira Tanaka
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US10/819,595 priority Critical patent/US20040194071A1/en
Publication of US20040194071A1 publication Critical patent/US20040194071A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/441Register allocation; Assignment of physical memory space to logical memory space

Definitions

  • the present invention relates to a compiling device translating a source program into an object program such as a machine language program or an assembler program, and in particular, to improvements achieved when the source program includes a section written in high-level programming language and a section written in assembly language.
  • the microprocessor targeted by the compiler uses a load/store method (a method in which addressing of operands is performed using only transfer instructions as memory-to-memory calculation instructions), and a division instruction div is as shown in FIG. 1D.
  • the division result is stored in a register rn, and a result of remainder calculation in a register mdr. This means that the division instructions used in a majority of microprocessors can perform division and remainder calculation simultaneously using one instruction.
  • registers r 2 , r 3 , r 4 and r 5 are allocated to variables a, b, c and d respectively, and ‘mov rm, rn’ signifies that the value in register rm is to be transferred to register rn.
  • FIG. 1 may be written as assembler statements following the keyword asm, as shown in FIG. 2.
  • parts of the asm statements written using variables at a level equivalent to C may be written into registers and memory allocated by the compiler. For example, if registers r 2 , r 3 , r 4 and r 5 are allocated to variables a, b, c and d respectively, as in FIG. 1, the output of the compiler is as shown in FIG. 2B.
  • FIG. 2B has two more transfer instructions than the ideal situation of FIG.
  • FIG. 3A shows a situation in which a microprocessor targeted by a C language compiler replaces x, y, z and w with a, b, c and d, as in FIG. 2A. Replacement of variables by a C compiler in this way is known as macro generation.
  • Descriptors that are macro-defined assembler statement sequences having a special function, such as dm in FIG. 3A, are known as ‘inline assembly routines’.
  • the program includes a plurality of variables.
  • the first check operation involves thoroughly checking the object program generated by the compiler to determine whether the value of the variable x has been destroyed.
  • a register r is allocated to the variable x by a process performed by the compiler, so that if the inline assembly routine defines the register r, the value of the register r will differ before and after the inline assembly routine.
  • variable a a value for a variable a defined at definition point ( 1 ) is used at use point ( 2 ) and variable a has a live range which extends over the inline assembly routine dm.
  • a register r 1 is allocated to the variable a, and if the value of register r 1 is changed during the inline assembly routine dm, a value of a which differs from that defined at definition point ( 1 ) will be used at use point ( 2 ) in FIG. 3C.
  • the programmer makes a careful check to determine whether values of parameters have been destroyed, after determining how such values are defined by the inline assembly routine.
  • values are transferred using specified registers r.
  • the live ranges of such parameters may extend over the inline assembly routine.
  • a register r is defined by the inline assembly routine, the value of the parameter will be different before and after the inline assembly routine. For example, if, as in FIG. 3D, a parameter p is referenced after the use point of the inline assembly routine dm, and the parameter p is passed to a register r 0 , it is clear that the value of the register r 0 will be destroyed by the inline assembly routine dm, and the value used when the parameter p is referenced will be inaccurate.
  • a first object of the present invention is to provide a compiling device that translates a program without requiring the programmer to make checks when an inline assembly routine is used.
  • a second object of the present invention is to provide a compiling device that translates a program so as to enable inline assembly routines to be inserted as black boxes.
  • a third object of the present invention is to provide a compiling device enabling inline assembly routines to be changed to library routines, thereby increasing the reusability of the program.
  • the present invention is a compiling device that translates a program including statements using variables into an object instruction sequence. Assembler instructions defining values for resources are arranged in a section of the program.
  • the compiling device includes a variable detecting unit for detecting variables whose live ranges overlap the section from variables having values defined in the statements, and a resource allocating unit for allocating to each variable detected by the variable detecting unit, a resource different from the resources having values defined in the assembler instructions.
  • the program may be embodied by a plurality of functions, the statements are included in the functions, and assembler instructions are included at least one of the functions.
  • the compiling device further includes a register parameter replacing unit that, when formal parameters that should use registers exist, (1) generates substitution instructions for substituting temporary variables for the values of each formal parameter used in the functions, and inserts each of the generated substitution instructions at the start of a corresponding function, and (2) replaces all of the formal parameter values in the functions with the temporary variables indicated by the substitution instructions.
  • the variable detecting unit detects temporary variables whose live ranges overlap the section; and the resource allocating unit allocates a register different from the registers whose values are defined in the assembler instructions to each detected temporary variable.
  • inline assembly routines can be freely defined, and used as a black box at an arbitrary position in the program. Using inline assembly routines actively in this way improves the execution speed and reusability of the program.
  • the variable detecting unit may also include a detecting unit for detecting assembler instructions from the program, a temporary variable generating unit for generating, when assembler instructions are detected, temporary variables already allocated to resources defined in the assembler instructions, a live range setting unit setting the live range of each generated temporary variable to be equal to the section where the assembler instructions are arranged; and a variable detecting unit detecting variables whose live range overlaps the live range set for the temporary variables.
  • the resource allocating unit allocates a resource different from the resources allocated to the temporary variables to each of the detected variables.
  • Allocated temporary variables are generated from the assembler statements, and resource allocation is performed using a method that integrates these generated temporary variables.
  • the resource allocation method disclosed in reference 2 which actively limits the generation of transfer instructions
  • the resource allocation method disclosed in reference 3 which is an expansion method of the widely known graph coloring technique, may be applied.
  • FIG. 1 shows an example program, a corresponding assembler program, a comparative assembler program, and an illustration of a division instruction
  • FIG. 2 shows an example asm statement sequence, and corresponding assembler program
  • FIG. 3 shows examples of inline assembly routine definitions and inline assembly routine uses
  • FIG. 4 is a block diagram of a compiling device 1 in a first embodiment
  • FIG. 5 is a flowchart of processing performed by a register parameter replacing unit 16 ;
  • FIG. 6 is a flowchart showing the procedure performed by an asm register detecting unit 17 ;
  • FIG. 7 is a flowchart showing the procedure performed by a resource allocating unit 14 ;
  • FIG. 8 shows an example of a program written in a high-level programming language
  • FIG. 9 shows a program after execution performed by a macro expanding unit 11 ;
  • FIG. 10 shows an intermediate program after execution performed by a syntax analyzing unit 12 ;
  • FIG. 11 shows an intermediate program after execution performed by the register parameter replacing unit 16 ;
  • FIG. 12 shows an intermediate program and live ranges corresponding to an example program
  • FIG. 13 shows an example of content held in asm defining register holding units 18 and 28 ;
  • FIG. 14 is a block diagram of a compiling device 2 in a second embodiment
  • FIG. 15 is a flowchart showing the procedure performed by an asm live range generating unit 29 ;
  • FIG. 16 is a flowchart showing the procedure performed by a resource allocating unit 24 ;
  • FIG. 17 shows an intermediate program and live ranges corresponding to a program after execution performed by an asm live range generating unit 29 ;
  • FIG. 18 shows a basic data structure for expressing live ranges
  • FIG. 19 shows an interference graph for variables corresponding to the live ranges shown in FIG. 17.
  • Japanese Patent Application No. 10-344524 A Resource Allocation Apparatus and A Computer-Readable Recording Medium on which a Resource Allocating Program as Recorded. Akira Tanaka.
  • a variable generated by the compiler to temporarily store a calculation result, thereby simplifying processing, is known as a ‘temporary variable’.
  • the following explanation treats such variables in the same way as variables written in a standard source program, unless a particular distinction needs to be made.
  • the compiler converts source program code into code known as ‘intermediate code’, and one step of the intermediate code is known as an ‘intermediate instruction’.
  • Intermediate instructions are for example quadruples or triples, and are converted to generate a final object program.
  • the source program is converted to a sequence of intermediate instructions, these are known collectively as an ‘intermediate program’.
  • FIG. 10 shows one example of an intermediate program corresponding to the program in C shown in FIG. 9. This program is expressed in three address code, which is one of the quadruples.
  • references i 1 , i 2 and the like, formed from ‘i’ and an attached number represent identifiers (names) of intermediate instructions.
  • the asm statements of FIG. 9, ( 1 ) are converted into intermediate instructions (FIG. 10, ( 1 ) having the same format as FIG. 9, ( 1 ).
  • the intermediate instructions for the asm statements in FIG. 10 ( 1 ) will be known as ‘asm intermediate instructions’.
  • intermediate instructions having other formats may also be used in addition to the format shown here.
  • the intermediate program is also equipped with intermediate instructions showing specified program ranges, such as intermediate instructions indicating the start and end of the intermediate program and the start and end of functions. In FIG. 10, for example, intermediate instructions i 50 and i 51 show the start and end of a function.
  • Live ranges are sections during which values stored in each variable are valid, each live range actually representing the section of a program from an intermediate instruction defining a value for a variable until an intermediate instruction which last references the defined value. Consequently, a live range can be expressed by the set of intermediate instructions included in this section.
  • the intermediate instruction defining the value for the variable corresponds to the start point of the live range and the intermediate instruction last referencing the defined value to the end point of the live range.
  • the areas occupied by the intermediate instruction sets are used to determine whether live ranges overlap. Thus, when the end point of one live range is identical to the start point of another live range, the two live ranges do not overlap.
  • FIG. 12B shows examples of live ranges. In the drawing, live ranges are represented by solid vertical lines.
  • FIG. 18 shows the actual structure of data representing the live ranges in FIG. 12B, with the live range of each variable shown by an intermediate instruction set.
  • the symbol ‘. . . ’ shown in various live ranges indicates the presence of an intermediate instruction not shown in the drawing.
  • Live ranges may also be referred to as ‘lifetimes’ or ‘extents’. A more detailed definition and actual examples of live ranges are given in references 1 and 2 .
  • registers and memory are hereafter referred to collectively as ‘resources’.
  • FIG. 4 is a block diagram of a compiling device 1 in a first embodiment.
  • the compiling device 1 is formed from the main components of a conventional compiler, such as a macro expanding unit 11 , a syntax analyzing unit 12 , an optimizing unit 13 , a resource allocating unit 14 , and a code generating unit 15 , along with a register parameter replacing unit 16 , an asm register detecting unit 17 , and an asm register holding unit 18 which bear a particular relationship to this embodiment.
  • a conventional compiler such as a macro expanding unit 11 , a syntax analyzing unit 12 , an optimizing unit 13 , a resource allocating unit 14 , and a code generating unit 15 , along with a register parameter replacing unit 16 , an asm register detecting unit 17 , and an asm register holding unit 18 which bear a particular relationship to this embodiment.
  • the macro expanding unit 11 is the first component to be activated by the compiling device 1 , and replaces macro-defined macro identifiers with their actual content. This processing is basically the same as that performed by a conventional C compiler, so explanation here is limited to describing an example processing result.
  • FIG. 8 shows an example source program.
  • a macro identifier dm (x,y,z,w) that macro-defines an inline assembly routine that performs division and remainder calculation as described in the background art, and a function f that uses this dm are shown.
  • the part of the function f relevant to the explanation given in this embodiment has been extracted and written in the drawing.
  • FIG. 9 shows an intermediate program resulting from processing of the source program of FIG. 8 performed by the macro expanding unit 11 . As shown in FIG. 9 ( 1 ), the macro identifier dm is replaced by the macro-defined inline assembly routine.
  • FIG. 9, ( 1 ) is composed of five assembler instructions: mov a,r 0 , mov b,r 1 , div r 1 ,r 0 , mov r 0 ,c and mov mdr,d.
  • the keyword asm is attached to the front of each of these instructions.
  • This asm keyword signifies that the statement shown between the keyword and a concluding semi-colon includes an assembler instruction.
  • This kind of statement is known as an assembler statement.
  • Such statements indicate to the compiling device 1 that translation processing equivalent to that used for the sections of the program written in a high-level programming language is not necessary.
  • the syntax analyzing unit 12 and the optimizing unit 13 in the compiling device 1 skip processing of statements that start with the keyword asm.
  • the syntax analyzing unit 12 is activated, and performs lexical analysis, syntax analysis and semantic factoring, thereby converting the source program to an intermediate program.
  • the source program of FIG. 9 is converted to the intermediate program shown in FIG. 10.
  • the operation of the syntax analyzing unit 12 is not the focus of this embodiment and so a more detailed description is omitted.
  • assembler statements which have had a keyword asm attached and been expanded inside the source program by the macro expanding unit 11 are inherited directly by the converted intermediate program without being changed into different code by the syntax analyzing unit 12 . This means that assembler statements having the attached keyword asm exist in the intermediate program as intermediate instructions.
  • the optimizing unit 13 optimizes the intermediate program so as to minimize the size and processing time of the object program finally generated by the compiling device 1 .
  • the operation of the optimizing unit 13 is not the focus of this embodiment and so a detailed description is omitted, with only those points relevant to the embodiment being explained.
  • the optimizing unit 13 performs basic block analysis, control flow analysis and data flow analysis.
  • Basic block analysis is performed by dividing the intermediate program into basic blocks.
  • control flow analysis is performed by analyzing the control flow between basic blocks.
  • data flow analysis is performed by analyzing where each variable is defined and referenced within each basic block.
  • the resource allocating unit 14 uses the results of this analysis to calculate live ranges. Note that when register parameters are included in the program to be translated, the optimizing unit 13 is activated following activation of the register parameter replacing unit 16 . Here, optimization performed by the optimizing unit 13 enables assembler statements having an attached keyword asm to be inherited directly by the intermediate program without being replaced by a different code, and without being deleted.
  • the register parameter replacing unit 16 is activated if register parameters are included in the program that is to be translated.
  • the register parameter replacing unit 16 inserts, at the start of a function, an intermediate instruction storing, as a temporary variable, a value of a formal parameter passed to the register. Further to this, the register parameter replacing unit 16 replaces the sections of the intermediate program in which the formal parameter is used with the temporary variables.
  • FIG. 5 is a flowchart showing the processing performed by the register parameter replacing unit 16 .
  • the register parameter replacing unit 16 repeats the processing of steps a 2 to a 5 for all formal parameters p, and when all the formal parameters p have been processed, the processing performed by the register parameter replacing unit 16 is completed.
  • step a 2 if a formal parameter p has been passed to a register, the register parameter replacing unit 16 performs steps a 3 and a 4 .
  • step a 4 the register parameter replacing unit 16 inserts the generated intermediate instruction i at the start of the function.
  • the register parameter replacing unit 16 replaces all the sections of the intermediate program where the formal parameter p is used with the temporary variable t, and returns to step a 1 .
  • FIG. 11 shows the result of processing performed by the register parameter replacing unit 16 on the intermediate program in FIG. 10.
  • the register parameter replacing unit 16 fetches a formal parameter p passed to a register (steps a 1 and a 2 ), generates an intermediate instruction i 20 indicating that the formal parameter p should be replaced by a temporary variable t 2 (step a 3 ), inserts the intermediate instruction i 20 at the start of the intermediate program (step a 4 ), and replaces the parts of intermediate instructions i 1 and i 9 that use the formal parameter p with the temporary variable t 2 (step a 5 ).
  • the resource allocating unit 14 allocates different registers to each of a plurality of variables having overlapping live ranges.
  • the resource allocating unit 14 activates the asm register detecting unit 17 before commencing its own processing.
  • the asm register detecting unit 17 detects registers defined in the assembler statements, and stores the detection result in the asm register holding unit 18 .
  • FIG. 6 is a flowchart showing the processing performed by the asm register detecting unit 17 .
  • step b 1 the asm register detecting unit 17 performs the processing of steps b 2 and b 3 for all of the intermediate instructions i. Once processing has been performed for all of the intermediate instructions i, the processing performed by the asm detecting unit 17 is completed.
  • step b 2 when the intermediate instruction i is an asm intermediate instruction, the asm register detecting unit 17 performs the processing of step b 3 .
  • processing returns to step b 1 .
  • the asm register detecting unit 17 stores the intermediate instruction i and the register r in the asm register holding unit 18 , and processing returns to step l.
  • FIG. 13 shows the content held by the asm register holding unit 18 corresponding to the intermediate program shown in FIG. 11. Registers defined in each asm intermediate instruction are held. For example, in the asm intermediate instruction i 3 in FIG. 11, a value of the variable a is transferred to a register r 0 , thereby defining the register r 0 , so that the register defined by the asm intermediate instruction i 3 is set as r 0 (step b 3 ).
  • the resource allocating unit 14 uses control flow information and data flow information analyzed by the optimizing unit 13 to calculate live ranges for all variables, including the temporary variables generated by the register parameter replacing unit 16 .
  • the method used to calculate live ranges is the same as that explained in detail in references 1 and 2 and the like, and so explanation is here confined to showing the calculation result of live ranges for the intermediate program shown in FIG. 11. This calculation result is shown in FIG. 12.
  • a live range is expressed conventionally as a set of intermediate instructions, as in reference 2 , but here the extent of each live range is represented by a solid line to make it conceptually easier to understand.
  • the reference (r 0 ) written next to the live range for the formal parameter p signifies that register r 0 is allocated to the formal parameter p.
  • the resource allocating unit 14 allocates resources to variables, including the temporary variables generated by the register parameter replacing unit 16 . Specifically, when allocating resources to a variable, the resource allocating unit 14 allocates registers that are not allocated to variables with overlapping live ranges and that are not among registers defined by an asm intermediate instruction that have been obtained from the asm register holding unit 18 . The latter condition applies only if asm statements are included in the live range of the variable.
  • FIG. 7 is a flowchart showing the processing performed by the resource allocating unit 14 .
  • step c 1 the resource allocating unit 14 repeats the processing of steps c 2 to c 6 for all variables v that have not yet been allocated a resource, and once all variables v have been allocated a resource, the processing performed by the resource allocating unit 14 is completed.
  • the resource allocating unit 14 determines a register set R 1 , containing registers allocated to variables whose live ranges overlap with the live range of a variable v.
  • the resource allocating unit 14 detects registers defined by all the asm intermediate instructions included in the live range of the variable v from the asm register holding unit 18 , thereby determining a register set R 2 .
  • step c 4 the resource allocating unit 14 determines whether a register r which is not included in either register set R 1 or register set R 2 exists. If such a register exists, the processing of step c 5 is executed, if such a register does not exist, the processing of step c 6 is executed.
  • step c 5 the resource allocating unit 14 allocates the register r to the variable v, and processing returns to step c 1 .
  • step c 6 the resource allocating unit 14 allocates memory to the variable v, and processing returns to step c 1 .
  • registers r 0 , r 1 and mdr defined in these asm intermediate instructions are fetched (step c 2 ).
  • a register that is not included in either of the register sets R 1 and R 2 , for example register r 2 is allocated to the variable a (step c 4 , c 5 ).
  • a register set R 1 containing registers allocated to variables t 1 , a, b, c, d and e whose live ranges overlap with that of the variable t 2 is determined.
  • the variables t 1 , b, c, d and e have not yet been allocated resources, and the variable a is allocated to the register r 2 as was previously described.
  • register r 2 is fetched from the register set R 1 (step c 2 ).
  • each of the asm intermediate instructions i 3 to i 7 included in the live range for variable t 2 is referenced in the asm register holding unit 18 of FIG.
  • registers r 0 , r 1 and mdr defined in these variables are fetched (step c 2 ).
  • the compiling device 1 activates the code generating unit 15 , and converts the intermediate instructions into an object program formed from assembler statements and machine language instructions for a machine targeted by the compiler.
  • the code generating unit 15 uses a conventional method and so detailed explanation is omitted here.
  • variables which are live for the extent of the asm statements such as variables a and t 2 in FIG. 12, are not allocated registers defined in the asm statements in steps c 3 to c 5 performed by the resource allocating unit 14 .
  • the first check operation mentioned in the Background Art section is no longer required.
  • a temporary variable t 2 is generated by the register parameter replacing unit 16 in steps a 2 to a 5 , and registers defined in the asm statements are not allocated to the variable t 2 in steps c 3 to c 5 performed by the resource allocating unit 14 . This means that the second check operation described in the Background Art section is not required.
  • the programmer can freely define inline assembly routines, and use such routines as black boxes at arbitrary points in the program. This greatly reduces the burden of checks placed on the programmer when using inline assembly routines, and also allows inline assembly routines to be changed to library routines, improving the reusability of the program.
  • step a 4 of the flowchart showing the processing performed by the register parameter replacing unit 16 the generated intermediate instruction i is inserted at the start of the function, but it may also be inserted at a point in the program prior to referencing of the formal parameter p.
  • FIG. 14 is a block diagram showing a compiling device 2 in a second embodiment.
  • the compiling device 2 is formed from the main components of a conventional compiler, in other words a macro expanding unit 21 , a syntax analyzing unit 22 , an optimizing unit 23 , a resource allocating unit 24 , and a code generating unit 25 , along with a register parameter replacing unit 26 , an asm register detecting unit 27 , an asm register holding unit 28 , and an asm live range generating unit 29 , that bear a particular relationship to this embodiment.
  • the compiling device 2 activates the macro expanding unit 21 , the syntax analyzing unit 22 , and the optimizing unit 23 in the same way as the compiling device 1 in the first embodiment.
  • the macro expanding unit 21 , the syntax analyzing unit 22 , the optimizing unit 23 and the register parameter replacing unit 26 in FIG. 14 are the same as the macro expanding unit 11 , the syntax analyzing unit 12 , the optimizing unit 13 and the register parameter replacing unit 16 of FIG. 4 explained in the first embodiment. Therefore, the following explanation focuses on the resource allocating unit 24 , the asm register detecting unit 27 , and the asm live range generating unit 29 .
  • An intermediate program generated for the example program shown in FIG. 8 resembles the one in FIG. 11 up until the end of processing performed by the optimizing unit 23 .
  • the asm register detecting unit 27 has the same construction as the asm register detecting unit 17 of the first embodiment, and is the first component to be activated by the resource allocating unit 24 . If the asm register detecting unit 17 performs detection processing on the example program shown in FIG. 11, the content shown in FIG. 13 is set in the asm register holding unit 28 .
  • the resource allocating unit 24 uses the control flow information and data flow information analyzed by the optimizing unit 23 to calculate the live ranges of all of the variables.
  • the result of processing performed on the example in FIG. 11 is the same as that explained in the first embodiment with reference to FIG. 12.
  • FIG. 15 is a flowchart showing the processing performed by the asm live range generating unit 29 .
  • step d 1 the asm live range generating unit 29 repeats steps d 2 to d 5 for all of the asm intermediate instructions i. Once all the intermediate instructions i have been processed, the processing performed by the asm live range generating unit 29 is completed.
  • step d 2 if a register r defining a asm intermediate instruction i is found to exist in the asm register holding unit 28 , the asm live range generating unit 29 performs steps d 3 to d 5 , and if such an intermediate instruction is not found, processing returns to step d 1 .
  • step d 3 the asm live range generating unit 29 generates a new temporary variable s.
  • the asm live range generating unit 29 generates a live range which starts and ends with asm intermediate instructions for the temporary variable s.
  • step d 5 the asm live range generating unit 29 allocates a register to the generated variable s, and processing then returns to step d 1 .
  • FIG. 17B shows the live ranges of each variable following the performance of processing by the asm live range generating unit 29 .
  • the drawing further includes temporary variables s 1 , s 2 and s 3 , to which registers have been allocated, with corresponding live ranges.
  • the asm intermediate instruction i 3 includes a temporary variable s 1 , which is allocated the register r 0 defined in the asm intermediate instruction i 3 .
  • a live range which covers only the asm intermediate instruction i 3 is generated for the temporary variable s 1 .
  • FIG. 16 is a flowchart showing the processing performed by the resource allocating unit 24 .
  • step e 1 the resource allocating unit 24 repeats the processing of steps e 2 to e 5 for all variables v that have not yet been allocated resources. Once all variables v have been processed, the processing performed by the resource allocation unit 24 is completed.
  • the resource allocating unit 24 determines a register set R, containing registers allocated to variables having live ranges which overlap with that of variable v.
  • the resource allocating unit 24 determines whether a register r, which does not belong to the register set R found at step e 2 , exists. If such a register exists, the resource allocating unit 24 executes step e 4 ; if not, it executes step e 5 .
  • step e 4 the resource allocating unit 24 allocates the register r to the variable v, and processing returns to step e 1 .
  • step e 5 the resource allocating unit 24 allocates memory to the variable v, and processing returns to step e 1 .
  • Variables t 1 , a, b, c, d, e, s 1 , s 2 , and s 3 have live ranges which overlap with that of the variable t 2 .
  • the variables a, s 1 , s 2 and s 3 have been allocated the registers r 2 , r 1 , r 0 and mdr, so the variable t 2 is allocated a different register, for example register r 3 .
  • the compiling device 2 activates the code generating unit 25 , and converts intermediate instructions into an object program including assembler statements and machine language instructions for a machine targeted by the compiling device 2 .
  • the code generating unit 25 uses a conventional method and so is not described in detail here.
  • variables such as a and t 2 in FIG. 17, that are live for the entire span of the asm statements are not allocated a register that is defined by the asm statements in steps e 3 and e 4 .
  • This effect is achieved by using the temporary variables s 1 , s 2 and s 3 generated by the asm live range generating unit 29 , and removes the need for performing the first check operation described in the Background Art section.
  • the variable t 2 is generated in steps a 2 to a 5 performed by the register parameter replacing unit 16 , and the variable t 2 is not allocated to a register defined in the asm statements in steps e 3 and e 4 performed by the resource allocating unit 24 .
  • the introduction of the temporary variables s generated by the asm live range generating unit 29 and generation of live ranges for these variables enables a conventional resource allocation method, such as the one described in references 1 and 2 , to be applied by the resource allocating unit 24 .
  • the method described in reference 2 may be applied by using the intermediate program and live range information shown in FIG. 17.
  • reference 2 teaches that it is possible to limit the generation of transfer instructions in the object program generated by the compiler to a bare minimum. For example, when the end point of the live range for one variable is identical to the start point of the live range for another variable, as is the case with variables b and s 2 in FIG. 17, these variables are if possible allocated the same register. As a result, the variable b is allocated to register r 1 , and asm intermediate instruction i 4 becomes a transfer within a same register, and so is deleted.
  • the extension method for graph coloring (a widely known technique) disclosed in reference 3 can be applied by constructing an interference graph like that in FIG. 19, showing overlapping live ranges between variables using the live range information of FIG. 17.
  • variables are expressed as nodes, and variables (nodes) having overlapping live ranges are connected by edges.
  • Some of the nodes in the graph have already been colored, that is have already been allocated a register.
  • These are nodes (variables) s 1 , s 2 and s 3 .
  • the method disclosed in reference 3 is a graph coloring method which can use a graph like this one in which some of the nodes have already been colored.
  • the invention is described in relation to a division instruction, but its application is not limited to such instructions, and it may also be applied to advanced instructions for multimedia processing, such as product-sum instructions, other arbitrary instructions using calculations such as the four arithmetic fundamentals, and bit manipulation calculations, or any combination of a plurality of the above-mentioned calculations.
  • FIGS. 5 to 7 and FIGS. 15 and 16
  • the procedure explained in the embodiments with reference to flowcharts is represented using a machine language program, but may equally be represented by recording such a program on a recording medium for distribution and sales.
  • the recording medium may be an IC card, optical disk, floppy disk or similar.
  • the machine language program recorded on such a recording medium is supplied for installation in a general-purpose personal computer.
  • the general-purpose personal computer executes the installed machine language program in sequence, realizing the functions of the compiling device shown in the present embodiments.

Abstract

Formal parameters which are to use registers are replaced with variables generated inside a compiler. Then, if a variable allocated to a register has a live range (lifetime) that includes an inline assembly subroutine, the variable is allocated a register that differs from the registers updated during the inline assembly subroutine.

Description

  • This application is based on an application No. 11-195717 filed in Japan, the content of which is hereby incorporated by reference. [0001]
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0002]
  • The present invention relates to a compiling device translating a source program into an object program such as a machine language program or an assembler program, and in particular, to improvements achieved when the source program includes a section written in high-level programming language and a section written in assembly language. [0003]
  • 2. Description of the Background Art [0004]
  • Recent developments in high-performance integrated microprocessors have led to such microprocessors being used in information processing devices performing multimedia processing such as communication, video processing and audio processing. [0005]
  • The design of programs used in multimedia processing has become increasing unwieldy, so that problems regarding the development cost, maintenance and portability of such programs have multiplied in recent years. Consequently, there is a great demand for developmental environments using high-level programming languages, of which C and C++ have become particularly popular. However, a look at the current state of affairs regarding developmental environments for multimedia processing reveals that multimedia processing is often written using assembly language, which is close to machine language. This seems to go against the prevailing demand for developmental environments written in high-level programming language. Sections of the program that are frequently executed and require a short execution time are written in assembly language. Such sections form the bulk of the mass data processing functions occurring in multimedia processing. [0006]
  • There are several reasons for writing sections of the program in assembly language. First, the translation ability of the compiler is limited. In addition, microprocessors have some machine language instructions which achieve a plurality of functions. Such instructions are increasingly found as multimedia processing instructions, and cannot be efficiently written in high-level programming language, nor be efficiently translated into machine language instructions by the compiler. [0007]
  • Suppose that the microprocessor targeted by the compiler uses a load/store method (a method in which addressing of operands is performed using only transfer instructions as memory-to-memory calculation instructions), and a division instruction div is as shown in FIG. 1D. In FIG. 1D, the division result is stored in a register rn, and a result of remainder calculation in a register mdr. This means that the division instructions used in a majority of microprocessors can perform division and remainder calculation simultaneously using one instruction. [0008]
  • In contrast, when the high-level programming language C is used, and the division and remainder results of variables a and b are to be set respectively as variables c and d, this process can only be written as shown in FIG. 1A. As a result, many compilers generate separate div instructions for each of ‘/’ calculation and ‘%’ calculation, as shown in FIG. 1B, ([0009] 1) and (2). Conventionally, execution of a div instruction requires a greater number of execution cycles than other instructions, so that ideally only one div instruction should be used to perform simultaneous division and remainder calculation, as shown in FIG. 1D. In FIGS. 1B and 1D, registers r2, r3, r4 and r5 are allocated to variables a, b, c and d respectively, and ‘mov rm, rn’ signifies that the value in register rm is to be transferred to register rn.
  • Consequently, in the case of most C compilers, a programmer uses asm statements as extended language specifications, so that program description written in C is mixed with description written in assembly language. The example program sections shown in FIG. 1 may be written as assembler statements following the keyword asm, as shown in FIG. 2. Here, parts of the asm statements written using variables at a level equivalent to C may be written into registers and memory allocated by the compiler. For example, if registers r[0010] 2, r3, r4 and r5 are allocated to variables a, b, c and d respectively, as in FIG. 1, the output of the compiler is as shown in FIG. 2B. FIG. 2B has two more transfer instructions than the ideal situation of FIG. 1D but, since it has only one div instruction, requires less execution time than FIG. 1B. In addition, if conventional copy propagation is optimized (this technique is described in reference 1, listed later in this specification) for FIG. 2B, the program section shown there can be changed to one similar to FIG. 1D.
  • Furthermore, if it is desirable to insert instructions capable of performing both division and remainder calculation at a plurality of places in the program, a macro is defined as in FIG. 3A, and if this macro is used as shown in FIG. 3B efficiency is increased. Furthermore, the descriptor is the same kind as that used to call a function, so the program becomes easier to read. Note that FIG. 3B shows a situation in which a microprocessor targeted by a C language compiler replaces x, y, z and w with a, b, c and d, as in FIG. 2A. Replacement of variables by a C compiler in this way is known as macro generation. Descriptors that are macro-defined assembler statement sequences having a special function, such as dm in FIG. 3A, are known as ‘inline assembly routines’. [0011]
  • However, if inline assembly routines are used in a conventional compiler, a programmer needs to carry out first and second check operations (described below). As a result, programmers are somewhat reluctant to include inline assembly routines when programming. [0012]
  • The program includes a plurality of variables. When a value of a certain variable x is valid for an entire inline assembly routine, the first check operation involves thoroughly checking the object program generated by the compiler to determine whether the value of the variable x has been destroyed. A register r is allocated to the variable x by a process performed by the compiler, so that if the inline assembly routine defines the register r, the value of the register r will differ before and after the inline assembly routine. [0013]
  • Suppose, as shown in FIG. 3C, that a value for a variable a defined at definition point ([0014] 1) is used at use point (2) and variable a has a live range which extends over the inline assembly routine dm. A register r1 is allocated to the variable a, and if the value of register r1 is changed during the inline assembly routine dm, a value of a which differs from that defined at definition point (1) will be used at use point (2) in FIG. 3C.
  • In the second check operation, the programmer makes a careful check to determine whether values of parameters have been destroyed, after determining how such values are defined by the inline assembly routine. [0015]
  • In some parameters, values are transferred using specified registers r. The live ranges of such parameters may extend over the inline assembly routine. Here, if a register r is defined by the inline assembly routine, the value of the parameter will be different before and after the inline assembly routine. For example, if, as in FIG. 3D, a parameter p is referenced after the use point of the inline assembly routine dm, and the parameter p is passed to a register r[0016] 0, it is clear that the value of the register r0 will be destroyed by the inline assembly routine dm, and the value used when the parameter p is referenced will be inaccurate.
  • These kinds of checks generally create a heavy workload for the programmer, and in an attempt to lighten this burden, many programmers write programs including various restrictions. For example, programmers only use inline assembly routines for functions including variables that can definitely be judged as being allocated to memory or a specified register prior to compiling (global variables and the like). In addition, registers used by parameters are not defined in the inline assembly routine. [0017]
  • Programmers would ideally like to express what were originally independent functions as an inline assembly routine, and use such routines to increase effectiveness, but the above described restrictions hamper such efforts. As a rule, a programmer must use the first and second check operations to determine how the inline assembly routine has been defined. This means that it is difficult for the programmer to use the inline assembly routine with no knowledge of its detailed content, as is necessary when dealing with so-called black boxes (that is programs/program sections whose operational code is confidential or otherwise unknown). Accordingly, it is difficult to increase the reusability of inline assembly routines by changing them into library routines. [0018]
  • SUMMARY OF THE INVENTION
  • A first object of the present invention is to provide a compiling device that translates a program without requiring the programmer to make checks when an inline assembly routine is used. [0019]
  • A second object of the present invention is to provide a compiling device that translates a program so as to enable inline assembly routines to be inserted as black boxes. [0020]
  • A third object of the present invention is to provide a compiling device enabling inline assembly routines to be changed to library routines, thereby increasing the reusability of the program. [0021]
  • As described above, the present invention is a compiling device that translates a program including statements using variables into an object instruction sequence. Assembler instructions defining values for resources are arranged in a section of the program. The compiling device includes a variable detecting unit for detecting variables whose live ranges overlap the section from variables having values defined in the statements, and a resource allocating unit for allocating to each variable detected by the variable detecting unit, a resource different from the resources having values defined in the assembler instructions. [0022]
  • This means that the programmer is not obliged to make checks when an inline assembly routine is used. Since these conventional checks are no longer necessary, assembler statements and inline assembly routines can be written at arbitrary positions in the program. Using inline assembly routines actively in this way improves the execution speed and reusability of the program. [0023]
  • In this invention, the program may be embodied by a plurality of functions, the statements are included in the functions, and assembler instructions are included at least one of the functions. Here, the compiling device further includes a register parameter replacing unit that, when formal parameters that should use registers exist, (1) generates substitution instructions for substituting temporary variables for the values of each formal parameter used in the functions, and inserts each of the generated substitution instructions at the start of a corresponding function, and (2) replaces all of the formal parameter values in the functions with the temporary variables indicated by the substitution instructions. Furthermore, the variable detecting unit detects temporary variables whose live ranges overlap the section; and the resource allocating unit allocates a register different from the registers whose values are defined in the assembler instructions to each detected temporary variable. [0024]
  • Here, a register that has been allocated to a parameter is no longer incorrectly updated in the assembly statements, and the same applies to variables whose live ranges span the assembler statements. This means that inline assembly routines can be freely defined, and used as a black box at an arbitrary position in the program. Using inline assembly routines actively in this way improves the execution speed and reusability of the program. [0025]
  • The variable detecting unit may also include a detecting unit for detecting assembler instructions from the program, a temporary variable generating unit for generating, when assembler instructions are detected, temporary variables already allocated to resources defined in the assembler instructions, a live range setting unit setting the live range of each generated temporary variable to be equal to the section where the assembler instructions are arranged; and a variable detecting unit detecting variables whose live range overlaps the live range set for the temporary variables. Here, the resource allocating unit allocates a resource different from the resources allocated to the temporary variables to each of the detected variables. [0026]
  • Allocated temporary variables are generated from the assembler statements, and resource allocation is performed using a method that integrates these generated temporary variables. In addition the resource allocation method disclosed in [0027] reference 2, which actively limits the generation of transfer instructions, and the resource allocation method disclosed in reference 3, which is an expansion method of the widely known graph coloring technique, may be applied.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • These and other objects, advantages and features of the invention will become apparent from the following description thereof taken in conjunction with the accompanying drawings which illustrate a specific embodiment of the invention. In the drawings: [0028]
  • FIG. 1 shows an example program, a corresponding assembler program, a comparative assembler program, and an illustration of a division instruction; [0029]
  • FIG. 2 shows an example asm statement sequence, and corresponding assembler program; [0030]
  • FIG. 3 shows examples of inline assembly routine definitions and inline assembly routine uses; [0031]
  • FIG. 4 is a block diagram of a [0032] compiling device 1 in a first embodiment;
  • FIG. 5 is a flowchart of processing performed by a register [0033] parameter replacing unit 16;
  • FIG. 6 is a flowchart showing the procedure performed by an asm [0034] register detecting unit 17;
  • FIG. 7 is a flowchart showing the procedure performed by a [0035] resource allocating unit 14;
  • FIG. 8 shows an example of a program written in a high-level programming language; [0036]
  • FIG. 9 shows a program after execution performed by a [0037] macro expanding unit 11;
  • FIG. 10 shows an intermediate program after execution performed by a [0038] syntax analyzing unit 12;
  • FIG. 11 shows an intermediate program after execution performed by the register [0039] parameter replacing unit 16;
  • FIG. 12 shows an intermediate program and live ranges corresponding to an example program; [0040]
  • FIG. 13 shows an example of content held in asm defining [0041] register holding units 18 and 28;
  • FIG. 14 is a block diagram of a [0042] compiling device 2 in a second embodiment;
  • FIG. 15 is a flowchart showing the procedure performed by an asm live [0043] range generating unit 29;
  • FIG. 16 is a flowchart showing the procedure performed by a [0044] resource allocating unit 24;
  • FIG. 17 shows an intermediate program and live ranges corresponding to a program after execution performed by an asm live [0045] range generating unit 29;
  • FIG. 18 shows a basic data structure for expressing live ranges; and [0046]
  • FIG. 19 shows an interference graph for variables corresponding to the live ranges shown in FIG. 17.[0047]
  • DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Prior to the description of the embodiments, a description of related references and terminology will be made. [0048]
  • References[0049]
  • 1. Compilers: Principles, Techniques and Tools. By Alfred V. Aho, Ravi Sethi and Jeffrey D. Ullman. Addison Wesley, 1986. [0050]
  • 2. Japanese Patent Application No. 10-344524: A Resource Allocation Apparatus and A Computer-Readable Recording Medium on which a Resource Allocating Program as Recorded. Akira Tanaka. [0051]
  • 3. Modern Compiler Implementation in Java. By Andrew W. Appel. Cambridge University Press, 1998.[0052]
  • Terminology [0053]
  • Definition, Referencing and Use of Variables [0054]
  • Setting the value of a variable is described as ‘defining’, and using the set value as ‘referencing’. When variables are defined and referenced in a program this is described as ‘using’. Unless a particular distinction needs to be made, the following explanation treats formal parameters in the same way as variables. [0055]
  • Temporary Variable [0056]
  • A variable generated by the compiler to temporarily store a calculation result, thereby simplifying processing, is known as a ‘temporary variable’. The following explanation treats such variables in the same way as variables written in a standard source program, unless a particular distinction needs to be made. [0057]
  • Intermediate Instruction [0058]
  • In order to simplify processing, the compiler converts source program code into code known as ‘intermediate code’, and one step of the intermediate code is known as an ‘intermediate instruction’. Intermediate instructions are for example quadruples or triples, and are converted to generate a final object program. Furthermore, when the source program is converted to a sequence of intermediate instructions, these are known collectively as an ‘intermediate program’. FIG. 10 shows one example of an intermediate program corresponding to the program in C shown in FIG. 9. This program is expressed in three address code, which is one of the quadruples. Also in FIG. 10, references i[0059] 1, i2 and the like, formed from ‘i’ and an attached number, represent identifiers (names) of intermediate instructions. To be more specific, the expression ‘a=p+b+10’ in FIG. 9 is divided into two intermediate instructions i1 and i2 in FIG. 10, through the use of a temporary variable t1. Furthermore, the asm statements of FIG. 9, (1) are converted into intermediate instructions (FIG. 10, (1) having the same format as FIG. 9, (1). The intermediate instructions for the asm statements in FIG. 10 (1) will be known as ‘asm intermediate instructions’. Note that in the embodiments, intermediate instructions having other formats may also be used in addition to the format shown here. Furthermore, in order to simplify processing performed by the compiler, the intermediate program is also equipped with intermediate instructions showing specified program ranges, such as intermediate instructions indicating the start and end of the intermediate program and the start and end of functions. In FIG. 10, for example, intermediate instructions i50 and i51 show the start and end of a function.
  • Basic Block [0060]
  • When there are no jumps from or to an intermediate instruction sequence, and the sequence is executed in a fixed order, it is known as a ‘basic block’. A detailed description of basic blocks may be found in [0061] reference 1.
  • Live Range [0062]
  • Live ranges are sections during which values stored in each variable are valid, each live range actually representing the section of a program from an intermediate instruction defining a value for a variable until an intermediate instruction which last references the defined value. Consequently, a live range can be expressed by the set of intermediate instructions included in this section. Here, the intermediate instruction defining the value for the variable corresponds to the start point of the live range and the intermediate instruction last referencing the defined value to the end point of the live range. The areas occupied by the intermediate instruction sets are used to determine whether live ranges overlap. Thus, when the end point of one live range is identical to the start point of another live range, the two live ranges do not overlap. FIG. 12B shows examples of live ranges. In the drawing, live ranges are represented by solid vertical lines. The start point of each live range is shown by a white dot and the end point by a black dot. FIG. 18 shows the actual structure of data representing the live ranges in FIG. 12B, with the live range of each variable shown by an intermediate instruction set. In FIG. 18, the symbol ‘. . . ’ shown in various live ranges, indicates the presence of an intermediate instruction not shown in the drawing. Live ranges may also be referred to as ‘lifetimes’ or ‘extents’. A more detailed definition and actual examples of live ranges are given in [0063] references 1 and 2.
  • Allocation of Resources to Variables [0064]
  • This refers to the allocation of registers and memory to variables. Since it is impossible to hold more than one value in a particular register or memory region during the same section of a program, the same register or memory region cannot be allocated to variables with overlapping live ranges, and it is essential to allocate different registers or memory regions to such variables. For example, the live ranges of variables a and b in FIG. 12 overlap, so these variables need to be allocated different registers or memory regions. Registers and memory are hereafter referred to collectively as ‘resources’. [0065]
  • First Embodiment [0066]
  • FIG. 4 is a block diagram of a [0067] compiling device 1 in a first embodiment. The compiling device 1 is formed from the main components of a conventional compiler, such as a macro expanding unit 11, a syntax analyzing unit 12, an optimizing unit 13, a resource allocating unit 14, and a code generating unit 15, along with a register parameter replacing unit 16, an asm register detecting unit 17, and an asm register holding unit 18 which bear a particular relationship to this embodiment.
  • The following is an explanation of the operation and function of each component, with reference to the drawings. [0068]
  • The [0069] macro expanding unit 11 is the first component to be activated by the compiling device 1, and replaces macro-defined macro identifiers with their actual content. This processing is basically the same as that performed by a conventional C compiler, so explanation here is limited to describing an example processing result.
  • FIG. 8 shows an example source program. Here, a macro identifier dm (x,y,z,w) that macro-defines an inline assembly routine that performs division and remainder calculation as described in the background art, and a function f that uses this dm are shown. The part of the function f relevant to the explanation given in this embodiment has been extracted and written in the drawing. FIG. 9 shows an intermediate program resulting from processing of the source program of FIG. 8 performed by the [0070] macro expanding unit 11. As shown in FIG. 9 (1), the macro identifier dm is replaced by the macro-defined inline assembly routine.
  • FIG. 9, ([0071] 1) is composed of five assembler instructions: mov a,r0, mov b,r1, div r1,r0, mov r0,c and mov mdr,d. The keyword asm is attached to the front of each of these instructions. This asm keyword signifies that the statement shown between the keyword and a concluding semi-colon includes an assembler instruction. This kind of statement is known as an assembler statement. Such statements indicate to the compiling device 1 that translation processing equivalent to that used for the sections of the program written in a high-level programming language is not necessary. As a result, the syntax analyzing unit 12 and the optimizing unit 13 in the compiling device 1 skip processing of statements that start with the keyword asm.
  • Following the completion of processing by the [0072] macro expanding unit 11, the syntax analyzing unit 12 is activated, and performs lexical analysis, syntax analysis and semantic factoring, thereby converting the source program to an intermediate program. As one example, the source program of FIG. 9 is converted to the intermediate program shown in FIG. 10. The operation of the syntax analyzing unit 12 is not the focus of this embodiment and so a more detailed description is omitted. At this point, assembler statements which have had a keyword asm attached and been expanded inside the source program by the macro expanding unit 11 are inherited directly by the converted intermediate program without being changed into different code by the syntax analyzing unit 12. This means that assembler statements having the attached keyword asm exist in the intermediate program as intermediate instructions.
  • Once the processing performed by the [0073] syntax analyzing unit 12 has been completed, the optimizing unit 13 optimizes the intermediate program so as to minimize the size and processing time of the object program finally generated by the compiling device 1. The operation of the optimizing unit 13 is not the focus of this embodiment and so a detailed description is omitted, with only those points relevant to the embodiment being explained. In order to perform optimization, the optimizing unit 13 performs basic block analysis, control flow analysis and data flow analysis. Basic block analysis is performed by dividing the intermediate program into basic blocks. Then control flow analysis is performed by analyzing the control flow between basic blocks. After this, data flow analysis is performed by analyzing where each variable is defined and referenced within each basic block. The resource allocating unit 14 (explained later in this specification) uses the results of this analysis to calculate live ranges. Note that when register parameters are included in the program to be translated, the optimizing unit 13 is activated following activation of the register parameter replacing unit 16. Here, optimization performed by the optimizing unit 13 enables assembler statements having an attached keyword asm to be inherited directly by the intermediate program without being replaced by a different code, and without being deleted.
  • The register [0074] parameter replacing unit 16 is activated if register parameters are included in the program that is to be translated. The register parameter replacing unit 16 inserts, at the start of a function, an intermediate instruction storing, as a temporary variable, a value of a formal parameter passed to the register. Further to this, the register parameter replacing unit 16 replaces the sections of the intermediate program in which the formal parameter is used with the temporary variables. FIG. 5 is a flowchart showing the processing performed by the register parameter replacing unit 16.
  • At step a[0075] 1, the register parameter replacing unit 16 repeats the processing of steps a2 to a5 for all formal parameters p, and when all the formal parameters p have been processed, the processing performed by the register parameter replacing unit 16 is completed.
  • At step a[0076] 2, if a formal parameter p has been passed to a register, the register parameter replacing unit 16 performs steps a3 and a4.
  • At step a[0077] 3, the register parameter replacing unit 16 generates a new temporary variable t and then an intermediate instruction i:t=p showing that the formal parameter p should be replaced by the temporary variable t.
  • At step a[0078] 4, the register parameter replacing unit 16 inserts the generated intermediate instruction i at the start of the function.
  • At step a[0079] 5, the register parameter replacing unit 16 replaces all the sections of the intermediate program where the formal parameter p is used with the temporary variable t, and returns to step a1.
  • The following is an explanation of an actual example of operations performed by the register [0080] parameter replacing unit 16, with reference to the example shown in FIG. 11. FIG. 11 shows the result of processing performed by the register parameter replacing unit 16 on the intermediate program in FIG. 10. The register parameter replacing unit 16 fetches a formal parameter p passed to a register (steps a1 and a2), generates an intermediate instruction i20 indicating that the formal parameter p should be replaced by a temporary variable t2 (step a3), inserts the intermediate instruction i20 at the start of the intermediate program (step a4), and replaces the parts of intermediate instructions i1 and i9 that use the formal parameter p with the temporary variable t2 (step a5).
  • Once the processing performed by the optimizing [0081] unit 13 has been completed, the resource allocating unit 14 allocates different registers to each of a plurality of variables having overlapping live ranges. Here, when assembler statements have been expanded in the program, the resource allocating unit 14 activates the asm register detecting unit 17 before commencing its own processing.
  • When assembler statements having an attached asm keyword are included in any of the intermediate instructions in the intermediate program, the asm [0082] register detecting unit 17 detects registers defined in the assembler statements, and stores the detection result in the asm register holding unit 18. FIG. 6 is a flowchart showing the processing performed by the asm register detecting unit 17.
  • At step b[0083] 1, the asm register detecting unit 17 performs the processing of steps b2 and b3 for all of the intermediate instructions i. Once processing has been performed for all of the intermediate instructions i, the processing performed by the asm detecting unit 17 is completed.
  • At step b[0084] 2, when the intermediate instruction i is an asm intermediate instruction, the asm register detecting unit 17 performs the processing of step b3. When the intermediate instruction i is not an asm intermediate instruction, processing returns to step b1.
  • When a register r is defined in the intermediate instruction i, at step b[0085] 3 , the asm register detecting unit 17 stores the intermediate instruction i and the register r in the asm register holding unit 18, and processing returns to step l.
  • FIG. 13 shows the content held by the asm [0086] register holding unit 18 corresponding to the intermediate program shown in FIG. 11. Registers defined in each asm intermediate instruction are held. For example, in the asm intermediate instruction i3 in FIG. 11, a value of the variable a is transferred to a register r0, thereby defining the register r0, so that the register defined by the asm intermediate instruction i3 is set as r0 (step b3).
  • The [0087] resource allocating unit 14 uses control flow information and data flow information analyzed by the optimizing unit 13 to calculate live ranges for all variables, including the temporary variables generated by the register parameter replacing unit 16. The method used to calculate live ranges is the same as that explained in detail in references 1 and 2 and the like, and so explanation is here confined to showing the calculation result of live ranges for the intermediate program shown in FIG. 11. This calculation result is shown in FIG. 12. A live range is expressed conventionally as a set of intermediate instructions, as in reference 2, but here the extent of each live range is represented by a solid line to make it conceptually easier to understand. Furthermore, the reference (r0) written next to the live range for the formal parameter p signifies that register r0 is allocated to the formal parameter p. After calculating live ranges, the resource allocating unit 14 allocates resources to variables, including the temporary variables generated by the register parameter replacing unit 16. Specifically, when allocating resources to a variable, the resource allocating unit 14 allocates registers that are not allocated to variables with overlapping live ranges and that are not among registers defined by an asm intermediate instruction that have been obtained from the asm register holding unit 18. The latter condition applies only if asm statements are included in the live range of the variable. FIG. 7 is a flowchart showing the processing performed by the resource allocating unit 14.
  • At step c[0088] 1, the resource allocating unit 14 repeats the processing of steps c2 to c6 for all variables v that have not yet been allocated a resource, and once all variables v have been allocated a resource, the processing performed by the resource allocating unit 14 is completed.
  • At step c[0089] 2, the resource allocating unit 14 determines a register set R1, containing registers allocated to variables whose live ranges overlap with the live range of a variable v.
  • At step c[0090] 3, the resource allocating unit 14 detects registers defined by all the asm intermediate instructions included in the live range of the variable v from the asm register holding unit 18, thereby determining a register set R2.
  • At step c[0091] 4, the resource allocating unit 14 determines whether a register r which is not included in either register set R1 or register set R2 exists. If such a register exists, the processing of step c5 is executed, if such a register does not exist, the processing of step c6 is executed.
  • At step c[0092] 5, the resource allocating unit 14 allocates the register r to the variable v, and processing returns to step c1.
  • At step c[0093] 6, the resource allocating unit 14 allocates memory to the variable v, and processing returns to step c1.
  • The following is an explanation of the actual operation of the [0094] resource allocating unit 14, with reference to the example shown in FIG. 12. This explanation concentrates on the allocation of resources to variables a and t2. First, a register set R1, consisting of registers allocated to the variables t2, b, c and d whose live ranges overlap with the variable a, is determined. However, resources have not yet been allocated to these variables, so register set R1 is an empty set (step c2). Next, each of the asm intermediate instructions i3 to i7 included in the live range for variable a is referenced in the asm register holding unit 18 of FIG. 13, and registers r0, r1 and mdr defined in these asm intermediate instructions are fetched (step c2). A register that is not included in either of the register sets R1 and R2, for example register r2, is allocated to the variable a (step c4, c5).
  • The following is an explanation of the allocation of a resource to the variable t[0095] 2. First, a register set R1 containing registers allocated to variables t1, a, b, c, d and e whose live ranges overlap with that of the variable t2, is determined. Here, suppose that the variables t1, b, c, d and e have not yet been allocated resources, and the variable a is allocated to the register r2 as was previously described. In this case, register r2 is fetched from the register set R1 (step c2). Next, each of the asm intermediate instructions i3 to i7 included in the live range for variable t2 is referenced in the asm register holding unit 18 of FIG. 13, and registers r0, r1 and mdr defined in these variables are fetched (step c2). A register that is not included in either of register sets R1 and R2, for example register r3, is allocated to the variable t2 (step c4, c5).
  • Next, the compiling [0096] device 1 activates the code generating unit 15, and converts the intermediate instructions into an object program formed from assembler statements and machine language instructions for a machine targeted by the compiler. The code generating unit 15 uses a conventional method and so detailed explanation is omitted here.
  • As explained above, in this embodiment, variables which are live for the extent of the asm statements, such as variables a and t[0097] 2 in FIG. 12, are not allocated registers defined in the asm statements in steps c3 to c5 performed by the resource allocating unit 14. As a result, the first check operation mentioned in the Background Art section is no longer required. In addition, a temporary variable t2 is generated by the register parameter replacing unit 16 in steps a2 to a5, and registers defined in the asm statements are not allocated to the variable t2 in steps c3 to c5 performed by the resource allocating unit 14. This means that the second check operation described in the Background Art section is not required. As a result, the programmer can freely define inline assembly routines, and use such routines as black boxes at arbitrary points in the program. This greatly reduces the burden of checks placed on the programmer when using inline assembly routines, and also allows inline assembly routines to be changed to library routines, improving the reusability of the program.
  • Note that in step a[0098] 4 of the flowchart showing the processing performed by the register parameter replacing unit 16, the generated intermediate instruction i is inserted at the start of the function, but it may also be inserted at a point in the program prior to referencing of the formal parameter p.
  • Second Embodiment [0099]
  • FIG. 14 is a block diagram showing a [0100] compiling device 2 in a second embodiment. The compiling device 2 is formed from the main components of a conventional compiler, in other words a macro expanding unit 21, a syntax analyzing unit 22, an optimizing unit 23, a resource allocating unit 24, and a code generating unit 25, along with a register parameter replacing unit 26, an asm register detecting unit 27, an asm register holding unit 28, and an asm live range generating unit 29, that bear a particular relationship to this embodiment.
  • The [0101] compiling device 2 activates the macro expanding unit 21, the syntax analyzing unit 22, and the optimizing unit 23 in the same way as the compiling device 1 in the first embodiment. Here, the macro expanding unit 21, the syntax analyzing unit 22, the optimizing unit 23 and the register parameter replacing unit 26 in FIG. 14 are the same as the macro expanding unit 11, the syntax analyzing unit 12, the optimizing unit 13 and the register parameter replacing unit 16 of FIG. 4 explained in the first embodiment. Therefore, the following explanation focuses on the resource allocating unit 24, the asm register detecting unit 27, and the asm live range generating unit 29. An intermediate program generated for the example program shown in FIG. 8 resembles the one in FIG. 11 up until the end of processing performed by the optimizing unit 23.
  • The asm [0102] register detecting unit 27 has the same construction as the asm register detecting unit 17 of the first embodiment, and is the first component to be activated by the resource allocating unit 24. If the asm register detecting unit 17 performs detection processing on the example program shown in FIG. 11, the content shown in FIG. 13 is set in the asm register holding unit 28.
  • Once the asm [0103] register detecting unit 27 has performed detection processing, the resource allocating unit 24 uses the control flow information and data flow information analyzed by the optimizing unit 23 to calculate the live ranges of all of the variables. The result of processing performed on the example in FIG. 11 is the same as that explained in the first embodiment with reference to FIG. 12.
  • Once the [0104] resource allocating unit 24 has calculated the live ranges, the asm live range generating unit 29 is activated and this unit generates temporary variables that have already been allocated to registers defined by asm statements, and live ranges corresponding to the variables. FIG. 15 is a flowchart showing the processing performed by the asm live range generating unit 29.
  • At step d[0105] 1, the asm live range generating unit 29 repeats steps d2 to d5 for all of the asm intermediate instructions i. Once all the intermediate instructions i have been processed, the processing performed by the asm live range generating unit 29 is completed.
  • At step d[0106] 2, if a register r defining a asm intermediate instruction i is found to exist in the asm register holding unit 28, the asm live range generating unit 29 performs steps d3 to d5, and if such an intermediate instruction is not found, processing returns to step d1.
  • At step d[0107] 3, the asm live range generating unit 29 generates a new temporary variable s.
  • At step d[0108] 4, the asm live range generating unit 29 generates a live range which starts and ends with asm intermediate instructions for the temporary variable s.
  • At step d[0109] 5, the asm live range generating unit 29 allocates a register to the generated variable s, and processing then returns to step d1.
  • FIG. 17B shows the live ranges of each variable following the performance of processing by the asm live [0110] range generating unit 29. The drawing further includes temporary variables s1, s2 and s3, to which registers have been allocated, with corresponding live ranges. For example, the asm intermediate instruction i3 includes a temporary variable s1, which is allocated the register r0 defined in the asm intermediate instruction i3. A live range which covers only the asm intermediate instruction i3 is generated for the temporary variable s1.
  • Next, the [0111] resource allocating unit 24 allocates resources to variables. FIG. 16 is a flowchart showing the processing performed by the resource allocating unit 24.
  • At step e[0112] 1, the resource allocating unit 24 repeats the processing of steps e2 to e5 for all variables v that have not yet been allocated resources. Once all variables v have been processed, the processing performed by the resource allocation unit 24 is completed.
  • At step e[0113] 2, the resource allocating unit 24 determines a register set R, containing registers allocated to variables having live ranges which overlap with that of variable v.
  • At step e[0114] 3, the resource allocating unit 24 determines whether a register r, which does not belong to the register set R found at step e2, exists. If such a register exists, the resource allocating unit 24 executes step e4; if not, it executes step e5.
  • At step e[0115] 4, the resource allocating unit 24 allocates the register r to the variable v, and processing returns to step e1.
  • At step e[0116] 5, the resource allocating unit 24 allocates memory to the variable v, and processing returns to step e1.
  • The following is an explanation of an actual example of processing performed by the [0117] resource allocating unit 24, with reference to the example in FIG. 17. The allocation of resources to variables a and t2 is explained. Variables t2, b, c, d, s1, s2 and s3 have live ranges which overlap with that of the variable a. Of these variables, s1, s2, and s3 have been allocated registers r0, r1 and mdr respectively, so these variables are contained in the register set R (step e2). The variable a is allocated a different register, for example register r2.
  • Next, the allocation of a resource to the variable t[0118] 2 is explained. Variables t1, a, b, c, d, e, s1, s2, and s3 have live ranges which overlap with that of the variable t2. In this case, the variables a, s1, s2 and s3 have been allocated the registers r2, r1, r0 and mdr, so the variable t2 is allocated a different register, for example register r3.
  • Next, the compiling [0119] device 2 activates the code generating unit 25, and converts intermediate instructions into an object program including assembler statements and machine language instructions for a machine targeted by the compiling device 2. The code generating unit 25 uses a conventional method and so is not described in detail here.
  • In the above embodiments, variables such as a and t[0120] 2 in FIG. 17, that are live for the entire span of the asm statements are not allocated a register that is defined by the asm statements in steps e3 and e4. This effect is achieved by using the temporary variables s1, s2 and s3 generated by the asm live range generating unit 29, and removes the need for performing the first check operation described in the Background Art section. Furthermore, the variable t2 is generated in steps a2 to a5 performed by the register parameter replacing unit 16, and the variable t2 is not allocated to a register defined in the asm statements in steps e3 and e4 performed by the resource allocating unit 24. This means that the second check operation described in the Background Art section is also not required. As a result, the programmer can freely define inline assembly routine and use them as black boxes in arbitrary positions. The checks performed by the programmer when using inline assembly routines are much reduced, and inline assembly routines can be changed into a library routines, increasing the reusability of the program.
  • Note that the introduction of the temporary variables s generated by the asm live [0121] range generating unit 29 and generation of live ranges for these variables enables a conventional resource allocation method, such as the one described in references 1 and 2, to be applied by the resource allocating unit 24. The method described in reference 2 may be applied by using the intermediate program and live range information shown in FIG. 17. In particular, reference 2 teaches that it is possible to limit the generation of transfer instructions in the object program generated by the compiler to a bare minimum. For example, when the end point of the live range for one variable is identical to the start point of the live range for another variable, as is the case with variables b and s2 in FIG. 17, these variables are if possible allocated the same register. As a result, the variable b is allocated to register r1, and asm intermediate instruction i4 becomes a transfer within a same register, and so is deleted.
  • The extension method for graph coloring (a widely known technique) disclosed in reference [0122] 3 can be applied by constructing an interference graph like that in FIG. 19, showing overlapping live ranges between variables using the live range information of FIG. 17. In the graph in FIG. 19, variables are expressed as nodes, and variables (nodes) having overlapping live ranges are connected by edges. Some of the nodes in the graph have already been colored, that is have already been allocated a register. These are nodes (variables) s1, s2 and s3. Specifically, the method disclosed in reference 3 is a graph coloring method which can use a graph like this one in which some of the nodes have already been colored.
  • In the embodiments, the invention is described in relation to a division instruction, but its application is not limited to such instructions, and it may also be applied to advanced instructions for multimedia processing, such as product-sum instructions, other arbitrary instructions using calculations such as the four arithmetic fundamentals, and bit manipulation calculations, or any combination of a plurality of the above-mentioned calculations. [0123]
  • Furthermore, the procedure explained in the embodiments with reference to flowcharts (FIGS. [0124] 5 to 7, and FIGS. 15 and 16) is represented using a machine language program, but may equally be represented by recording such a program on a recording medium for distribution and sales. The recording medium may be an IC card, optical disk, floppy disk or similar. The machine language program recorded on such a recording medium is supplied for installation in a general-purpose personal computer. The general-purpose personal computer executes the installed machine language program in sequence, realizing the functions of the compiling device shown in the present embodiments.
  • Although the present invention has been fully described by way of examples with reference to accompanying drawings, it is to be noted that various changes and modifications will be apparent to those skilled in the art. Therefore, unless such changes and modifications depart from the scope of the present invention, they should be construed as being included therein. [0125]

Claims (16)

1-12. (Cancelled)
13. A compiling device that translates a program including an assembler statement section into an object instruction sequence, the compiling device comprising:
a variable detecting means for detecting a variable whose live range overlaps the assembler statement section; and
a resource allocating means for allocating a resource different from a resource to be used in the assembler statement section to the variable whose live range overlaps the assembler statement section.
14. The compiling device of claim 13, wherein said variable detecting means detects a variable whose live range spreads over an entire assembler statement section.
15. The compiling device of claim 13, wherein said resource allocating means allocates a resource different from the one which has been used in the assembler statement section.
16. The compiling device of claim 13, wherein said resource allocating means allocates a resource different from the one to be allocated to a temporary variable in the assembler statement section.
17. The compiling device of claim 13, further comprising:
a code generating means for translating the program into an optimized object code,
wherein the assembler statement section is not optimized by said code generating means.
18. A compiling device that translates a program including an assembler statement section into an object instruction sequence, the compiling device comprising:
a variable detecting unit which detects a variable whose live range overlaps the assembler statement section; and
a resource allocating unit for allocating a resource different from a resource to be used in the assembler statement section to the variable whose live range overlaps the assembler statement section.
19. A compiling device of claim 18, wherein said variable detecting unit detects a variable whose live range spreads over an entire assembler statement section.
20. The compiling device of claim 19, wherein said resource allocating means allocates a resource different from the one which has been used in the assembler statement section.
21. The compiling device of claim 20, wherein said resource allocating means allocates a resource different from the one to be allocated to a temporary variable in the assembler statement section.
22. The compiling device of claim 20, further comprising:
a code generating unit for translating the program into an optimized object code,
wherein the assembler statement section is not optimized by said code generating unit.
23. A compiling method that translates a program including an assembler statement section into an object instruction sequence, the compiling method comprising the steps of:
a detecting step for detecting a variable whose live range overlaps the assembler statement section; and
an allocating step for allocating a resource different from a resource to be used in the assembler statement section to the variable whose live range overlaps the assembler statement section.
24. The compiling method of claim 23, wherein said detecting step detects a variable whose live range spreads over an entire assembler statement section.
25. The compiling method of claim 23, wherein said allocating step allocates a resource different from the one which has been used in the assembler statement section.
26. The compiling method of claim 23, wherein said allocating step allocates a resource different from the one to be allocated to a temporary variable in the assembler statement section.
27. The compiling method of claim 23, further comprising:
a generating step for translating the program into an optimized object code,
wherein the assembler statement section is not optimized by said generating step.
US10/819,595 1999-07-09 2004-04-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method Abandoned US20040194071A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/819,595 US20040194071A1 (en) 1999-07-09 2004-04-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP11-195717 1999-07-09
JP19571799A JP4041248B2 (en) 1999-07-09 1999-07-09 COMPILER DEVICE, COMPUTER-READABLE RECORDING MEDIUM CONTAINING COMPILING PROGRAM, AND COMPILING METHOD
US09/612,028 US6738966B1 (en) 1999-07-09 2000-07-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method
US10/819,595 US20040194071A1 (en) 1999-07-09 2004-04-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/612,028 Division US6738966B1 (en) 1999-07-09 2000-07-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method

Publications (1)

Publication Number Publication Date
US20040194071A1 true US20040194071A1 (en) 2004-09-30

Family

ID=16345804

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/612,028 Expired - Lifetime US6738966B1 (en) 1999-07-09 2000-07-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method
US10/819,595 Abandoned US20040194071A1 (en) 1999-07-09 2004-04-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/612,028 Expired - Lifetime US6738966B1 (en) 1999-07-09 2000-07-07 Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method

Country Status (2)

Country Link
US (2) US6738966B1 (en)
JP (1) JP4041248B2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050166195A1 (en) * 2004-01-28 2005-07-28 International Business Machines Corporation Compiler, compilation and storage
US20050235268A1 (en) * 2002-04-15 2005-10-20 Michael Baldischweiler Optimisation of a compiler generated program code
US20060277529A1 (en) * 2005-06-06 2006-12-07 Matsushita Electric Industrial Co., Ltd. Compiler apparatus
US20090064112A1 (en) * 2007-08-29 2009-03-05 Tatsushi Inagaki Technique for allocating register to variable for compiling
US7861234B1 (en) * 2005-02-23 2010-12-28 Oracle America, Inc. System and method for binary translation to improve parameter passing
US20120042304A1 (en) * 2010-08-10 2012-02-16 Nobuaki Tojo Program conversion apparatus and computer readable medium
US11188656B2 (en) * 2018-07-27 2021-11-30 Silicon Laboratories Inc. Secure software system for microcontroller or the like and method therefor

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1199629A1 (en) * 2000-10-17 2002-04-24 STMicroelectronics S.r.l. Processor architecture with variable-stage pipeline
US20020138819A1 (en) * 2000-12-19 2002-09-26 Hills Theodore S. Computer programming language to describe and encapsulate a computer as a set of classes and objects
JP2004078268A (en) * 2002-08-09 2004-03-11 Fujitsu Ltd Information processor, information processing method and program
JP3896087B2 (en) 2003-01-28 2007-03-22 松下電器産業株式会社 Compiler device and compiling method
US7337438B1 (en) 2003-03-31 2008-02-26 Applied Micro Circuits Corporation Macros to support structures for an assembler that does not support structures
US8549466B2 (en) * 2005-07-15 2013-10-01 Texas Instruments Incorporated Tiered register allocation
US8924691B2 (en) * 2006-02-24 2014-12-30 Freescale Semiconductor, Inc. Software pipelining
US8161464B2 (en) * 2006-04-11 2012-04-17 International Business Machines Corporation Compiling source code
US8522218B2 (en) * 2010-03-12 2013-08-27 Microsoft Corporation Cross-module inlining candidate identification
JP7225900B2 (en) * 2019-02-25 2023-02-21 富士通株式会社 Compiler device, program, and information processing method
GB2582785A (en) * 2019-04-02 2020-10-07 Graphcore Ltd Compiling a program from a graph
CN111124416B (en) * 2019-12-09 2024-02-13 龙芯中科(合肥)技术有限公司 Method, apparatus, device and storage medium for transferring parameters to an inline assembly
GB202010839D0 (en) * 2020-07-14 2020-08-26 Graphcore Ltd Variable allocation

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4782444A (en) * 1985-12-17 1988-11-01 International Business Machine Corporation Compilation using two-colored pebbling register allocation method such that spill code amount is invariant with basic block's textual ordering
US5418958A (en) * 1992-07-15 1995-05-23 Sun Microsystems, Inc. Register allocation by decomposing, re-connecting and coloring hierarchical program regions
US5832273A (en) * 1993-07-07 1998-11-03 Nec Corporation System for deleting redundant instructions from high level language source code containing in-line assembly instructions
US6247174B1 (en) * 1998-01-02 2001-06-12 Hewlett-Packard Company Optimization of source code with embedded machine instructions
US6463582B1 (en) * 1998-10-21 2002-10-08 Fujitsu Limited Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method
US6983459B1 (en) * 1999-04-06 2006-01-03 International Business Machines Corporation Incorporating register pressure into an inlining compiler

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428793A (en) * 1989-11-13 1995-06-27 Hewlett-Packard Company Method and apparatus for compiling computer programs with interproceduural register allocation
US5659753A (en) * 1991-02-27 1997-08-19 Digital Equipment Corporation Interface for symbol table construction in a multilanguage optimizing compiler
IL100987A (en) * 1991-02-27 1995-10-31 Digital Equipment Corp Method and apparatus for compiling code
IL100990A (en) * 1991-02-27 1995-10-31 Digital Equipment Corp Multilanguage optimizing compiler using templates in multiple pass code generation
US5355494A (en) * 1991-12-12 1994-10-11 Thinking Machines Corporation Compiler for performing incremental live variable analysis for data-parallel programs
JP3606387B2 (en) * 1994-09-13 2005-01-05 松下電器産業株式会社 Compilation device
CN1149476C (en) * 1995-03-16 2004-05-12 松下电器产业株式会社 Resource dispensing equipment
JP3130446B2 (en) * 1995-05-10 2001-01-31 松下電器産業株式会社 Program conversion device and processor
JP3650649B2 (en) * 1995-06-16 2005-05-25 松下電器産業株式会社 Optimization device
US5881288A (en) * 1995-09-29 1999-03-09 Matsushita Electric Industrial Co., Ltd. Debugging information generation system
US5815719A (en) 1996-05-07 1998-09-29 Sun Microsystems, Inc. Method and apparatus for easy insertion of assembler code for optimization
US6286135B1 (en) * 1997-03-26 2001-09-04 Hewlett-Packard Company Cost-sensitive SSA-based strength reduction algorithm for a machine with predication support and segmented addresses
JP3220055B2 (en) * 1997-07-17 2001-10-22 松下電器産業株式会社 An optimizing device for optimizing a machine language instruction sequence or an assembly language instruction sequence, and a compiler device for converting a source program described in a high-level language into a machine language or an assembly language instruction sequence.
US6651247B1 (en) * 2000-05-09 2003-11-18 Hewlett-Packard Development Company, L.P. Method, apparatus, and product for optimizing compiler with rotating register assignment to modulo scheduled code in SSA form

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4782444A (en) * 1985-12-17 1988-11-01 International Business Machine Corporation Compilation using two-colored pebbling register allocation method such that spill code amount is invariant with basic block's textual ordering
US5418958A (en) * 1992-07-15 1995-05-23 Sun Microsystems, Inc. Register allocation by decomposing, re-connecting and coloring hierarchical program regions
US5832273A (en) * 1993-07-07 1998-11-03 Nec Corporation System for deleting redundant instructions from high level language source code containing in-line assembly instructions
US6247174B1 (en) * 1998-01-02 2001-06-12 Hewlett-Packard Company Optimization of source code with embedded machine instructions
US6463582B1 (en) * 1998-10-21 2002-10-08 Fujitsu Limited Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method
US6983459B1 (en) * 1999-04-06 2006-01-03 International Business Machines Corporation Incorporating register pressure into an inlining compiler

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7805718B2 (en) * 2002-04-15 2010-09-28 Giesecke & Devrient Gmbh Optimisation of a compiler generated program code
US20050235268A1 (en) * 2002-04-15 2005-10-20 Michael Baldischweiler Optimisation of a compiler generated program code
US7409678B2 (en) * 2004-01-28 2008-08-05 International Business Machines Corporation Compiler, compilation and storage
US20050166195A1 (en) * 2004-01-28 2005-07-28 International Business Machines Corporation Compiler, compilation and storage
US7861234B1 (en) * 2005-02-23 2010-12-28 Oracle America, Inc. System and method for binary translation to improve parameter passing
US7856629B2 (en) * 2005-06-06 2010-12-21 Panasonic Corporation Compiler apparatus
US20060277529A1 (en) * 2005-06-06 2006-12-07 Matsushita Electric Industrial Co., Ltd. Compiler apparatus
USRE45199E1 (en) * 2005-06-06 2014-10-14 Panasonic Corporation Compiler apparatus
US20090064112A1 (en) * 2007-08-29 2009-03-05 Tatsushi Inagaki Technique for allocating register to variable for compiling
US8266603B2 (en) * 2007-08-29 2012-09-11 International Business Machines Corporation Technique for allocating register to variable for compiling
US20120042304A1 (en) * 2010-08-10 2012-02-16 Nobuaki Tojo Program conversion apparatus and computer readable medium
US8732684B2 (en) * 2010-08-10 2014-05-20 Kabushiki Kaisha Toshiba Program conversion apparatus and computer readable medium
US11188656B2 (en) * 2018-07-27 2021-11-30 Silicon Laboratories Inc. Secure software system for microcontroller or the like and method therefor

Also Published As

Publication number Publication date
JP4041248B2 (en) 2008-01-30
US6738966B1 (en) 2004-05-18
JP2001022591A (en) 2001-01-26

Similar Documents

Publication Publication Date Title
US6738966B1 (en) Compiling device, computer-readable recording medium on which a compiling program is recorded and a compiling method
US5613117A (en) Optimizing compiler using templates corresponding to portions of an intermediate language graph to determine an order of evaluation and to allocate lifetimes to temporary names for variables
US5577253A (en) Analyzing inductive expressions in a multilanguage optimizing compiler
EP0528028B1 (en) Automatic flowgraph generation for program analysis and translation
EP1280056B1 (en) Generation of debugging information
EP1837757A2 (en) Compiler with particular instruction scheduling
US9858054B2 (en) Method for optimizing binary code in language having access to binary coded decimal variable, and computer and computer program
JP4638484B2 (en) Data integrity in data processing equipment
AU663311B2 (en) Multilanguage optimizing compiler using templates in multiple pass code generation
EP1253515A2 (en) Method for verifying basic instruction arrangement in VLIW instructions for variable length VLIW processor
US6301652B1 (en) Instruction cache alignment mechanism for branch targets based on predicted execution frequencies
EP0947922B1 (en) Compiler
JP3264901B2 (en) Compiling device and compiling method
CN112416313B (en) Compiling method supporting large integer data type and operator
JP2007114934A (en) Compiler system
JP3630086B2 (en) Program conversion apparatus, program conversion method, and recording medium
Haines et al. Note on conditional compilation in Standard ML
IE920608A1 (en) Interface for symbol table construction in a multilanguage¹optimizing compiler
Joshi A Task Optimization Framework for MSSP
Goyal et al. Function Overloading and Default Arguments
JP2004126666A (en) Compilation method
JP2001290652A (en) Device and method for converting program and recording medium

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION