Re: i386/m68k binary conversion

[Jose Alburquerque <jose%alexandria.net@localhost>]

Thank you all for the input.  I guess my curiousity got the better of me.
The main reason I asked about binary conversion is that I was trying to
compile LyX (a LaTeX frontend) for my NetBSD-Amiga.  I needed Xforms (a
GUI Library), but it was only available in binary format for certain
platforms, among which was NetBSD/i386.  I thought that a conversion was
possible.

Fortunately for me I've discovered that Xforms is now available for
NetBSD-Amiga.  I've downloaded and compiled LyX and it seems to work
nicely.  The only problem is that scrolling down in the window seems to
"spill out" off the top into the background of my desktop and scrolling
upwards brings the stuff back, but leaves traces behind. The documentation
mentions that LyX requires libXpm-4.7 (aka libXpm-3.4g), which I have
installed, and unknowingly I compiled using the old libXpm-4.6 include
file "X11/xpm.h".  I'm not sure this is the problem, but I have installed
libXpm-4.7 again and will try again.  I will try keep everyone posted.

However, I still think that the conversion is a worthwhile project in
which I would invest time if I were more knowledgeable.  Thank you all
again.

-Jose

  * * * *     +<><><><><><><><><><><><><><><><><><><><><><><><><><><><><>+
 *        *   |                   Jose A. Alburquerque                   |
*  O    O  *  |                     jose%smartec.com@localhost                  
   |
*    ()    *  |             csjaa%csfaculty.engr.ccny.cuny.edu@localhost        
   |
*  \----/  *  |                                                          |
 *        *   |         "In God we trust" - From face of US penny        |
  * * * *     +<><><><><><><><><><><><><><><><><><><><><><><><><><><><><>+


On Wed, 9 Oct 1996, Andrew Reilly wrote:

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