Sure you can. In fact, the FPGA would only swap certain instructions where this is required.
The swap is only required because the byte order is backwards (Endian issue). So, if you fetch a long word from memory using something like mov.l $12345678,d0 that memory location will appear backwards to an x86 and would have to be swapped. The swap occurs during the opcode emulation, and using some hardware means to perform the swap (like the bus wired backwards momentarily) would eliminate having to do it in software.
The problem with JIT is that it is not cycle exact, so it breaks a LOT of programs. This is where the FPGA would come in handy as it could be used to throttle the instruction cycle speed so it is correct for a given desired performance level.
Maybe I'm considering a different path, but with an emulated CPU, you'll still be byte swapping for every local memory (non-Amiga bus) read and write.
Not taking advantage of inexpensive memory that's local to the real CPU would cut down performance dramatically so I assume you'd want this.
Given the comparatively slow Amiga bus, wouldn't swapping only on the local accesses and letting an FPGA byte swap Amiga accesses introduce unnecessary checks in the code and extra complexity in the FPGA?
It would seem to me that using the same macro, etc. to swap accesses throughout the JIT would keep the code cleaner and be less likely to introduce careless errors. It just seems like premature optimization.
And I'm not sure cycle exact is really a problem except for badly written software that would already have broken under 020 and 030.
