Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!prls!mips!earl@wright.mips.com
From: earl@wright.mips.com (Earl Killian)
Newsgroups: comp.arch
Subject: Re: object <-> object translation (was Re: VLIW)
Message-ID: <8523@wright.mips.COM>
Date: 19 Nov 88 20:46:01 GMT
References: <3386@pt.cs.cmu.edu> <74435@sun.uucp> <70@armada.UUCP> <550@m3.mfci.UUCP> <2152@ficc.uu.net> <552@m3.mfci.UUCP> <76500@sun.uucp> <10643@tekecs.TEK.COM>
Sender: earl@mips.COM
Organization: MIPS Computer Systems, Sunnyvale CA
Lines: 40
In-reply-to: andrew@frip.gwd.tek.com (Andrew Klossner)

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.
--