earl@wright.mips.com (Earl Killian) (11/20/88)
In article <10643@tekecs.TEK.COM>, andrew@frip (Andrew Klossner) writes: > "O.K. who will confess to having worked on the object to object > translation problem?" >We've played around with it. This usually comes up when you want to >take existing object code from another system and run it on yours. The >big problems turn out to be the environment -- mapping Brand X syscalls >into your syscall, or spraying Brand Y pixel blits to your screen. I agree with Andrew's statements 100%. MIPS has done it twice, once translating MIPS code to VAX code (in the early days before MIPS hardware) and once translating MIPS code to MIPS code (used for profiling (shipped as part of the compiler suite)). The hardest part is dealing with the environment, even when translating from MIPS->MIPS! By the way, MIPS machine code is particularly easy to translate to other machine code because the instructions are fixed size (fairly common these days) and tend to be single-purpose, i.e. not lots of useless side effects (still uncommon today). If the MIPS architecture becomes widespread, I wouldn't be surprised to see such translators crop up as a way of capturing applications quickly. Perhaps it could be the standard distribution format, the AIBI (architecture independent binary interface)? :-> To see what I mean about single-purpose instructions, consider translating machine code from a condition code architecture. Condition codes are the ultimate useless side effect. To translate an add instruction you generate an add instruction to compute the result, and then 14 more instructions to generate N,Z,C,V etc. Not acceptable. So you're forced to do lifetime analysis to figure out which, if any, of the condition codes are later used, and where, so you can generate the code you really meant. You can do it, but... Condition codes are not only harmful for translation, but for performance. 15% of instructions are conditional branches. If you take two instructions instead of one to do this simple operation (set the condition codes and then branch on them), you've just forced your computer to execute 15% more instructions. --
aglew@urbsdc.Urbana.Gould.COM (11/20/88)
>The Hunter XDOS system attempts to tranlate DOS programs to their Unix >equivalents statically, which is hopeless without manual intervention or a lot >of a priori hints. There are, however, three other systems that do it >dynamically, packages from Insignia (a startup that seems to be partly in >California and partly in England), from Phoenix (the BIOS people), and from >IBM. Each of these dynamically translate and run 8086 code on Unix hosts such >as 680X0, SPARC and ROMP (the RT PC's processor.) They get very credible >performance, I saw an early version of Phoenix's running a copy-protected >version of spacewar in close to real time on a Sun-3, limited by paging. It >emulated the PC's disk controller well enough to satisfy the copy protection >code, which I found quite impressive. >-- >John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 How does "dynamic translation" differ from interpretation?
bcase@cup.portal.com (Brian bcase Case) (11/21/88)
WRT to object-object compilation: >MIPS has done it twice, once translating MIPS code to VAX code (in the >early days before MIPS hardware) and once translating MIPS code to >MIPS code (used for profiling (shipped as part of the compiler >suite)). The hardest part is dealing with the environment, even when >translating from MIPS->MIPS! Earl, you translated MIPS *binary* code to VAX and MIPS *binary* code to MIPS? I thought it was MIPS assembly code.... How did you deal with the jump tables associated with switch statements? What strategy did you use for other indirect branches (e.g., returns)? >By the way, MIPS machine code is particularly easy to translate to >other machine code because the instructions are fixed size (fairly >common these days) and tend to be single-purpose, i.e. not lots of >useless side effects (still uncommon today). Yeah, but try it for a 68K or VAX or 386. It is hard to tell code from data. I have "done" object-object code translation three times now (actually built two monsters and spec'd a third). The easiest is when a RISC is the source: at least then you can compile areas of the object image that look like data but might be code in a reliable way: if you translate some data as code, you've only done extra work and increased the size of the image on disk, but at least it's bullet-proof. WRT to comments made about the Phoenix and Insignia Solutions' "solutions" to this problem: they are interpreters, perhaps incrementally-compiling interpreters, but interpreters nontheless. The Hunter Systems' approach is the only true, static compiler of which I know. At last the count, the Insignia solutions ran applications in close to real time on a SUN-3 if you consider PC-XT speed real time (they might have improved this significantly since I last saw a demo). Hunter Systems' stuff runs at something like 80386 speed on a SUN-3. Of course, the Hunter Systems' stuff requires some up-front, human labor to create key files.
johnl@ima.ima.isc.com (John R. Levine) (11/21/88)
In article <28200239@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >How does "dynamic translation" differ from interpretation? Interpreters crack one instruction at a time; the dynamic translation approach translates chunks of object code to host machine target code and reuses the translated stuff unless stores into the code space force it to retranslate. Such stores are pretty common on PCs, since most applications of any size are overlaid. The effect is the same except that translating a block at a time seems to get an order of magnitude better performance than doing one instruction at a time. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Kids spend more time with their parents than parents spend with their kids.
earl@wright.mips.com (Earl Killian) (11/23/88)
In article <11560@cup.portal.com>, bcase@cup (Brian bcase Case) writes: >Earl, you translated MIPS *binary* code to VAX and MIPS *binary* code >to MIPS? I thought it was MIPS assembly code.... In both cases it was MIPS object code, fully linked, ready to run. MIPS object code is much easier to deal with than assembler: no parsing! It's also very convenient this way. You want to profile nroff? It's as simple as: # instrument installed binary pixie /usr/bin/nroff -o nroff.pixie # takes less than one second of cpu time ./nroff.pixie nroffinput > nroffouput # takes about 2x longer than running unpixified nroff prof nroff > nroff.prof # you're done which is a lot easier than recompiling everything -p, and having -p libraries of everything on hand. >How did you deal with the jump tables associated with switch statements? >What strategy did you use for other indirect branches (e.g., returns)? Both versions used table lookup. To jump to a computed address, use the address as an index into a table to get the address of the translation. One table entry for every instruction, so the table is identically the size of the original text section, so it's no big deal. This technique breaks down for sparse address spaces. Fortunately (for this application), Unix address spaces are pretty constrained. Another technique would be to use relocation information in the binary. pixie works without relocation, at the cost of the table. -- UUCP: {ames,decwrl,prls,pyramid}!mips!earl USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086
karl@ficc.uu.net (karl lehenbauer #) (11/24/88)
In reference to the discussion of the differences between static and dynamic binary translation, HP has a large body of HP3000 customers they want to move to their proprietary OS that they run on the Spectrum. Consequently, they put a lot of time into the binary translation problem. They translate all they can statically, but they also can do complete emulation at run time -- this was necessitated by the fact that the 3000 has an instruction which causes the top of the stack to be executed as an instruction, ouch! -- -- +1 713 274 5184, uunet!ficc!karl -- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478