Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

> > 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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

> > > 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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

[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.

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

>> > 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. >> >> >>

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

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, using

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

Andy Polyakov ap...@openssl.org 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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

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 where it

[openssl-dev] Making assembly language optimizations working on Cortex-M3

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 where it became