Subject: Re: i386/m68k binary conversion
To: None <current-users@NetBSD.ORG>
From: Mathew Hendry <scampi@dial.pipex.com>
List: current-users
Date: 10/22/1996 23:23:09
On Tue, 22 Oct 1996 09:38:19 -0700,
"Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net> wro=
te
about Re: i386/m68k binary conversion:
:=20
: >> Really, the only part you need to write is a front end for gcc that=

: >> can turn assembly code for a given processor (i386 in this case) in=
to
: >> gcc's RTL; think of it as the back end in reverse.  Just a SMOP. =3D=
:-O
: >> The full chain would look something like:
: >> objdump | <asm parser for A> | gcc backend for B | as | ld
:=20
: >Well, there's a problem: text segments often contain things other tha=
n
: >executable instructions.  Common examples are string literals and jum=
p
: >tables.  Even =5Fidentifying=5F such things can be hard, never mind
: >correctly mapping them.  (I speak from experience here, having done
: >disassembly and uncompilation for VAX, SPARC, and 68k code in the pas=
t.
: >If a =5Fhuman=5F has trouble, it will border on impossible for a =5Fp=
rogram=5F
: >to have a prayer.)
:=20
: Yet, DEC seems to have done it quite successfully, with their MIPS ->
: Alpha converter, and their new x86 -> Alpha converter (for NT). In my =
                              : experience, the MIPS/DECstation -> Alpha converter worked very well
: (never used the other one).  How is that they were able to be so
: successful with binary conversion?

The x86 -> Alpha "converter" (whose name I forget) is not a true [static=
]
translator; it is an emulator which keeps a running cache of translated
instructions. This cache is dumped back into the executable every so oft=
en -
presumably after a suitable amount of x86 code has been translated. So, =
as
more of the original code is executed under user direction, more is
translated, cached, and saved, and performance steadily improves.

By assuming that =5Feverything=5F is data until proved otherwise by atte=
mpted
execution, this approach neatly avoids having to explicitly distinguish
between code and data before runtime, a problem which is impossible in t=
he
general case.

Does the MIPS -> Alpha converter work in a similar way? Perhaps the MIPS=
 and
Alpha are similar enough in operation that a static translation approach=
 would
be more workable...

-- Mat.