Re: Machine language and assembler translators?

glen herrmannsfeldt <gah@ugcs.caltech.edu>
26 Jun 2005 11:17:54 -0400

          From comp.compilers

Related articles
Machine language and assembler translators? jatinb@noida.hcltech.com (Jatin Bhateja, Noida) (2005-06-21)
Re: Machine language and assembler translators? vtsikoza@yahoo.com (2005-06-23)
Re: Machine language and assembler translators? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-06-23)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-06-23)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-06-26)
Re: Machine language and assembler translators? vtsikoza@yahoo.com (2005-06-30)
Re: Machine language and assembler translators? jcrens@earthlink.net (Jack Crenshaw) (2005-07-17)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-07-22)
Re: Machine language and assembler translators? toby@telegraphics.com.au (toby) (2005-07-22)
Re:Machine language and assembler translators? Robert.Thorpe@antenova.com (Robert Thorpe) (2005-07-22)
Re: Machine language and assembler translators? peter.jinks@manchester.ac.uk (Pete Jinks) (2005-07-22)
[6 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 26 Jun 2005 11:17:54 -0400
Organization: Compilers Central
References: 05-06-103 05-06-105
Keywords: translator, assembler

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


Post a followup to this message

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