On the contrary, the BOINC platform is the typical method of specifying the ABI when there are multiple potentially incompatible ABIs (i.e. i686-linux vs x86_64-linux). I'm not suggesting separate platforms for NEON or different FPUs, I'm suggesting different platforms for the two android ABIs that could be present, to prevent sending a v7a ABI app to a pre-v7a ABI machine.
And if you're sending to android on ARMv6 with VFP or NEON, it seems to me that you are doing something that the NDK says is not supported by either ABI. I guess it will probably work because any device with a VFP or NEON will have a linux kernel that supports it. So that kind of breaks the SETI@home model, which is to send a single application that supports multiple instruction sets and determines which routines to call at run time. On Tue, Jul 23, 2013 at 12:38 PM, Heinz-Bernd Eggenstein <[email protected]> wrote: > Hi > > Von meinem iPad gesendet > > Am 23.07.2013 um 17:58 schrieb Eric J Korpela <[email protected]>: > >> The way to communicate the ABI of the host OS is the platform string. > > Unfortunately there seems to be only one platform string > "arm-android-linux-gnu" for ARM android regardless of the ABI. Are the > projects all serving only the pre-v7a (no-FPU code in the app) ABI? Or are > they letting v7a apps crash on pre-v7a machines? > > As for Einstein@Home, we check the FPU capabilities in the CPU features > communicated by the client, and then provide one of two possible app > versions, one for VFP and one for NEON, each compiled with ABI flag > "softfp". We support ARMv6 and following CPU generations. Hosts without > either FPU or older CPUs than ARMv6 will not get work. I think this is > better than trying to encode this information (and all possible > combinations!) of features in the platform string. And it's not done that > way on any of the other platforms, e.g. there is no SSE,SSE2, AVX etc. > Windows or Linux platform. > > Cheers > HB _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
