TKF15H posted on Jul 7 2006 at 10:04 AM said:
The gp2x runs a little over 10 times faster than the gba mhz to mhz, thats 10 instructions to one, with the video overhead I dont think you will make it.
The VBA emulator re-compiled for the GP2X runs at 10% speed (or so it says).
Static recompilers are famed of multiplying speed by 25. So even if I made a recompiler that could do only half of that, it should be enough to get 100%.
I'm using software SDL for now, with no overclocking.
The second processor is not being used.
GCC will be re-compiling the GBA's code, with optimization it may actually generate code with a ratio of less than 1:1 in some cases, if we're lucky.
With so much to do, I don't think getting 100% is going to be such an amazingly difficult task.
Right now I'm working on generating a database that stores information on each instruction in a ROM. Data is to be stored in the DB while the game is run (rather slowly

). A post-processor will get the database and generate a C file from it. GCC will then get the C file, make an object file which is then linked to VBA. Running the game again will be much faster as the interpretor will not be executed in the places that were run previously, and quite a few optimizations will have been made.
I got stung before translating Asteroids to the GBA, even with a 10 to 1 it was quite slow because the vector graphics took more horsepower than the 6502 translation itself. Sure, esp with Asteroids, shortcuts are easy in the vector graphics engine, but I gave up because the commercial version came out.
You brought up an interesting idea though, if push comes to shove the coprocessor could handle the tile video hardware emulation...
It would be VERY interesting to see what ARM instruction sequences when disassembled, translated to C and then back to ARM instructions looks like. Unfortunately every memory access has to be filtered at a high level, and every few instructions most likely accesses memory. Anyway, it is starting to sound like a very interesting project. I wonder if a machine code to machine code translation might be better/easier than machine code to C to machine code.
I have an arm disassembler that I wrote that you can have/use if you like, no guarantees on how accurate it is, I used it in parallel with arms and gccs disassemblers so hopefully I worked out the kinks. (www.dwelch.com/ipod). I am sure I have a thumb disassembler, but dont know where it is, shouldnt be hard to re-create. Having the smarts to know whether to disassemble in arm or thumb, that is the trick. I would probably build a trigger list by running the rom on a known-good emulator (that I had the source to). In the same way that you might build a branch destination table for disassembling on a variable length instruction set architecture (most CISC, some RISC). Fortunately for ARM you dont necessarily need a branch destination table, you still have to determine instructions from embedded data. There again you can use a trigger list or the easiest (but least-legal) thing is to just carry the rom image around with the application.
A static re-compile takes hand holding rather than a generic program that can re-compile any rom. So every rom translated is going to take effort (vs simple emulation where one solution fits many if not all). Now what would also be an interesting thing is that some developers write programs in modules, for example this bit of code handles the game, builds a virtual display memory, the every so often a function is called to copy the display data from ram to the video memory. where I am headed is programs written this way will have large sections of code that only deal with system memory and do not access peripherals every few instructions. These programs would be the easiest to translate, either just do an instruction to instruction translation for these sections, then emulate or translate in C the sections that deal with the peripherals. When performance drives accessing the peripherals more often (as the case may be on the GBA), you will end up spending a lot of time with emulation overhead (even in a translation as calling a generic write memory and read memory function to trap peripheral accesses and modify the address for system memory is no different than emulation).
I dont know enough about the gp2x yet, much less the mmu, I am thinking that "All you have to do" is simply run the GBA rom as is, and all of the gp2x work is in handling mmu faults. Basically map the gba system memory to gp2x memory, and set the mmu to fault on every other address, then the mmu fault handler takes the address determines what peripheral it is and goes from there. What is nice is that the vba source would have to do all of this already when emulating memory reads and writes, so it is a matter of borrowing the bulk of the code from an existing emulator and just gluing it all together. This would give you a one size fits all solution (most if not all roms would run without any rom specific hand holding required). All of the non i/o code would run 1:1, you would not have to deal with thumb vs arm (except in your handler front end of course). No disassembly...And here again you have two processors, one could handle the peripheral emulation to get a foothold on the overhead.
This development wiki is already, what, 35 pages deep with developer related topics. Where would I start looking to find out what the state of the machine is in when GamePark starts execution of your application, what can and cant you do with the machine? (well actually there had better be a way to take over control of the whole machine, even if the user has to power cycle or the application has to force a cold boot). How is SDL implemented, how much does it rely on the underlying linux os, or is it independent of the os talking directly to the hardware?
Sorry to ramble on so long...