PCSX2 meets clang

[Urisma]

I'd like to move all of the inline assembly into separate .S files (and in the case of small assembly functions just replace with C++ if possible). I'll have to think about how to organize all of the .S files. I'd like to do it in a cross platform way (in case PCSX2 ever gets ported to a different architecture). As far as reimplementing the standard library goes, I don't have a problem with it as long as it's transparent to the programmer. Since clang doesn't like the assembly syntax it's not huge on my todo list, but I'd like to use generic standard library calls that can either use the standard implementation for development purposes or PCSX2 implementations for release builds, where it can choose what method to call via some defines or a small wrapper.

I posted about having someone do optimization flags cleanup in the development ideas thread here, so I'm hoping someone takes me up on my offer. I wish I had more time to work on this. Having a full time job really cuts in to my free time

[gregory]

Ok. The small asm part (less than 10 lines) could probably be easily ported to the not-intel syntax. Or maybe it could use intrinsics.

[gregory]

Does your clang build start? On my side I got strange crash related on the libspu2x plugins.

[Urisma]

It usually does. I've noticed some oddities clang built plugins, most notably some .so errors. Sometimes I'll get something like

Code:

undefined reference: someFunctionNameThatHasBeenMangledByC++ButLooksLikeAnExport. spu2-x.so is not a valid plugin file

I'm guessing that clang is silently changing some method signatures that are DLL exports which is breaking the plugin at load time. I've also noticed that it's much easier to avoid those weird crashes by using the portable.ini option and having it do te first time wizard thingy.

[gregory]

Always spu2x ?