Re: Machine language and assembler translators?

Vit wrote:
(snip, and previous snip regarding translation of object code
between architectures as an alternative to recompilation.)


> I doubt it is a reasonable idea. If you wish just to port the code
> so that it just works on another platform, then it is theoretically
> possible (though it may take less efforts to write an emulator). If
> you wish to gain a reasonable performance, then avoiding back-end's
> work is impossible.


For significantly different architectures there is likely a fairly
large performance penalty.


For subarchitectures, different branches of what is fundamentally the
same architecture, though, it may be more useful.


I have written similar discussions here before, but I believe it may
make a lot of sense in the continuing development of RISC machines.


If find it interesting that the S/360 architecture, though with some
improvements along the way, is still alive and well.


Now, consider that much of the advantage of RISC depends on the
compilers generating optimal code for the specific processor. That is,
not just at the architecture level but for what is sometimes called the
subarchitecture. (I first knew subarchitecture from Sun/SPARC where it
refers more to the MMU from the days of external MMU, but I believe the
term is appropriate.)


One of the early feature of RISC was branch delay slots. The proper use
of branch delay slot instructions, of optimizing for the branch
prediction logic, and other branch related instruction scheduling tricks
allow one to get the best performance out of a RISC machine. Yet all
these tricks are dependent on the specific details of the machine, the
subarchitecture, and likely result in code that performs poorly on
different machines with the same architecture, maybe only a year or
two later. It might be that some kind of object code translation
could help in the RISC case.


S/360 code likely runs fine, though maybe slightly less than optimal,
on current z/Architecture machines. That is, assembly code that is
now almost 40 years old!


-- glen

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