EP0428560A1 - Traitement machine, pour la traduction de programmes en langage machine binaire en un autre langage machine binaire - Google Patents

Traitement machine, pour la traduction de programmes en langage machine binaire en un autre langage machine binaire

Info

Publication number
EP0428560A1
EP0428560A1 EP19890908667 EP89908667A EP0428560A1 EP 0428560 A1 EP0428560 A1 EP 0428560A1 EP 19890908667 EP19890908667 EP 19890908667 EP 89908667 A EP89908667 A EP 89908667A EP 0428560 A1 EP0428560 A1 EP 0428560A1
Authority
EP
European Patent Office
Prior art keywords
data
program
computer
flow analysis
memory
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.)
Withdrawn
Application number
EP19890908667
Other languages
German (de)
English (en)
Other versions
EP0428560A4 (en
Inventor
Colin B. Hunter
John P. Banning
Hans Pufal
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.)
HUNTER SYSTEMS SOFTWARE Inc
Original Assignee
HUNTER SYSTEMS SOFTWARE Inc
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 HUNTER SYSTEMS SOFTWARE Inc filed Critical HUNTER SYSTEMS SOFTWARE Inc
Publication of EP0428560A1 publication Critical patent/EP0428560A1/fr
Publication of EP0428560A4 publication Critical patent/EP0428560A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/52—Binary to binary

