PPSSPP for Windows Phone (8)?

[Dissonance]

IIRC historically it was used to accelerate Forth interpreters in the days before binary translation was developed or practical given the memory constraints. For a given number of emulated instructions the technique will use less memory than a dynarec because you are only caching function pointers rather than blocks of code. If you structure the interpreter to eliminate branches in the leaf functions as far as possible such that each possible instruction is a singular leaf function then you are seeing a considerable saving by skipping the decode (by having stored its previous result as a function pointer then calling it directly). I don't see "blowing the I-cache" as a certainty either, sure it's got some extra overhead from having to return to the top level fetch loop after each instruction but I think it will come down to how efficient your fetch code is and whether that will fit.

Regarding performance benefits my thinking was it would depend on the sophistication of the branch prediction and pipelining of the underlying hardware as to what the benefit would be for threaded interpretation vs a simple interpreter. While in comparison to dynarec it's going to depend on the cost of the call/return and call stack access and the aforementioned fetch routine.

As I said before, I'm mostly trying to dispell the myth that seems to be circulating that there is no method of accelerating a CPU emulation other than dynarec. Given that Windows Phone does have access to high end processors now (even if only in flagship devices). Then I don't see how long this attitude of "never going to happen" can persist at least for 5th gen emulation. I agree the commercial reward for the amount of work involved in porting a dynarec emulator to a threaded interpreter for Windows Phone's sake is near non-existent. The fact is that the technique apparently does yield performance benefits as demonstrated by EmiPSX. It's unfortunate that the developer hasn't been able to iron out more of the compatibility issues but I'd hope most emulator developers would understand the challenge involved and shouldn't be using this as an excuse for ignoring its achievements and their possible implications.

[Dissonance]

(10-25-2014 11:43 AM)Bigpet Wrote:  Well is there any actual benchmarks for this approach?

Yep.

M. Anton Ertl. and David Gregg. "The Structure and Performance of Efficient Interpreters". In Journal of Instruction-Level Parallelism 2003

Kevin Casey, David Gregg, and M. Anton Ertl. "Optimizing Indirect Branch Prediction Accuracy in Virtual Machine Interpreters". In ACM Transactions on Programming Languages and Systems 2007

I can't post clickable URLs for whatever reason. Just google the titles of those papers to get pdfs.

[Henrik]

"Threaded" (not to be confused with multithreaded) interpreters generally get you around 2x over a regular interpreter, while JITs get you 10x+. And it's a much smaller market and the only one with this problem (well, iOS too but that doesn't even allow emulators), but it's indeed pretty likely that at least some games would be fairly playable on fast Windows Phones, maybe even with the current interpreter.

Doing the DX11 port of the GPU emulation might probably be more work than getting the basics of such a CPU core running though..

[Trqrrhmn]

Sorry if this is off-topic, but does PPSSPP work on tablets running Windows 8 (not windows phone 8 or Windows RT)?

[Bigpet]

(10-29-2014 06:24 PM)Trqrrhmn Wrote:  Sorry if this is off-topic, but does PPSSPP work on tablets running Windows 8 (not windows phone 8 or Windows RT)?

Yes, there's nothing different to tablets running Win8 from laptops running Win8 (except for maybe multi-touch input but that got fixed a few months ago too).

[Dissonance]

There is also Windows 8 Metro apps running on x86 and Windows RT as well. These aren't quite as limited as a Windows Phone in terms of hardware. With Windows 10 aiming to converge these three platforms together under a single store and the steady increase in Windows Phone specs I'd say the case for ignoring these platforms is smaller than it used to be. Something for the PPSSPP team to consider for the future I suppose...

There does seem to be a lot of misinformation about the obstacles facing emulator development on Windows Phone. In my opinion these are being exacerbated by two factors; a) belief that JITs are the only means of accelerating an emulator and other aspects of the emulation don't factor (I sense this is coming mostly from people who know something of how emulators work but have never written one themselves). b) direct porting of emulators for 8 and 16-bit consoles from x86 to Windows Phone with no efforts made at optimization, resulting in users seeing performance issues which get blamed on the OS or phone hardware.

While I do think PSP would be on the optimistic end of WP8's current capabilities I see N64, PSX and Amiga emulation as firmly within its capabilities.

[iCEQB]

Hi all,

I just wanted to drop this here:

hxxp://channel9.msdn.com/Events/Build/2015/C9-04 (sorry can't post links)

at around 17:40 the guy tells the interviewer that JIT is coing for Universal Windows Apps (which is the one binary - all Win 10 devices concept).
So this means JIT is coming to Windows 10 Mobile (and every other device that runs Win 10, like the XBOX One).

I dunno if the major devs here took a look at the UWP API and how easy / difficult it would be to port PPSSPP over, but at least M$ heard the feedback (I guess?).

[Bigpet]

(05-15-2015 08:44 PM)iCEQB Wrote:  So this means JIT is coming to Windows 10 Mobile (and every other device that runs Win 10, like the XBOX One).

I was about to type my ".Net JIT is not the same as the ability to write a JIT" diatribe again.

But you're actually right, they did say in that video that you can now use VirtualAlloc and VirtualProtect to create memory that you can write to and then execute in Windows Store Apps.

Edit: but he does not actually mention Windows 10 Mobile, merely win32 apps for the store which aren't available on mobile as far as I know

[iCEQB]

Oh damn you are right :/

Coding for Windows is pretty fragmented man, all of this Win32, UWP, .NET, etc. shiz .... what's up with all that?
Why isn't one way to code stuff enough ?

I also somehow blame the presence of ARM for this Universal Windows Apps thing, if Intel would dominate the smartphone market, we might have Win32 apps running on Mobile right now