Andy Polyakov wrote:
>> > Cortex-M platforms are so limited that every bit of performance and
>> > space savings matters. So, I think it is definitely worthwhile to
>> > support the non-NEON ARMv7-M configuration. One easy way to do this
>> > would be to avoid building NEON code wh
> > Cortex-M platforms are so limited that every bit of performance and
> > space savings matters. So, I think it is definitely worthwhile to
> > support the non-NEON ARMv7-M configuration. One easy way to do this
> > would be to avoid building NEON code when __TARGET_PROFILE_M is d
Andy Polyakov wrote:
> > Cortex-M platforms are so limited that every bit of performance and
> > space savings matters. So, I think it is definitely worthwhile to
> > support the non-NEON ARMv7-M configuration. One easy way to do this
> > would be to avoid building NEON code when __TARGET_PROFILE
>
>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17
> made whole assembly pack Thumb2-friendly, so that now you should be able
> to compile all modules. Please, double-check.
>
>
> This is awesome!
>
> I have a question about t
[Sorry for the **long** delay in responding.]
Andy Polyakov wrote:
>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17
> made whole assembly pack Thumb2-friendly, so that now you should be able
> to compile all modules. Please, double-check.
>> > and recognize two new settings,
>> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.
>>
>> While NO_NEON might make sense, I really see no reason to introduce
>> THUMB_ONLY. Because pre-defines set by the compiler driver are
>> sufficient.
>>
>>
>> You
> > and recognize two new settings,
> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.
>
> While NO_NEON might make sense, I really see no reason to introduce
> THUMB_ONLY. Because pre-defines set by the compiler driver are
> sufficient.
>
>
> You mean,
Andy Polyakov wrote:
> > Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is
> > exactly the problematic configuration, if I understand that comment
> > correctly.
>
> The comment in question applies *exclusively* to cases when you attempt
> to build "universal" binary, one t
Hi,
> In ./Configure, there is this comment:
>
> # big-endian platform. This is because ARMv7 processor always
> # picks instructions in little-endian order. Another similar
> # limitation is that -mthumb can't "cross" -march=armv6t2
> # boundary, because that's wh
