This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM] architecture specific subdirectories & optimised memchr [V3]


On 27 October 2011 00:42, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 28 Sep 2011, Dr. David Alan Gilbert wrote:
>
>> Hi,
>> ? As previously discussed, here is a new version of my ARM optimised memchr
>> and patch that picks up ARM version based on compiler flags.
>
> Given the discussions on the newlib list, is this still the version of the
> memchr code you are proposing or is there a newer one?

I can update with a new one in a few days; the tweeks as discussed on
that list are minor.

>> + ? ? ? ? ? ? case x$archcppflag in
>> + ? ? ? ? ? ? x__ARM_ARCH_7A__)
>> + ? ? ? ? ? ? ? machine=armv7
>> + ? ? ? ? ? ? ? echo "Found compiler is configured for $machine"
>> + ? ? ? ? ? ? ? ;;
>> +
>> + ? ? ? ? ? ? x__ARM_ARCH_6T2__)
>> + ? ? ? ? ? ? ? machine=armv6t2
>> + ? ? ? ? ? ? ? echo "Found compiler is configured for $machine"
>> + ? ? ? ? ? ? ? ;;
>
> Let's assume we do detect architecture variants this way. ?The main
> problem is that this will be suboptimal on any future architecture
> variants - if the compiler defines __ARM_ARCH_8A__, for example. ?There
> are various ways to avoid that issue:

It's difficult, especially since the naming convention isn't quite linear;
i.e. we have the A variant on 7, I don't know if that convention will
stay for 8; and since it looks like 8 is going to have 32 and 64bit variants
it looks like a much bigger overhaul of the config around that area
will happen.

> * sysdeps/arm/memcpy.S has a conditional on all the macros for older
> architecture variants not being defined. ?That's not a very convenient way
> to do things and it's always possible there could be a new variant of
> ARMv6, say.
>
> * Hopefully in the future the compiler will define a macro directly with a
> version number for the architecture, which will make this easier.

Yes, that would be nice.

> * At present, the best approach for a configure script like this is
> probably to handle __ARM_ARCH_[789]* and __ARM_ARCH_1[0-9]* the same as
> your patch handles __ARM_ARCH_7A__ - assume that all v7 and later
> architectures can use this code.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]