Not being a lawyer I can't say, but on other platforms (such as Windows) .NET executables can be "compiled" to something other than IL code to a native format by a program called NGEN. Granted it's not an exact analogy but it does show a conversion from one form (relying on a runtime) and converting that to something else that is native.
I am speaking of doing this only as the program is run and only on the installation on which it is running.
Or does this potentially break the do not modify terms of many licenses?
If the license prohibits "disassembly" or "reverse engineering" possibly - but again to run a JITter means it's doing it (at some level) anyway - it's just that you're not collecting the evidence on the hard disk
Yeah this is what confuses me. There has never been any complaint about JIT that I know of, though yet I have no way of knowing if caching the translated code to disk for future use would cause a problem.
The 26bit versus 32bit issue is (relatively) simple to solve - there are static code analysers - such as David Ruck's excellent !Armalyser - that has allowed code to be "fixed" for 32bit running. Fixing 26bit code regarding flags not being part of the PC (R15) is doable - but a bit of a pain in the head (even with !Armalyser). The real issue is that old games - particularly ones that "assume" old style hardware (or directly address it as Games are likely to do) throw up much more thorny issues.
Interesting of you to mention as that is part of the issue that I am attempting to solve. That is direct access to the HW registors on older systems.
Though that is not directly to the issue at hand.
Also self modifying code would be another pain in the head (simply saving code once to disk won't fix that case) as the JITter would be required to recompile it again for the changes - and yes I do know self modifying code is bad but early ARM's didn't have cache (and didn't have Harvard Architecture) so this although being a "pig ugly" approach didn't break things... but with anything of StrongARM era or later you're going to be (IMHO) in a world of pain - and the JITter will still need to sit there "just in case" to "recompile" (if that's the right word) code that would be re-written as the game ran. You'll also take a hit because the instruction cache may need some lines flushed (though that would happen whether the game was on disk or precompiled on disk in either event).
Yes unfortunately there will be the need to recompile anything that gets modified. That is the one area that there will be a small slow down
Though it is also possible that not all of the original has not yet been translated, due to a portion of code not having being called (using a lazy translation JIT to improve the performance a bit).
Though I guess that the stuff that is old enough to use self modifying code is also expecting a quite slow system so that case the extra time taken by JIT should be less noticable.
Using a lazy translation JIT makes it a little less noticable. Still some issues as stated.
One issue that I have not figured out how to compensate for is that of code that uses timing loops expecting much slower HW will likely run way to fast on the RPi. This is one issue that I think would require the presence of a soft CPU emulation to deal with.
I suspect much of the performance is sapped by the emulator having to "present" an A310 like hardware set up on a (nearly) completely alien RaspberryPi (no friendly IOMD or VIDC2 in sight...).
Yes I have.
The big advantage with JIT are all of the WIMP based apps that folow the rules.
Though I have been looking to how I could play with the page mappings, and page fault handling to improve the situation at least a little bit.
You'd also probably find that as system calls or calls requiring fiddling with flags (where the 26/32 bit issue raises it's head) are fair less frequent than games trying to manipulate Video RAM or change VIDC registers that would need to be "caught".
With games this is true. The big area of advantage for JIT is the well behaved stuff.
Thank you for your feedback.