 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
 |
 |
 |
|
|
|
|||
|
| Short description |
| 68k -> PPC reassembler |
| Proposed name |
| surpass |
| Full description |
| The PPC and m68k family aren't WILDLY different... Sure, there ARE differences, but they're not as "different" as, say, 68k and Intel. The PPC apparently even has a set of instructions that are supposed to help it with m68k emulation! It ought to not be HORRIBLY difficult to take a 68k executable, break apart the hunks, disassemble the code hunks, map instructions to equivalent PPC instructions, probably perform some fairly standard optimisation stuff (although early betas could leave this out), re-assemble the PPC code, bundle the data hunks back together with the new code hunks, and produce a PPC (elf?) executable out of it. EFFECTIVELY doing the same sort of job as a java just-in-time compiler, except instead of taking java byterun code, which is relatively alien, it's taking m68k code, which is not so horribly different, and instead of calling stuff in standard java classes, you're making standard Amiga library calls - IE nothing quite so difficult there either. ... which leads me to the next stage of the project - repeat as above with some of the Amiga libraries too - a different set of hunk structures to rip apart, but reassemble the code in Amiga m68k libraries into PowerUp PPC libraries too. I understand that anything that hits the hardware is a big no-no, but there's quite a few obvious candidates - lots of compression and image-manipulation libraries spring to mind. ... repeat as above for datatypes, etc etc. Once we've got the main reassembler done, it ought to be fairly easy to write frontends that'll break up such-and-such a 68k code format, reassemble the code sections, and bundle it back up into such-and-such a PPC equivalent. ... hell, why spend ages re-writing AmigaDOS for the PPC when you could get the machine to do it for you? OK, so maybe I'm going a bit far there! :-) I'm not going to pretend it would be easy. It's a similar level of complexity to an emulator, except we're only talking about emulating an Amiga on a slightly different Amiga, which ought to be a lot easier than most OTHER emulators... It's also not strictly EMULATING, it's translating, but the technology is similar. |
| Development history |
| Empty |
| Comments |
|
On this topic, it occurs to me that it should be fairly trivial to write a program to translate code between various members of the MC680x0 family, eg. translating from 68000 code to 68060. Perhaps optimizations could be done at the same time. The translated code would likely be more stable for higher-end 680x0 processors, and somewhat faster. Also possible, if optimizations are implemented, should be a straight optimize of the binary, without necessary translating to another processor. I can, however, see some problems with self-modifying or extremely tricky code...another reason not to write self-modifying code. 06/04/2000 James R. Jacobs Do you know the FX32! software from Digital for their ALPHA processor? It´s genious! Running under WindowsNT4 there´s the problem, that there are too less native programs. So you can install the x86 code via the FX32! emulator. It creates a database an the harddisk for every non-native program. After quiting the x86 proggy, FX32! starts to work: It translates and optimizes the code for the ALPHA! So on a DEC PW500 with ALPHA 21164/500 MHz I was able to run Intel version of Photoshop nearly at the same speed as on a PPro/200 MHz. Visit their homepage http://www.digital.com/amt/fx32/index.html 26/02/1999 Robert Niessner Another potential problem found... CODE hunks don't have to contain only code! :-) This means we/I will have to be fairly careful about only translating real code in the CODE hunks. Shouldn't be too hard - just start at the beginning and work down following each path that the PC could ever take - IE where there are any branches, continue converting where we are, but make a note to also translate the stuff at the other end of the jump. Continue until all bits of code that could ever be executed have been translated, and anything else must be data - either that, or it's dead code! I'm currently working on the de-hunking part of the program, by the way, and would definitely appreciate any help anyone can offer with the next few stages - dissassembly (not nesescarily to ASCII by the way) and translating the dissassembled 68k code into PPC assembly. 10/09/1998 Nick Waterman I've marked this idea as "under development" by myself. I'm the same person who posted the idea, and so far I'm the only person to have made any comments. I HAVE marked it as "Under Development", but I WOULD appreciate any help and relevent skills that anyone can offer me, because my main skills are in C, and I do know a bit of m68k assembly, but not a huge ammount, and I've only just started learning PPC assembly, and the relevent OS internals that I'm going to need. BASICALLY, I'll write this damned thing myself if I have to, but if I DO do it all myself, I'm going to have to teach myself a lot of the relevent skills. If anyone else has experience with porting 68k to PPC stuff, disassembling amiga executables and libraries, assembling PPC stuff, (PPC) optimisation techniques, etc etc etc, please offer your help! 07/09/1998 Nick Waterman OK, I've looked at this in more detail. It looks like it's THEORETICALLY dead easy to take m68k assembly and map it to equivalent PPC instructions. See "PPCtut.guide" on Aminet. It sounds like the MAIN problem is going to be that context-switching between PPC and m68k and back again is quite expensive, so if we re-assemble an m68k program onto the PPC, it THEORETICALLY ought to be a lot faster, but in practice, if the re-assembled code still needs to call a lot of m68k libraries and things quite frequently, the re-assembled code will often run a lot SLOWER than the raw m68k code! Obviously this is less of a problem if you also translate the m68k libraries into PPC ones, but, particularly where the library hits the hardware, this isn't always possible. Therefore, the most difficult part of this re-assembler is probably likely to be an algorythm that looks at the code and "guesses" whether each section is likely to be worth translating or not, based on how many PPC-m68k context-switches are "likely to be" required. The only TRULY reliable way to work this out is to run the code and profile it, which is unlikely to be an option! 07/09/1998 Nick Waterman |