this paper is structured in the following way: a thorough description of the structure of a decompiler, followed by the description of our implementation of an # An idiom is a sequence of instruction that forms a logical entity and has a meaning that cannot be derived by considering the primary meanings of the individual instructions # # # # HLL program (language dependent) Back-end (analysis) UDM (machine dependent) Front-end binary program Figure 1. Decompiler modules automatic decompiling system, and conclusions. The paper is followed by the definitions of graph theoretical concepts used throughout the paper (Appendix I), and sample output from different phases of the decompilation of a program (Appendix II)

Program slicing is a technique for determining the set of statements of a program that potentially affect the value of a variable at some point in the program. Intra and interprocedural slicing of high-level languages has greatly been studied in the literature; both static and dynamic techniques have been used to aid in the debugging, maintenance, parallelization, program integration, and dataflow testing of programs. In this paper we explain how to apply conventional intraprocedural static analysis to binary executables, for the purposes of static analysis of machine-code and assembly code, such as debugging code and determining the instructions that affect an indexed jump or an indirect call on a register. This analysis is useful in the decoding of machine instructions phase of reverse engineering tools of binary executables, such as binary translators, disassemblers, binary profilers and binary debuggers. 1 Introduction It is well known that a series of programmers worked for days...

Embedded hard real-time software systems often need finegrained parallelism and precise control of timing, things typical real-time operating systems do not provide. The Esterel language has both, but compiling large Esterel programs has been challenging, producing either needlessly slow or large code. This paper presents the first Esterel compiler able to compile large Esterel programs into fast, small code. By choosing a concurrent control-flow graph as its intermediate representation, it preserves many of the control constructs to produce code that can be a hundred times faster and half the size than that from other compilers with similar capacity. The primary contribution is an algorithm that generates efficient sequential code from a concurrent control-flow graph. While developed specifically for compiling Esterel, the algorithm could be used to compile other synchronous languages with fine-grained parallelism. Keywords--- Embedded systems, Esterel, compilers, real-time language, concurrency, code generation, synchronous, reactive I.

Translation of assembly code to high-level language code is of importance in the maintenance of legacy code, as well as in the areas of program understanding, porting, and recovery of code. We present techniques used in the asm2c translator, a SPARC assembly to C translator. The techniques involve data and control flow analyses. The data flow analysis eliminates machine dependencies from the assembly code and recovers high-level language expressions. The control flow analysis recovers control structure statements. Simple data type recovery is also done. The presented techniques are extensions and improvements on previously developed CISC techniques. The choice of intermediate representation allows for both RISC and CISC assembly code to be supported by the analyses. We tested asm2c against SPEC95 SPARC assembly programs generated by a C compiler. Results using both unoptimized and optimized assembly code are presented. 1 Introduction Recovery of high-level language cod...

This paper concentrates on optimizations which rely on the knowledge of the target architecture, so they cannot be performed by the compiler which generates the class file, since the target machine is not known at that time. At the same time, the optimization techniques we consider cannot be easily performed on bytecodes directly and require the recovery of high-level representation of the code which is being optimized. Briki is a compiler developed to research the issues of potential benefits of high-level optimizations for Java programs. Briki reads in a Java program distributed in the bytecode form, converts it into JavaIR (an intermediate representation used to represent Java programs in our compiler), performs the optimizations, and writes out the optimized code. We are primarily interested in the configuration of Briki which performs JIT compilation, i.e., a compiler which is integrated with the virtual machine and generates machine code for immediate execution. The current implementation of Briki, which was used in the experiments presented in this paper, reads in a class file and writes the optimized code to another file in the form of Java source. We chose off-line compilation and Java source as the output form for the ease of debugging and better understanding of the quality of the recovered code. A JIT implementation of Briki which will integrate our compiler with kaffe [3], a publicly available JIT Java system, is under way. Section 2 presents the organization of Briki including a brief discussion of JavaIR,

We describe a new processing architecture, known as a warp processor, that utilizes a field-programmable gate array (FPGA) to improve the speed and energy consumption of a software binary executing on a microprocessor. Unlike previous approaches that also improve software using an FPGA but do so using a special compiler, a warp processor achieves those improvements completely transparently and operates from a standard binary. A warp processor dynamically detects the binary’s critical regions, re-implements those regions as a custom hardware circuit in the FPGA, and replaces the software region by a call to the new hardware implementation of that region. While not all benchmarks can be improved using warp processing, many can, and the improvements are dramatically better than achievable by more traditional architecture improvements. The hardest part of warp processing is that of dynamically re-implementing code regions on an FPGA, requiring partitioning, decompilation, synthesis, placement, and routing tools, all having to execute with minimal computation time and data memory so as to coexist on-chip with the main processor. We describe our results of developing a warp processor. We developed a custom FPGA fabric specifically designed to enable lean place and route tools, and we developed extremely fast and efficient versions of partitioning, decompilation, synthesis, technology mapping, placement, and routing. Warp processors achieve overall application speedups of 6.3X with energy savings of 66 % across a set of embedded benchmark applications. We

Java, a new object-oriented member of the C family of languages, has become popular in part because it emphasizes portability. Portability is achieved by compiling programs to machine-independent bytecodes that can be interpreted on a Java virtual machine. Unfortunately, interpreted performance does not match native code performance. A just-in-time compiler can regain performance without sacrificing portability by turning the bytecodes into native code at runtime. This idea has a proven track record: Deutsch and Schiffman presented a dynamic Smalltalk compiler in 1984 [5], and the Self system currently sports a dynamic type-feedback based optimizing compiler [12]. To study the performance potential of Java with this state-of-the-art optimization technology, we built Pep, a just-intime compiler from Java bytecodes to Self. Following translation by Pep, Java programs can execute on the Self virtual machine and benefit from the optimizations performed by Self's compiler. We describe the design and implementation of Pep, focusing on concepts and trade-offs, but also compare performance with the JDK 1.0.2 and 1.1 interpreters. 1

We evaluate a CISC interprocedural data flow technique for the recovery of high-level language code from assembly code

The extensive use of computers and networks worldwide has raised the awareness of the need for tools and techniques to aid in computer security analysis of binary code, such as the understanding of viruses, trojans, worms, backdoors and general security flaws, in order to provide immediate solutions with or without the aid of software vendors.

To compete with optimized C, object-oriented languages need classical optimizations as well as specific object-oriented optimizations. Therefore, a compiler infrastructure that enables object-oriented compiler research isof great interest for the research community. The SUIF compiler system with the OSUIF extension offers such a research environment. SUIF defines an intermediate representation for procedural languages and offers standard optimization passes. OSUIF extends SUIF with an intermediate representation tailored towards object-oriented languages, hence allowing specific object-oriented optimizations. To enable Java-related compiler research in (O)SUIF, we have implemented j2s, a Java bytecode front end for the OSUIF/SUIF 2.0 compiler system. Our compiler uses off-line compilation, so that the whole program is known at compile time. Thus, static whole-program optimizations such as class hierarchy analysis and type inference can be implemented with (O)SUIF and applied during the compilation. j2s supports the complete Java Virtual Machine specification, except for threads and exception handling, which are currently not supported by the runtime system and (O)SUIF. Because we implemented an off-line compiler, the dynamic loading of classes is also not supported. The compiler is divided into the (O)SUIF front end and the runtime system. The main part of