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

[Brian Smith]

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 Thumb-2. Well, this
        # limitation is a bit artificial, because it's not really
        # impossible, but it's deemed too tricky to support.

Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is
exactly the problematic configuration, if I understand that comment
correctly. I am interested in getting libcrypto working for these
processors with the assembly language optimizations enabled. Specifically,
the configuration I am interested in is:

CC=arm-none-eabi-gcc -mcpu=cortex-m3 -march=armv7-m
-mthumb  -D__ARM_MAX_ARCH__=7.

Currently, the assembly language source files don't compile because they
expect to be able to use ARM (-marm) instructions when __ARM_MAX_ARCH__ >=
7. Further, they try to do feature detection for NEON in that case, but I'd
prefer to not have the feature detection compiled in, since I know NEON is
never available.

Has anybody started working on this?

If not, my thinking was to refactor the assembly language code so that all
the ARM-only (-marm) code is cleanly separated from the unified (-mthumb
and -marm) code, move the detection of NEON from the assembly language code
to the C wrappers, and recognize two new settings, OPENSSL_NO_ARM_NEON and
OPENSSL_ARM_THUMB_ONLY, to accommodate this. Does this seem like a
reasonable strategy? It would be quite a large change so I think it would
be good to have some coordination ahead of time.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150805/dee26890/attachment.html>