who wants to take up porting this n64 emulator to the pandora?

[skeezix]

Some folks do use ARM ASM in their projects; it is not rare, but perhaps uncommon.


jeff

 

[notaz]

As it has been said multiple times PSP has low level GPU access possible and that helps N64 emulation tremendously (and PSX too for that matter). Sony published that information to the licensed devs to get most out of the machine, and that information has been leaked to, or has been reverse engineered by homebrew people, so it can be used in projects like Daedalus.

So no "accidently" leaked full OMAP 3530 Hardware specs out there yet? And if so, would this really help to make better Software? I just mean, everything is leaked today...maybe if we are lucky... :rolleyes:

OMAP is documented well in the most part, but certain parts like SGX and video decoding blocks are almost not documented at all. However the leak is rather unlikely, since there are only few entities (ImgTec and perhaps TI) that have full documentation, while on PSP hundreds of devs have it, hence much more likely to leak.

How is actualy the ARM Assembler situation at the Moment on the Pandora? Do devs use it? Can they use it at all and would it make sense to use it? I don't hear much about on the general ARM OMAP front.

I think it still does make sense, but I'm not really aware of anything that is not emulator or part of the system and is using it.


Whatever came from GP2X and had ARM asm still has it since ARM is backwards compatible (PicoDrive, gpSP, mame4all), but there is tendency of removing it as porters are unable to fix bugs there (uae4all). Emulators with dynarecs have that by definition and as support routines (Mupen64plus, PCSX, gpSP). There is fair bit of asm in kernel itself.

 

[Exophase]

On the older ARM9 platforms it was pretty easy to get much better performance by writing ASM - the compiler was bad at a lot of things and ARM9 doesn't have a lot of scheduling caveats, so it was relatively easy to write ASM for it. Cortex-A8 is a lot harder to write efficient ASM for because you not only have to pair instructions but there are a lot of other new intricacies in the pipeline that can lead to dependency stalls and there are other artifacts of fetch/decode that can bite you where you don't expect it. The documentation by ARM is also not always complete or accurate - Ari64's writeup on the Pandora wiki has some surprising things in it.


So, if you don't put a good amount of time and energy into it you may not end up beating the compiler so easily.. but then again I don't know how good gcc is at scheduling for Cortex-A8.


Most programs using NEON will be written either with intrinsics or ASM. Intrinsics are only really one step away from inline ASM and usually are almost as unportable, and in this case don't perform as well as hand-written ASM. gcc is not good at auto-vectorization with ARM and as far as I'm aware lacks even an option to force NEON usage for floating point regardless of whether or not it can vectorize. So to get good floating point performance you have to write NEON code manually.


Unfortuantely NEON code is an utter nightmare to schedule.. if you're not good at it you can end up slower than the scalar version. This goes beyond knowing the TRM's timing, there are bottlenecks that are still not well understood.