Hi, > While looking at the Configure script, I found that there is the > armv4_asm variable, which seems to promise a speedup for ARM > architectures (and the "4" in ARMv4 sounds like it should work > "everywhere"?).
Yes. v4 denotes only *minimal* requirement. There is conditionally compiled code that targets v7 and even v8. > However, further looking at that Configure file, I > see it's only used for "linux-armv4" and "android-armv7", but not for > e.g. iphoneos-cross. Does that imply you know/suspect it doesn't work > anyway? Apple assembler uses a little bit different syntax and you can't assemble current modules as they are. There is perlasm/arm-xlate.pl that enables assembly for 64-bit iOS, and it's being modified to cover even 32-bit iOS. > Or does it imply there is no measurable speedup? You'll observe as much speedup on iOS as on Linux/Android. > Or does it > just imply you never bothered to actually test it? And in the last > case, would you expect it's going to work (or "almost") or would you > rather expect it's going to be lots of trouble? See above. > Similar question for > Android: You only use the assembler code for the "android-armv7" > configuration. For maximum compatibility, I'm usually compiling with > "-march=armv5te", which still sounds like using "armv4" assembler > should be safe, but for some reason, you're restricting its use to > the "android-armv7" configuration which explicitly sets > "-march=armv7-a". Why? Because that target was conceived to solve very specific problem, one can say too specific. In other words, yes, it's appropriate to extend support and introduce additional or unified target in linux-armv4 style. What would be more appropriate? I mean additional or unified? More specifically. Android has two distinct ARM targets, in sense that if you build JNI-enabled application, then you'd have to provide two ARM shared libraries, right? Question is is if both can be build with unified config (see linux-armv4 for example) or does it have to be two config lines? _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
