Re: Machine language and assembler translators?

I have built translators like this for machine/assembly language, with
mixed results. Yes, it can be done. But it won't be efficient code.


At the most primitive level, you can look at each instruction of the
"source" processor, and see how best to make the CPU do _EXACTLY_ the
same thing in the "target" processor. Once you have a translation of
each instruction, it's a simple matter to write a text processor that
will make the necessary substitutions. I've even been known to do it in
the macro language of a good editor.


As both John and Vit point out, your results will depend a lot on the
similarity between the two processors. Translating, say, the assembly
language of one RISC machine to another one is a piece of cake, and
gives good results. Translating between families is a lot harder.


Our first translator, back in the 8-bit days, involved translating 8080
assembly language to 6800. That's probably the worst-case scenario for
two reasons. First, the 6800 had fewer registers, so we had to implement
registers equivalent to the 8080 registers, in RAM. Second, the Intel
and Motorola lines had (still do) very different rules for the way the
flags work. In the Intel line, flags are "sticky," and often remain
unchanged by certain operations. In the Moto line, flags always reflect
the contents of the "accumulator" (or register last used).


Since our translator operated only on one instruction at a time, we had
to take the worst-case assumption, that every flag had to be treated
just as it would have been in the source processor. This is clearly a
pessimistic assumption, and led to much of the inefficiency. The
translated program ran, and generated correct results out of the gate.
But the size of the translated code was about double that of the
original source, and speed was about one third.


If you had a _REALLY_ good back-end optimizer -- one that could tell if
a given flag was going to be needed or not -- you might get a lot of the
performance back.


Others have suggested an emulator instead of a translator. That
definitely works too, and would of course not cause a bloat in code size.


Looked at at the most fundamental level, you can imagine each
translation as a macro substitution. A translator substitutes each
macro in line. An emulator basically has a subroutine for each macro,
and uses a jump table to select and execute it. The macros are
essentially the same either way.


One last thought: Since I assume that, nowadays, you are writing the
code in a high-order language like C, and assuming that you have a feel
for what constructs are generated for various kinds of instructions, you
might be able to anticipate things like flag usage much better. That is
to say, an if-statement or for-statement is going to do its predicate
tests in a very specific way. If you know what that way is, you can use
it to create an equivalent construct for the target machine.


Unfortunately, this approach is coming very close to being a decompiler,
which is a whole 'nuther problem. Not impossible, but not easy either.


Jack


Jatin Bhateja, Noida wrote:


> Hi Sir
>
> My question is that are there any tools available which converts the
> machine language of one architecture to other architecture. For
> example if we have a got a complier for language say X and the target
> language of compiler is say for ARM. Now are there any tools available
> which convert or translate the code generated for ARM to some other
> architecture say SH. ...

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