User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

26 bit questions.

Thu Oct 10, 2013 9:24 pm

Ok obviously there are many ways to run 26-bit programs on a 32-bit only RISC OS.

The question that I have is.
Beings that there seems to be no issue with using a JIT based emulation layer to run 26-bit addressing applications:
Is there any leagle issue with saving the code that has already been translated by a JIT emulation to a on disk file, in order to speed up future usage?

I am speaking of oing this only as the program is run and only on the installation on which it is running.

Or does this potentialy break the do not modify terms of many licenses?


If there are no issues with this kind of thing it could make for an interesting future for many of the freely distributed closed source educational programs for RISC OS that are not 32 bit addressing compatabile. Not to mention games.

I do not think that anyone realy likes the extra delay of translating (while it is only a few of micro seconds at a time it does have an impact on the user experience [there is no way to be non subjective with that statement, just have to ask people for there subjictive views]).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: 26 bit questions.

Thu Oct 10, 2013 10:42 pm

DavidS wrote:Ok obviously there are many ways to run 26-bit programs on a 32-bit only RISC OS.

The question that I have is.
Beings that there seems to be no issue with using a JIT based emulation layer to run 26-bit addressing applications:
Is there any legal issue with saving the code that has already been translated by a JIT emulation to a on disk file, in order to speed up future usage?
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.
DavidS wrote: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 :D .

DavidS wrote:If there are no issues with this kind of thing it could make for an interesting future for many of the freely distributed closed source educational programs for RISC OS that are not 32 bit addressing compatabile. Not to mention games.
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.

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).
DavidS wrote:I do not think that anyone realy likes the extra delay of translating (while it is only a few of micro seconds at a time it does have an impact on the user experience [there is no way to be non subjective with that statement, just have to ask people for there subjictive views]).
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...). 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".

While your suggestion is an interesting idea I suspect, sadly, that many old programs simply can't be run be effectively at the moment - as later/faster ARM processors arrive that might (just) become feasible though.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: 26 bit questions.

Fri Oct 11, 2013 12:09 am

AMcS wrote: 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.
DavidS wrote: 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 :D .
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.

ALSO: 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.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: 26 bit questions.

Fri Oct 11, 2013 2:25 am

DavidS wrote: Thank you for your feedback.
No problem David, I am happy to help, please let us know how you get on with your deliberations.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: 26 bit questions.

Sat Oct 12, 2013 1:43 am

Ok I have decided to go and use disk caching of the translation, and include a disclamer about the use of third party software, and the unknow status of licensing issues. I think that that should provide me with a good CYA setup.

If any one could provide any further suggestions on the CYA issue, it would be apreciated.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “RISCOS”