Improve Execution Engine ( JIT ) perfomance and x86 chip

[zminhquanz]

Some game is slow because this problem above

[fervi]

@zminhquanz
I asked a colleague and try to fix problems with nds4droid (in summer). Although cool if jquesnelle fix problems with nds4droid.

[zminhquanz]

and improve UI , UX similarly PPSSPP

[fervi]

@zminhquanz
UI in my opinion is not important as quick work emulator. Unfortunately, I do not know whether it is possible to create a fast emulator based DeSmuMe because DeSmuMe even on fast computers can work too slowly.

[zminhquanz]

One Question to you , in the future can you add emulate bios and Firmware Nintendo DS on this emulator , similarly DeSmuMe

[M1cha]

well a properly implemented NDS emulator for Android should be way faster than any nds emulator for desktop's because both Android and NDS use ARM CPU's the problem probably is that DeSmuME was designed with a different approach so they do full CPU emulation instead of translating the code to something executable on phones.

[tangalbert919]

DeSmuME has to emulate the ARM CPU, since the whole program is running on the i686 or AMD64 architecture.
At this point, DeSmuME can run fast on most devices. We can get more performance out of Lightning JIT if we just updated it to 2.1.0. The one we use right now is 1.2, and that was released over 10 years ago.
Why we have ArmCJit, I don't really know. The same goes for TinyCC.

[tangalbert919]

Only Android devices with a x86 chip can benefit from an updated core immediately because of AsmJIT.
The rest use an ARM chip (it could be the 32-bit ARMv7-A or the 64-bit ARMv8-A chip), which means we need to use Lightning JIT for that. AsmJIT does not have an ARM backend publicly available yet.
Also, how fast the emulator will be depends primarily on the game you have selected to play. We cannot guarantee that every game will run smoothly and at exactly 60 FPS the whole time.

[NotTsunami]

@jquesnelle Can you expand on the existence of TinyCC? To my understanding, it replaces GCC in the case of any non-neon ARMv7 devices. TinyCC does have the tradeoff of a lower filesize, but wouldn't the tradeoff between performance and filesize vastly invalidate the usage of TinyCC in favor of GCC? We could reduce the binaries by one by dropping ARMv6 support as Google themselves dropped ARMv6 before ICS (as I have done in my fork). Also, I don't think AsmJIT is being used at all anymore either, is this correct or am I missing an indirect reference?

[tangalbert919]

AsmJIT can only be used on the x86 platform, and arm_jit.cpp uses the asmjit namespace. That's why it's in the code.
Here's what I don't understand: Why use Lightning JIT and not AsmJIT for the x86 binary?

[tangalbert919]

ARM64 support has been added to my fork, and the NEON binary will now compile using VFPv4 and NEON with 32 double precision registers, and the performance tuned for CPUs with Cortex-A7 and Cortex-A15 inside.
Only devices that support VFPv4 can use this NEON binary, as improved CPU feature checks will be in place. Devices that can only handle VFPv3 or lower will use the old binary instead.
ARM64 will have its own optimizations for better performance.

[NotTsunami]

VFPv4 change is likely negligible, not worth an extra binary, hence why in my v2 fork I've actually reduced the binaries by one and not readded the A15 one.

[tangalbert919]

I didn't add an extra binary. I modified the existing NEON binary makefile to increase performance for devices using the Cortex-A7, Cortex-A15, or both. Before, GCC would optimize the code for Cortex-A9 (and NEON support was optional for that core).
I might undo the whole "VFPv4" thing because some people might still be using a device with a Cortex-A8 or A9.

[tangalbert919]

ARMv8-A support is complete, with all errors fixed. This can all be found in my v47-1 branch, and will be merged to v48 later.

[tangalbert919]

Those that want to help contribute to version 48, fork my fork. I cannot do this alone, and @jquesnelle is still silent.

[zminhquanz]

@tangalbert919 It still too long for release a new version , does @jquesnelle forget this project