Definitions

  • This invention relates to machine processes for translating computer programs from one computer language into another computer language and, more particularly, to a method for translating computer programs from one binary machine language into another binary machine language, or from one assembly language into another assembly language.
  • Compilers are well-known in the art. They translate programs written in a high-level language, such as C, Fortran, or Pascal, into either assembly language or binary machine language. Likewise, assemblers are well-known in the art; they translate assembly language into binary machine language.
  • compilers translate single lines of a human-readable, high-level language ("statements") into several lines of assembly language or several binary machine instructions.
  • Assemblers on the other hand generally translate one assembly language line into one machine instruction (neglecting comments and assembler directives) .
  • Interpreters are similar to compilers, but instead of simply translating the source program into machine language, an interpreter translates each statement, then executes the translated code, and then translates and executes the next statement, and so on. Because an interpreter deals with only one statement at a time, it can be simpler in design than a compiler for the same language, but the scope for optimization is much less. Consequently, interpreted programs tend to execute much more slowly than compiled programs. Other forms of translators have also been developed from time to time. Various high-level translators (e.g. , Pascal to C) have been around for almost as long as there have been high-level languages. Assembly language translators (e.g., 8080 assembly code to 8086 assembly code) have also been reported, but seldom actually seen. It appears that compiler optimization techniques have not been applied to such translators.
  • high-level translators e.g. , Pascal to C
  • Assembly language translators e.g., 8080 assembly code to 8086 assembly code
  • phase problem is caused because the binary instruction formats of most computers have a varying length. It is, therefore, sometimes difficult to know where one instruction ends and another begins. It is especially difficult to know whether the disassembly process has been started correctly at the beginning of an instruction, or has begun in the middle of an instruction. In the latter case, all subsequent disassembled instructions will generally be wrong.
  • Disassemblers have a difficult time determining whether a particular pattern of bits is really an instruction or just several bytes of data. And of course the data problem exacerbates the phase problem, since the disassembler must correctly determine the length of the data area before it can resume disassembling at the correct place.
  • simulators deal with binary machine language source files. Simulators, however, are similar to interpreters in that they simultaneously translate and execute the source file. When they run, they have an effect as if the source binary program were executing on another computer with a different machine language. Simulators achieve this effect by simulating in software on the target computer the exact behavior of the original computer. Simulators have had very limited success, largely because of one well-known -A- proble : they are very slow. Quite often hundreds of simulator instructions must be executed for every instruction in the source program, and even the very best simulators need ten to twenty simulator instructions per source instruction.
  • This invention provides an effective machine process for translating with high efficiency computer programs from one binary machine language into another binary machine language.
  • This machine process will be referred to as a "binary compiler”; it can be realized in a program for a digital computer.
  • the technique can also be used to translate from one assembly language into another.
  • a binary compiler has the same relationship to a simulator that a compiler has to an interpreter. And just as a compiler produces code that executes faster than interpreted code, application programs converted with a binary compiler execute faster than they do with simulators.
  • the binary compiling process of the present invention involves disassembling the source binary program, analyzing the binary program to produce "global flow analysis" data, using this global flow analysis data to complete the disassembly process, and producing a translated binary machine language version of the source binary program, using global flow analysis data to generate optimized binary code.
  • the invention is used to translate from one assembly language into another, the disassembly stage is omitted, but the global flow analysis is still performed.
  • the output uses the global flow analysis data to produce optimized assembly code instead of optimized binary code.
  • FIG. 1 shows a generalized flow diagram representing the illustrative machine algorithm for practicing data processing in accordance with the present invention
  • FIG. 2 shows a more detailed flow diagram of the PROCESS PROCEDURES portion of the algorithm of FIG. 1;
  • FIG. 3 shows a more detailed flow diagram of the PROCESS A PROCEDURE portion of the algorithm of FIG. 2;
  • FIG. 4 shows a more detailed flow diagram of the of the BUILD BASIC BLOCKS portion of the algorithm of FIG. 3;
  • FIG. 5 shows a more detailed flow diagram of the FORWARD FLOW ANALYSIS portion of the algorithm of FIG. 3;
  • FIG. 6 shows a more detailed flow diagram of the
  • FIG. 7 shows a more detailed flow diagram of the UNKNOWNS ANALYSIS portion of the algorithm of FIG. 3;
  • FIG. 8 shows a more detailed flow diagram of the ANALYZE COMPLETED FLOWGRAPH portion of the algorithm of FIG. 1;
  • FIG. 9 shows a more detailed flow diagram of the LIVE/DEAD ANALYSIS portion of the algorithm of FIG. 8;
  • FIG. 10 shows a more detailed flow diagram of the TRANSLATE INSTRUCTIONS portion of the algorithm of FIG. 1.
  • the first steps of the algorithm represented by the flow chart of FIG. 1 are to read the input data 104 necessary to carry out the represented process.
  • This data includes the source program 108 in 8086 binary machine language and any application specific data (asd) 112 associated with the source binary program.
  • Read data input is represented by block 104 of FIG. 1.
  • the object in this PROCESS PROCEDURES 120 is to analyze the source binary program into its component instructions, which are grouped into "basic blocks" of sequential instructions terminated by a change of control (call, jump, or return) .
  • the PROCESS PROCEDURES 120 also builds a "flow graph", which is a data structure representing the flow of control among the basic blocks. Associated with each basic block are data structures containing information about the use of registers, flags, the stack, and memory within the block, along with a list of all instructions in the block.
  • the basic blocks are grouped into "procedures", which are entered from a call instruction and terminate with a return.
  • the ANALYZE COMPLETED FLOWGRAPH 124 is to analyze the data structures built by PROCESS PROCEDURES 120 in several different ways and pass the results of this analysis to the TRANSLATE INSTRUCTIONS block 132.
  • the ANALYZE COMPLETE FLOWGRAPH 124 performs five different types of analysis: "call-return analysis”, "live-dead analysis” on registers, "live-dead analysis” on flags, "byte orientation analysis", and "alignment analysis”. The results of this analysis are used by TRANSLATE INSTRUCTIONS 132 to generate optimized translated code.
  • the process enters the TRANSLATE INSTRUCTIONS algorithm block 132.
  • the object in the TRANSLATE INSTRUCTIONS 132 is to translate the analyzed instructions in the instruction lists of the basic blocks into equivalent instructions in 68020 binary machine language, using the data developed by the ANALYZE COMPLETED FLOWGRAPH 124 to make the translated code sequences optimally short.
  • FIG. 2 shows an overview of the PROCESS PROCEDURES process 120.
  • the process manipulates data structures called Procedure Blocks (PBs) , which can be linked onto up to three different queues: the new procedure queue, the upward procedure queue, and the downward procedure queue.
  • PBs Procedure Blocks
  • PB exists for every procedure in the program being analyzed.
  • the first step of the PROCESS PROCEDURES process 120 is to build an empty PB on the new procedure queue. This step is represented by block 204 of FIG. 2.
  • the next step, represented by block 208, is to determine whether any PBs exist on the new procedure queue. (The first time through the loop the answer is, of course, yes.) If a PB is on the queue, the process moves to block 210, which is responsible for removing the empty PB from the new procedure queue and initializing it, that is, filling in the starting values in the PB. After the step represented by block 210, the process moves to block 220, which represents the PROCESS A PROCEDURE algorithm.
  • This algorithm 220 performs as much processing on the procedure represented by the PB as can be done at the current point in the analysis. As many basic blocks are built as can be found in this procedure.
  • One result of this algorithm's operation may be to cause new PBs to be put on the new procedure queue, or existing PBs (including the present one) to be put on either the downward procedure queue or the upward procedure queue.
  • This step determines again if any PBs exist on the new procedure queue (some may have been created by the PROCESS A PROCEDURE algorithm) . Again, the process moves to block 210 and thence to 220 and back to 208 if a PB is found on the queue, with this loop executing until no new PBs remain on the new procedure queue.
  • the process moves on to the decision step represented by block 212, which determines if any PBs are on the downward procedure queue. If any are found, the process moves to block 214, which removes the PB from the queue for processing, and on to block 220 (PROCESS A PROCEDURE) .
  • the result of this step may be to create new PBs, so the process moves back to 208, and this cycle continues until all PBs have been removed fro both the new procedure queue and the downward procedure queue.
  • the process moves to the step represented by block 216 and decides if there are any PBs on the upward procedure queue. If there are, they are processed just like the PBs on the downward queue, until no PBs remain on any of the three queues, then the whole PROCESS PROCEDURES algorithm exits.
  • FIG. 3 shows the details of the PROCESS A PROCEDURE block 220 shown in FIG. 2.
  • the binary compiler manipulates four queues of data structures called Basic Blocks (BBs) .
  • BBs Basic Blocks
  • the four queues are: new queue, config queue, unknowns queue, and uses queue.
  • One BB is associated with each basic block in the procedure.
  • the first step in this process is to build all BBs that can be identified in the procedure (304).
  • FORWARD FLOW ANALYSIS is performed (block 308), then BACKWARD FLOW ANALYSIS (312), and finally UNKNOWNS ANALYSIS (320) . If any BBs remain on any of the four queues after these steps (see block 3200, then the process repeats steps 304 through 316, and this loop is iterated until no BBs remain on any queues.
  • FIG. 4 shows the details of the BUILD BASIC BLOCKS
  • the first step (402) is to take the first available BB off the new queue (one of the four BB queues mentioned above) , and then sequentially disassemble instructions beginning at the starting address in the BB, until a jump, call, return, or interrupt instruction (known as the termination instruction) is reached.
  • An encoded representation of the disassembled instructions is stored in a data structure called the Instruction List associated with the BB.
  • the next step (404) is to link the current BB with the BB whose code begins immediately after the current BB's termination instruction (th s BB is called the immediate successor) . If no immediate successor BB has yet been created, the process now creates a new BB with this address, links it to the current BB, and also puts it on the new queue. If an immediate successor already exists, it is put on the config queue (another of the four BB queues) .
  • the next step (408) is to perform forward flow analysis within the current BB.
  • the BBs that precede the current BB are all called its predecessors; they are either the immediate predecessors in the sense of the previous paragraph, or they are BBs whose termination instruction resulted in a transfer of control to the current BB.
  • the result of this operation is the forward data of the current BB, which is stored in a data structure associated with the BB.
  • next steps depend on whether the termination instruction of the current BB is a call, a computed jump, or an interrupt (block 412) . If it is (420) , then the BB is put on the unknowns queue (another of the four BB queues). If it is not (i.e., if the termination instruction is a simple jump) , then the BB is linked to the BB associated with the code at the jump's target address. A new BB is created and put on the new queue, if no BB exists for that address. An existing BB is put on the config queue. (See 416) .
  • the current BB is put on the uses queue (the last of the four BB queues) . Then a check is made to see if the new queue is empty (428) . If it is not, the process performs steps 402 through 428 again repeatedly until the new queue is empty.
  • FIG. 5 shows the details of the FORWARD FLOW ANALYSIS algorithm of FIG. 3, represented by block 308, which performs the forward flow analysis on all the BBs in a procedure.
  • the first step (504) is to take a BB off the config queue. Then.the forward data from all predecessors to the BB is propagated through the BB and stored in its forward data structure (blocks 508 and 512) . If the immediate predecessor ends with a call instruction, the data is first propagated through the called procedure before it is propagated through the BB. Then a check is made (516) to determine if the current BB's forward data has been modified. If so, all successor BBs are put on the config queue (520) . In either case, a check is made to see if any BBs are left on the config queue (524) , and if there are, the whole loop from 504 to 524 is performed again repeatedly until no BBs remain on the config queue.
  • FIG. 6 shows the details of the BACKWARD FLOW ANALYSIS algorithm of FIG. 3, represented by block 312, which performs the backward flow analysis on all the BBs in a procedure.
  • the first step (604) is to take a BB off the uses queue. Then the backward data (expression lists) from all successors to the BB is propagated back through the BB and stored in its backward data structure (blocks 608 and 612) . If any successor ends in a call instruction, the data is first propagated through the called procedure before it is propagated through the BB. Then a check is made (616) to determine if the current BB's backward data has been modified. If so, all predecessor BBs are put on the uses queue (620) . In either case, a check is made to see if any BBs are left on the uses queue (624) , and if there are, the whole loop from 604 to 624 is performed again repeatedly until no BBs remain on the uses queue.
  • FIG. 7 shows the details of the UNKNOWNS ANALYSIS algorithm of FIG. 3, represented by block 316, which performs the analysis on the unknown BBs in a procedure.
  • the first step (704) is to take a BB off the unknown queue. Then an attempt is made to calculate the computed jump or call address, using data in the asd file, if necessary (706) . The process then splits (712) depending on the result of this attempt. If the computation successfully determined the target address, a link is built to the target BB. A new BB is created on the new queue, if no BB exists for that address; an existing BB is put on the config queue.
  • the BB itself is put on the uses queue, and that entry is removed form the unknown list of the procedure's PB (724) . If the attempt to compute the target address was unsuccessful (720) , the BB is put back on the unknown queue and an entry is made in the unknown list of the procedure's PB. In either case, a check (728) is made to see any BBs remain on the unknown queue whose unknown list entry has not been processed. If any remain, the entire loop from 704 to 728 is performed again repeatedly until no unprocessed BBs remain on the unknowns queue.
  • FIG. 8 shows the details of the ANALYZE COMPLETED FLOWGRAPH algorithm of the FIG. 1 process, represented by block 124, which performs the global flow analysis on the completed flowgraph in preparation for the code generation stage.
  • the first step 804 is the sorting stage where the complete set of basic blocks are sorted into order by increasing address, using a standard sort algorithm.
  • the sort algorithm used is a version of the insertion sort algorithm described in D.E. Knuth The Art of Computer Programming, Vol. 3., Sorting and Searching, , Addison-Wesley, 1973, Reading, Massachusetts, pages 80 - 102.
  • the process moves to an optional stage (808) that optimizes the use of jump, call, and return addresses for the particular case of translating programs from 8086 code into 68020 code. This stage will not be present in the general case.
  • FLOWGRAPH algorithm 124 This step performs a global flow analysis of the completed flowgraph, computing "live-dead" data for registers and flags. This data specifies whether source machine condition flags (e.g., CARRY or OVERFLOW) and registers are used by subsequent instructions ("live") or not used ("dead") . This information is used by the subsequent TRANSLATE INSTRUCTIONS algorithm 132 in FIG. 1 to generate optimized target code, by only generating instructions to preserve or simulate live condition flag values and by not preserving data in dead registers. Then the process moves to another optional stage (816) , which performs various "peep-hole” optimizations that are dependent on the particular case of translating programs from 8086 code into 68020 code. FIG.
  • FIG. 9 shows the details of the stage represented by block 812 in FIG. 8., that is, the LIVE-DEAD ANALYSIS algorithm.
  • PBs Procedure Blocks
  • BBs Basic Blocks
  • the first step (904) is to put the PBs for all non-returning procedures (that is procedures that do not return to another procedure) on the downward queue.
  • the next step (908) is to check whether there are any PBs on the downward queue. If not, the process checks (912) to see if there are any PBs on the upward queue.
  • step 916 which computes live-dead data and the transfer function (that is, the effect the procedure has on live-dead data coming from other procedures) for the procedure. This step terminates when the procedure is completely analyzed or when the process encounters a call instruction whose called procedure has not been previously analyzed. Then the process continues to step 920, which determines whether step 916 terminated because the procedure was completely analyzed or because a call to an unanalyzed procedure was reached. If the procedure was completed, the process moves to step 924, which puts the PBs for all procedures that call the completed one on the upward queue. If step 916 terminated because .a call to an unanalyzed procedure was reached, the unanalyzed procedure's PB is put on the downward queue in step 928. In either case, the process continues back to step 908 and iterates until all procedures have been fully analyzed.
  • FIG. 10 shows the details of the TRANSLATE INSTRUCTIONS algorithm of the FIG. 1 process, represented by block 132, which performs the 68020 code generation.
  • the first step (1204) is to get a BB from the chain of BBs arranged in increasing address order that is produced by step 804.
  • an instruction's encoded opcode, addressing mode, and attributes are read from the instruction list associated with the BB (1208) .
  • These encoded values are used as indices to select a short segment of translated 68020 binary code (often just one instruction) from a table (1212) .
  • the 68020 code is saved in a data structure (1216) , then the process proceeds to convert the next instruction by performing steps 1208 through 1220 repeatedly until no more instructions remain in the BB's instruction list. At this point the 68020 instructions representing the BB are output to a file (1222) . Then the process moves to the next BB and performs steps 1204 through 1224 until no BBs remain to be translated.

Landscapes

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

Abstract

On a mis au point un traitement machine dans lequel un premier programme dans un language machine binaire est traduit dans un second programme dans un autre langage machine binaire. Le traitement consiste à désassembler le premier programme binaire (120), à analyser le premier programme afin de produire des données d'analyse de flux globales (124) et à utiliser ces données pour achever le désassemblage. Ce traitement utilise les données d'analyse de flux globales afin de créer le second programme (140), qui est une version en langage machine binaire traduite du premier programme.
EP19890908667 1988-07-29 1989-07-10 Machine process for translating programs in binary machine language into another binary machine language Withdrawn EP0428560A4 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US22607888A 1988-07-29 1988-07-29
US226078 1988-07-29

Publications (2)

Publication Number Publication Date
EP0428560A1 true EP0428560A1 (fr) 1991-05-29
EP0428560A4 EP0428560A4 (en) 1992-04-01

Family

ID=22847458

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19890908667 Withdrawn EP0428560A4 (en) 1988-07-29 1989-07-10 Machine process for translating programs in binary machine language into another binary machine language

Country Status (3)

Country Link
EP (1) EP0428560A4 (fr)
JP (1) JPH04500132A (fr)
WO (1) WO1990001738A1 (fr)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5313614A (en) * 1988-12-06 1994-05-17 At&T Bell Laboratories Method and apparatus for direct conversion of programs in object code form between different hardware architecture computer systems
US5317740A (en) * 1991-03-07 1994-05-31 Digital Equipment Corporation Alternate and iterative analysis of computer programs for locating translatable code by resolving callbacks and other conflicting mutual dependencies
US5598560A (en) * 1991-03-07 1997-01-28 Digital Equipment Corporation Tracking condition codes in translation code for different machine architectures
US5652869A (en) * 1991-03-07 1997-07-29 Digital Equipment Corporation System for executing and debugging multiple codes in a multi-architecture environment using jacketing means for jacketing the cross-domain calls
US5507030A (en) * 1991-03-07 1996-04-09 Digitial Equipment Corporation Successive translation, execution and interpretation of computer program having code at unknown locations due to execution transfer instructions having computed destination addresses
US5307492A (en) * 1991-03-07 1994-04-26 Digital Equipment Corporation Mapping assembly language argument list references in translating code for different machine architectures
US5428786A (en) * 1991-03-07 1995-06-27 Digital Equipment Corporation Branch resolution via backward symbolic execution
US5450575A (en) * 1991-03-07 1995-09-12 Digital Equipment Corporation Use of stack depth to identify machine code mistakes
DE69225982T2 (de) * 1991-03-07 1999-02-18 Digital Equipment Corp Verfahren und Gerät zur Rechnercode-Verarbeitung in einem Codeübersetzer
US5287490A (en) * 1991-03-07 1994-02-15 Digital Equipment Corporation Identifying plausible variable length machine code of selecting address in numerical sequence, decoding code strings, and following execution transfer paths
US5432795A (en) * 1991-03-07 1995-07-11 Digital Equipment Corporation System for reporting errors of a translated program and using a boundry instruction bitmap to determine the corresponding instruction address in a source program
US5301325A (en) * 1991-03-07 1994-04-05 Digital Equipment Corporation Use of stack depth to identify architechture and calling standard dependencies in machine code
WO1992015947A1 (fr) * 1991-03-07 1992-09-17 Digital Equipment Corporation Systeme de debogage ameliore de logiciel et procede specialement adapte au debogage de code dans un environnement multi-architecture
US5339238A (en) * 1991-03-07 1994-08-16 Benson Thomas R Register usage tracking in translating code for different machine architectures by forward and reverse tracing through the program flow graph
US5784552A (en) * 1993-07-28 1998-07-21 Digital Equipment Corporation Debugging a computer program by simulating execution forwards and backwards in a main history log and alternative history logs
EP0703532B1 (fr) * 1994-09-22 2001-11-28 Sun Microsystems, Inc. Information encastrée de déroulement de programme d'ordinateur pour la manipulation du code en résultant
US6233733B1 (en) * 1997-09-30 2001-05-15 Sun Microsystems, Inc. Method for generating a Java bytecode data flow graph
US5966541A (en) 1997-12-04 1999-10-12 Incert Software Corporation Test protection, and repair through binary-code augmentation
US6317873B1 (en) * 1998-10-14 2001-11-13 Alcatel Usa Sourcing, L.P. Assembly language translator
US6308321B1 (en) * 1998-12-11 2001-10-23 Incert Software Corporation Method for determining program control flow
US6662354B1 (en) * 1999-01-29 2003-12-09 Unisys Corporation Determining destinations of a dynamic branch
US6353924B1 (en) 1999-02-08 2002-03-05 Incert Software Corporation Method for back tracing program execution
US6804814B1 (en) 1999-12-29 2004-10-12 Veritas Operating Corporation Method for simulating back program execution from a traceback sequence
US6748584B1 (en) 1999-12-29 2004-06-08 Veritas Operating Corporation Method for determining the degree to which changed code has been exercised
US6745383B1 (en) 1999-12-29 2004-06-01 Veritas Operating Corporation Early warning mechanism for enhancing enterprise availability
US6662361B1 (en) * 2000-01-14 2003-12-09 International Business Machines Corporation Method, system, program, and data structures for transforming an instruction in a first bit architecture to an instruction in a second bit architecture
US7246267B2 (en) * 2001-10-01 2007-07-17 Tektronix, Inc. Logic analyzer having a disassembler employing symbol table information for identifying op-codes
US7673293B2 (en) 2004-04-20 2010-03-02 Hewlett-Packard Development Company, L.P. Method and apparatus for generating code for scheduling the execution of binary code
CN101271398B (zh) * 2007-03-23 2010-06-09 北京大学 多路分支结构的识别方法
US20080250231A1 (en) * 2007-04-03 2008-10-09 Kabushiki Kaisha Toshiba Program code conversion apparatus, program code conversion method and recording medium
US7802299B2 (en) 2007-04-09 2010-09-21 Microsoft Corporation Binary function database system
US8869109B2 (en) 2008-03-17 2014-10-21 Microsoft Corporation Disassembling an executable binary
CN103235724A (zh) * 2013-05-10 2013-08-07 中国人民解放军信息工程大学 基于原子操作语义描述的多源二进制代码一体化翻译方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372835A2 (fr) * 1988-12-06 1990-06-13 AT&T Corp. Méthode de traduction

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4667290A (en) * 1984-09-10 1987-05-19 501 Philon, Inc. Compilers using a universal intermediate language

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372835A2 (fr) * 1988-12-06 1990-06-13 AT&T Corp. Méthode de traduction

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DIGEST OF PAPERS SPRING COMPCON 89 34TH IEEE COMPUTER SOCIETY INTERNATIONAL CONFERENCE 27 February 1989, SAN FRANCISCO, CA, US pages 282 - 287; J. BANNING: 'THE XDOS BINARY CODE CONVERSION SYSTEM' *
PROCEEDINGS IEEE 1987 NATIONAL AEROSPACE AND ELECTRONICS CONFERENCE NAECON 1987 vol. 3/4, 18 May 1987, DAYTON CONVENTION CENTER pages 728 - 731; R.A. LAWLER: 'AUTOMATIC TRANSLATION OF ASSEMBLY LANGUAGE SOFTWARE' *
See also references of WO9001738A1 *
W.M. WAITE, G.GOOS 'COMPILER CONSTRUCTION' 1985 , SPRINGER VERLAG , NEW YORK, US CHAPTER 13: 'OPTIMIZATION', pages 326 - 357; *

Also Published As

Publication number Publication date
EP0428560A4 (en) 1992-04-01
WO1990001738A1 (fr) 1990-02-22
JPH04500132A (ja) 1992-01-09

Similar Documents

Publication Publication Date Title
EP0428560A1 (fr) Traitement machine, pour la traduction de programmes en langage machine binaire en un autre langage machine binaire
JP4573189B2 (ja) プログラムコード変換方法
US7877741B2 (en) Method and corresponding apparatus for compiling high-level languages into specific processor architectures
US6571385B1 (en) Early exit transformations for software pipelining
US20030088860A1 (en) Compiler annotation for binary translation tools
JPH05257709A (ja) 並列化判別方法およびそれを用いた並列化支援方法
JPH07105012A (ja) 言語処理プログラムのコンパイル処理方式
US6658655B1 (en) Method of executing an interpreter program
US20180165079A1 (en) Instruction-set simulator and its simulator generation method
JPH04330527A (ja) プログラムの最適化方法及びコンパイラ・システム
EP0703532B1 (fr) Information encastrée de déroulement de programme d'ordinateur pour la manipulation du code en résultant
US7120905B2 (en) System and method for transformation of assembly code for conditional execution
KR0125605B1 (ko) 프로그램의 아키덱쳐 변환방법 및 장치와 그 방법 및 장치를 사용하여 프로그램의 동작을 검증하는 방법 및 장치
US7698534B2 (en) Reordering application code to improve processing performance
JP2002527816A (ja) プログラム最適化装置および方法
JPH08305583A (ja) Ｃｐｕシミュレーション方法
KR100309632B1 (ko) 최적화이미지에대응한디버그용소스파일을생성하는언어처리시스템및방법
JP3266097B2 (ja) 非リエントラントプログラムの自動リエントラント化方法及びシステム
EP0180077A2 (fr) Système de traitement de données pour la compilation de programmes d'ordinateur
Spinellis Declarative peephole optimization using string pattern matching
JPH02176938A (ja) 機械語命令最適化方式
JP4158239B2 (ja) 情報処理装置および方法、並びに記録媒体
US20090112568A1 (en) Method for Generating a Simulation Program Which Can Be Executed On a Host Computer
JP3323147B2 (ja) コンパイル装置、コンパイル方法およびコンパイラプログラムを記録した記録媒体
JP3551352B2 (ja) ループ分割方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19901227

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE FR GB IT LI LU NL SE

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HUNTER, COLIN, B.

Inventor name: BANNING, JOHN, P.

Inventor name: PUFAL, HANS

A4 Supplementary search report drawn up and despatched

Effective date: 19920207

AK Designated contracting states

Kind code of ref document: A4

Designated state(s): AT BE CH DE FR GB IT LI LU NL SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 19930202