Re: binary-compiler from Apple?

In article 92-04-030 taihou@iss.nus.sg (Tng Tai Hou) writes:
>Apple is doing a binary-compiler for its new line of PowerPC Macs. It
>takes in existing 680x0 code and translate opcodes for the PowerPC chip.
>Can anyone tell me if this is logical, or right approach? Seems to be a
>great idea. Why hasn't anyone thought of it before?


It's been thought of many times, and has seen operational use. You can
buy commercial products that do this for x86 code in particular.


The main problem is performance, and how serious it is depends on the
nature of the two machines. Ideally, they should have the same byte
order, the "source" machine should have substantially fewer registers than
the "object" machine, and the "source" machine should not have condition
codes. Wrong byte order, inadequate registers, or the need to simulate
condition codes can result in very bulky and very slow code, unless
perhaps you optimize heavily. Mismatches in memory model can also be
troublesome; you'd really like addresses on the source machine to be
usable as-is on the object machine. One area where nobody has found a
good solution (that I know of) is mapping branch addresses that the
program computes in complex ways; the usual brute-force solution is a
table, one entry per possible source-machine branch target (that's one
entry for each and every instruction!), used to map computed branch
targets into the real targets.
--
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu utzoo!henry
--

Return to the comp.compilers page.
Search the comp.compilers archives again.