The structure of a decompiler is presented, along with a thorough description of the different modules that form part of a decompiler, and the type of analyses that are performed on the machine code to regenerate high‐level language code. The phases of the decompiler have been grouped into three main modules: front‐end, universal decompiling machine, and back‐end. The front‐end is a machine‐dependent module that performs the loading, parsing and semantic analysis of the input program, as well as generating an intermediate representation of the program. The universal decompiling machine is a machine‐ and language‐independent module that performs data and control flow analysis of the program based on the intermediate representation, and the program's control flow graph. The back‐end is a language‐dependent module that deals with the details of the target high‐level language. In order to increase the readability of the generated programs, a decompiling system has been implemented which integrates a decompiler, dcc, and an automatic signature generator, dccSign. Signatures for libraries and compilers are stored in a database that is read by the decompiler; thus, the generated programs can make use of known library names, such as WriteLn() and printf(). dcc is a decompiler for the Intel 80286 architecture and the DOS operating system. dec takes as input binary programs from a DOS environment and generates C programs as output. Sample code produced by this decompiler is given.
The circle is closed. The European Modula-2 Conference was originally launched with the goal of increasing the popularity of Modula-2, a programming language created by Niklaus Wirth and his team at ETH Zürich as a successor of Pascal. For more than a decade, the conference has wandered through Europe, passing Bled,
mburg is a tool for producing bottom up tree rewriters. It has been used for code selection in compilers. It produces hard coded tree pattern matchers from tree grammars, with dynamic programming at runtime. It is comparable in its capabilities with iburg[1], but has a rather different. implementation, and produces its output in ISO Modula-2. The source code for the tool is available by ftp. BackgroundBottom up tree rewriting is the method of choice for code selection in modern compilers. Given a tree gramrnar, and a cost expression for each production, it allows for optimM code selection from trees.The ibmy[1] tool has been widely used, and forms the basis for code selection in the widely available retargetable C cornpiler lcc [2]. The gardens point compilers written at Queensland University of Technology use a stack-based intermediate form [3] to communicate between target independent frontends and language independent backends. Our current backends target Intel 386, Mips, Sparc and Alpha architectures, and produce very high quality code using shadow stack automata for code selection. We have noticed however, that as each of our backends has evolved, the code selection automata have become increasingly complex, as we recognize increasing numbers of special case patterns.We decided to experiment with bottom up tree rewriting code selection as an alternative technology. In order to do this we created the mburg tool, created some alternative code selectors, and evaluated their performance. We are making the tool generally available in the hope that it will be of interest to two separate groups. Firstly, developers working with Modula-2 rather than the C language will find integration of the resulting code selectors simpler than is the case with iburg. Secondly, the implementation is sufficiently different from iburg to be of some intrinsic interest. The MBURG ToolCode selectors generated by mburg perform dynamic programming at compile-time, and make two passes over the subject trees. In the first pass, the nodes of the tree are labelled during a recursive bottom-up traversal. The labelling for each node encodes the minimal cost of placing the denoted value of that subtree in any of the possible "typeforms." The labelling also records the ordinal of the production rule which produces each of the minimal costs. This is the labelling pass.The second pass uses the state information to guide a top-down traversal, which performs a virtual rewriting of the tree. In this second pass the nodes are not visited in the order determined by the structure of the tree, but rather are visited in an order determined by the matched patterns of the production rules which are selected by the labelling. At each node a specified semantic action may be performed. This is the reduction pass.mburg currently produces the labelling pass and a single reduction pass completely automatically, requiring no hand-written code at all. This is sufficient for the production of virtual assembly language. We may at some future stage define declarative ...
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.