NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/7007

Text File | 1996-08-05 | 6.9 KB | 138 lines

Path: news.mountain.net!usenet
From: [e-mail] (Gene Heskett)
Newsgroups: comp.sys.amiga.programmer
Subject: PPC conversions
Date: 07 Apr 96 15:34:42 +0500
Organization: MountainNet, Inc. Morgantown WV 800.444.1458
Message-ID: <[e-mail]>
NNTP-Posting-Host: slip4.mpl.com
X-Newsreader: THOR 2.22 (Amiga;TCP/IP)

Hello Olaf, and ALL;

From time to time I read (in this group) that converting the Motorola
object code to PPC object code would be impossible to do, and the
quotation usually involves the difficulty of the calculation of a
jump address when the jump is taken.

I dissagree, and I'm going to "waste some bandwidth" as they say:

While I am not the one to do it as I know relatively little about 68k
code, and virtually nothing abpout PPC code, I do know a bit about
object codes in general.  I came in on the cpu scene with the RCA
1802, which IMO is the *first* RISC chip, and wrote a program for it
using nothing but the monitor rom in a Super Elf and the programmers
manual that listed the nemonic and the hex as a crossref.  AFAIK that
program is still in use today, on a several times a day basis.  I
also have about that same level of experience on the Z-80, and now
many years of coding for the 6x09 cpu's running various dialects of
OS-9 and NitrOS-9.

I for one do not believe that such a translator/interpretor program
is anywhere near as impossible as you state.  While my general
overview of such a program is admittedly hazy at best, I don't see
the location of a jump to take as anything but an exercise in record
keeping by the interpretor program.

This "interpretor" should only need be run once for each program that
needs to be converted as it should not only perform an emulator
function, but should also keep track of the code it uses to allow the
emulation to be done, storeing that emulation as the file to be run
the next time the program being converted is executed.

I don't see this first time run as a very speedy operation, and it
will probably need to *heavily* exercise a virtual memory manager and
a few files on a gigabyte sized hard drive.

The jump/branch address problem? IMHO, simple. In the process of the
translation, you know the address's first component already from the
auto increment of the interpretors instruction pointer. If the
interpretor kept a table of the next addresses after any RTS or RTI
instructions, the hit rate of finding the calculated address to be
one of those would be several percent right there. If a miss, then
use the two addresses stored on each side of the target as the start
and finish for a scan/re-interpret until the source pgm counter is
matched.  Use that address as the pointer into a table to get the new
address, calculate that emulation address by its actual position in
the emulation, and store the new address data into the emulation
file.

Or, imagine it this way.  Everytime the interpretor fetches a new
instruction from the file being translated, the offset address its
fetched from is stored in a table thats going to be 4x the size of
the source cause every source byte needs a 4 byte address stored.
Then when the interpretor has this instruction figured out, and knows
where in the output file this translated code will live, this
"translated" address is stored in the next 4 byte location.  This
method would allow, once the code has been emulated *once before* the
interpretor to simply use the old jump address as an entry address
into the table, check the old address for a good match, and load the
next long word above it as the output address to be written to the
PPC object file.  If there is not a valid entry because the code
hasn't been translated once before, then yet another table should
have an entry made indicating that here is an address that needs
resolution yet.  This table should be updated each time a new address
question is resolved.

The data vs executable problem is handled the same way, and could
even function as a method to remove code thats there, but which never
execs because if its never accessed, then it shouldn't be there in
the first place.  The ONLY exception to that rule would be the $VER
string, which should be copied but modified to indicate its now PPC
code.

The data storage requirement while its doing the
emulation/translation/interpreting the first time is why I mentioned
the virtual memory option. A 528k rom image could need a 2 pointer
table entry for every byte in it. Not bloody likely of course, but
possibly.  With the other tables needed to save stuff ala a linkage
file, several megabytes might be needed *this one time*, but the end
result should be a similarly sized file thats directly executable by
the PPC.

The one problem I see with that would be the diffs in hardware
addresses for device drivers. However, that only ups the complexity
of the translators tables by one more lookup table, which given
enough virtual memory and time, are solvable by the same general
match and substitute when match found, maybe 6 lines of C for that.

Maybe I don't know what the heck I'm talking about, and as a 68k/PPC
coder, I'd be a miserable failure.  But, I've been around long enough
to have seen the farmer plant a few seeds.  My green thumb long ago
got arthritic and has turned black and blue on more than one
occasion, but thats what this tome is, the seeding of the fertile,
much younger and hopefuly more agile than mine, minds I know are out
here reading these newgroup carryings on.  Some of you waste a lot of
bandwidth on arguments that are A: Old long before Grace Hopper
found her first computer "bug", and B: Boring as hell to the rest of
us actually looking for *usefull* information.

So I say, not just to Olaf B., and AT et all, but to ALL, quit
mewling about it and do it!  If I, with an 8th grade education, can
claim to have worked on some of the hardware that put John Glenn in
orbit, to have worked on the construction of tv cameras that brought
back the *first* pictures of blind fish from the bottom of the
Marianas Trench, and I can truthfully claim just that, then I know
very well there is somebody out there who can get this picky little
job done, all you have to do is "get to it".

If, by the time such a translator has been written, I have managed to
upgrade my machine to such a cpu, then here is my promise of a $50.00
USD shareware fee for a copy of said program, payable to the author
of first one that actually works.

Not some "won't save" crippleware demo, but a real, working, I can
run its output on my PPC, working version.  So get to it, I file for
social security and won't be able to afford it by 2001, or before if
my health doesn't hold.  Right now its touch and go, I ate too much
Easter dinner!

Cheers to Olaf, and to ALL!

/*            Gene Heskett          |  I need help, please see my adv. */
/*  CE @ WDTV Weston/Clarksburg WV  |  in the newsgroup 'alt.tv.jobs'  */
/*  <[e-mail]>   |  We are an equal opportunity and */
#include <std.disclaimer>           |  all that stuff employer.