Closed fuzun closed 7 years ago
I reopened this because there is no reason for supporting this.
armeabi-v7a-hard is not a real ABI. No devices are built with this. Hard float code generation is already used in the armeabi-v7a ABI. The “hard float” variant only changes the function call ABI. That is, the floating point registers are used to pass floating point arguments rather than the integer registers.
Even if it does not support (for now) compiling on newer NDKs, there is no sense to use this method according to Google.
It is aapcs_vfp calling conversion. All mods now using this on armv7. Softfp engine cannot load mods with aapcs conversion. And it works faster than softfp. Xash3D now suports mods that built in 2015 BTW, new ndks desided to use clang instead of gcc. Porting mods to clang is hard procedure as it cannot get method pointers without classnames (e.g gcc allows use &DefaultTouch with -fpermissive, but clang does not allow it all, requring &CMyEntity::DefaultTouch. Dou you want to fix hundreds of such usages)? Impossibility to build with new ndk is really problem that we need to fix and it may be solved by using own libm_hard library. I've tried to do it with armv6 and it worked correctly.
I do not know about aapcs conversion but if newer ndks only need "&CMyEntity::DefaultTouch", it would take time like hlsdk-xash3d but it will be better.
Also, theoretically, newer ndks must have more performance. I did not test anything yet but I think staying at old ndks is not a good thing. Whether or not it makes some compatibility issues. (Maybe make a legacy version of xash and continue with new ndks ?)
Clang/LLVM can't into performance. xD
I am thought about switching to Crystax NDK, as they provise GCC6.
18 сент. 2016 г. 2:56 PM пользователь "fuzun" notifications@github.com написал:
I do not know about aapcs conversion but if newer ndks only need "&CMyEntity::DefaultTouch", it would take time like hlsdk-xash3d but it will be better.
Also, theoretically, newer ndks must have more performance. I did not test anything yet but I think staying at old ndks is not a good thing. Whether or not it makes some compatibility issues. (Maybe make a legacy version of xash and continue with new ndks ?)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/175#issuecomment-247843534, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgW8linaWcYaqaIXHAwYKyyCTycFwks5qrSb_gaJpZM4Juywz .
Haha so this switch looks like another google bullshit. Why google hate native development so much...
I have looked Crystax NDK and it looks promising. Better give it a chance.
So, close issue?
Actually, it's not bullshit. Clang/LLVM codebase is more simple, than GCC's.
2016-09-18 15:19 GMT+03:00 fuzun notifications@github.com:
Haha so this switch looks like another google bullshit. Why google hate native development so much...
I have looked Crystax NDK and it looks promising. Better give it a chance.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/175#issuecomment-247844462, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgY_ibHW-pUCQZ90PKHpwWMF1m1Wfks5qrSxBgaJpZM4Juywz .
Changed title as dropping hardfp is not good idea. It is better to make it work with gcc's from last ndk (manually adding hardfp build) as fallback and switch main development to other ndk implementation
Haha so this switch looks like another google bullshit. Why google hate native development so much...
It's better then gcc 4.x any way. https://www.phoronix.com/scan.php?page=article&item=gcc-61-clang39&num=1
On x86 maybe, not on arm
ndk 12b state:
The ndk-build command defaults to using Clang in r13. We will remove GCC in a subsequent release.
Can I use 12b or 12a(This allows hardfp) because they still support gcc according to statement?
Is there any particular reason why xash3d android uses 10e ?
The NDK will neither be upgrading to 5.x, nor accept non-critical backports.
R11. No serious changes for GCC, so release builds uses 10e. Any developer can use it's own NDK, ofc. :) Switching to new NDK require deep testing.
https://android.googlesource.com/platform/ndk/+/ndk-r12-release/docs/HardFloatAbi.md