[openssl-dev] Usage of assembler code on ARM architectures

[Andy Polyakov]

Hi,

>> There is perlasm/arm-xlate.pl that enables assembly for 64-bit
>> iOS, and it's being modified to cover even 32-bit iOS.
> 
> Is that something that can/will be backported to 1.0.2- (or even 1.0.1-)
> branch, once it's working?

Well, it would have to be *your* responsibility, because 1.0.2, as well
as 1.0.1, are closed for new features.

>> 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?
> 
> Here, you lost me. So far, I'm building only one shared library for ARM,
> using the no_asm variant of OpenSSL. And so far, there weren't complaints
> about unsupported devices, so what do you mean by "two distinct ARM
> targets"?

On Android you can build kind of "fat" apps, when same .apk contains JNI
shared object modules targeting different hardware architectures, right?
For example ARM, x86, MIPS. As far as I understand contemporary Android
ARM platforms come in two "flavours": armhf/armv7-a and traditional
armeabi. This means that along with say x86 module there is "room" for
*pair* of ARM shared libraries targeting these two ABIs. Google's idea
is naturally to provide better performance on former. For OpenSSL
performance choice of ABI doesn't really matter (because we don't do
much floating point), but it can be part of application that otherwise
uses a lot of floating point and therefore is sensitive to ABI choice.
This is how pair of shared libraries comes into picture. Does it mean
that we better have two config lines reflecting this? That's where we
need your support. To help us formulate what is sensible, what are
expectations and that it would actually benefit applications.