Re: i386/m68k binary conversion

[Andrew Reilly <reilly%zeta.org.au@localhost>]

In a previous message, Dave Gilbert said:

> >>>>> "Jose" == Jose Alburquerque <jose%alexandria.net@localhost> writes:
> 
> Jose> Would it be possible to convert a binary program or library for
> Jose> NetBSD-i386 to m68k-NetBSD binary fomat with some sort of
> Jose> conversion program?  Just curious.
> 
> writing out this new executable.  Think about it another way.  If you
> had the source, then you could just recompile.  So you're really
> asking about compiling with your source language being an i386 binary
> and your destination being a m68k one.
> 
>       Again... your chief problem is optimization... since the
> trivial (dumb) translation is fairly feasible.  The only roadblock
> here is discerning what to translate.  Sicne code generators often put
> data in the code segment, another difficult job (more difficult than
> the emulators job) is to determine what is actually code).

I wonder how difficult this would really be, given that we're talking about
an environment that is _significantly_ better behaved than the dreaded PC
emulator, where all of the hardware has to be emulated and self-modifying,
hand written assembly code is commonplace.

The environment we have to deal with involves a well defined abstract
machine (the NetBSD kernel) that is pretty close to identical for both
platforms.  The vast bulk of the code is compiled.  Not only that, it's
compiled from C, and by the same compiler.  So presumably we know something
about the calling conventions and stack discipline.  Put that together with
a useful executable file format that has strict text/data segmentation and
perhaps some symbol table information, and I'd think that we could have a
pretty good go.

How about a disassembler followed by something to translate assembly
instructions into equivalent C statements (I know, I'm not sure how to
handle condition codes here...).  Then just feed it back into the compiler,
which should do an OK job of optimisation and register allocation...

Apart from the condition code handling, which would probably be
difficult, but could perhaps be managed by letting the compiler toss
heaps of dead code for condition evaluation that isn't used, another big
problem could be data alignment restrictions.  The i386 allows byte
allignment, and I'm pretty sure that the m68k forces 16-bit alignment,
and Sparcs and the like force 32 bit alignment.  Maybe our compiler
configuration makes this a non-issue already.

None of this should be construed as an indication that I'm volunteering
for the job...

In what appears to be a similar circumstance, I believe that DEC have
quite a good i386 to Alpha translator for the Windows NT environment. 
There you've got the same virtual machine, but perhaps not as well
controlled program segmentation, so it's perhaps a harder problem.

Anyway, interesting discussion.

-- 
Andrew

"The steady state of disks is full."
                                -- Ken Thompson