A binary recompiler is a compiler that takes executable binary files as input, analyzes their structure, applies transformations and optimizations, and outputs new optimized executable binaries.[1]
The foundation to the concepts of binary recompilation were laid out by Gary Kildall[2][3][4][5][6][7][8] with the development of the optimizing assembly code translator XLT86 in 1981.[4][9][10][11]
[…] "Unless you have a translating scheme that takes account of the peculiar idiosyncrasies of the target microprocessor, there is no way that an automatic translator can work," explains Daniel Davis, a programmer with Digital Research. "You'll end up with direct transliterations." […] In spite of all these limitations, progress has been made recently in the development of translators. Most notably, Digital Research has introduced its eight- to 16-bit assembly code translator. Based on research performed by Digital Research president Gary Kildall, the XLT86 appears to offer advances over previously available software translator technology. Like Sorcim's Trans and Intel's Convert 86, Kildall's package translates assembly-language code from an 8080 microprocessor to an 8086. However, Kildall has applied a global flow analysis technique that takes into account some of the major drawbacks of other translators. The procedure analyzes the register and flag usage in sections of 8080 code in order to eliminate nonessential code. According to Digital Research programmer Davis, the algorithm Kildall uses allows the translator to consider the context as it translates the program. Until now, one of the major problems with any translator program has been the inability of the software to do much more than transliteration. If Digital Research's new translator actually advances the technology to the point where context can be considered, then more software translators may proliferate in the microcomputer marketplace.
In March, 1995, the Software Publishers Association posthumously honored Gary for his contributions to the computer industry. They listed some of his accomplishments: […] In the 1980s, through DRI, he introduced a binary recompiler. […]
[…] Rolander: I mentioned earlier that Gary liked to approach a problem as an architect. […] And he would draw the most beautiful pictures of his data structures. […] And when he finished that […] and was convinced those data structures were now correct, he would go into just an unbelievable manic coding mode. He would just go for as many as 20 hours a day […] he was just gone during these periods of time. On a couple of those occasions, when he'd get something running the first time, which could be in the middle of night. And all you who have written software have seen that, for example, that the first time it comes up on the screen, you've got to tell somebody. My wife Lori will tell you that I had a couple of those calls in the middle of the night, LOGO was one example, XLT 86 was another, where he got it running the first time, and he had to have somebody see it. So it didn't matter what time it was, he'd call me, I'd have to come over and see it running. […][2][3] (33 pages)
[…] XLT-86 is an analytical translator program written in PL/I-80. It reads the entire 8080 source program, assembles it to machine code, analyzes the register, memory and flag utilization, and emits an optimized 8086 assembly-language program. […] The program translation proceeds in a five-step process. First, the program is scanned and assembled to produce symbol values and locations. Second, the program structure is analyzed and decomposed into basic blocks. Third, the basic blocks are analyzed to determine program flow and resource usage. Forth, the block structure and register allocation data is gathered into a listing for the user. Fifth, the flow information and source program are used to produce the 8086 source program. […]
[…] Kildall: […] A year and a half ago I was probably spending 75% of my time on the business and 25% on programming. XLT-86 was a product I was working on at that time, and it took me nine months to do it. That would have been a three-month project if I had been able to concentrate on it. […]
[…] PC: What are some of the complexities involved in translating a program from 8080 to 8086 form? Kildall: Straight translations at the source program level you can do pretty much mechanically. For example, an 8080 "Add immediate 5" instruction turns into an "Add AL 5" on the 8086 — very straightforward translation of the op codes themselves. The complexity in mechanical translation comes from situations such as this: The 8080 instruction DAD H takes the HL register and adds DE to it. For the 8086 the equivalent instruction would be something like ADD DX BX, which is fine, no particular problem. You just say the DX register is the same as HL and BX the same as DE. The problem is that the 8086 instruction has a side effect of setting the zero flag, and the 8080 instruction does not. In mechanical translation you end up doing something like saving the flags, restoring the flags, doing some shifts and rotates, and so forth. These add about five or six extra instructions to get the same semantic effect. There are a lot of sequences in 8080 code that produce very strange sequences in 8086 code; they just don't map very well because of flag registers and things of that sort. The way we get software over is a thing called XLT-86. It's been out six months or so. PC: By "better" code do you mean smaller? Kildall: Twenty percent smaller than if you just took every op code and did a straight translation, saving the registers to preserve semantics. PC: How does the size of the translated program compare to the 8080 version? Kildall: If you take an 8080 program, move it over to 86 land and do an XLT-86 translation, you'll find that it is roughly 10 to 20 percent larger. With 16-bit machines it's more difficult to address everything; you get op codes that are a little bit bigger on the average. An interesting phenomenon is that one of the reasons you don't get a tremendous speed increase in the 16-bit world is because you're running more op codes over the data bus. […]