Restricting architectures

Arnd Bergmann arnd at
Thu Sep 2 16:56:49 BST 2010

On Wednesday 01 September 2010, Michael Hope wrote:

> We will try to do no harm to other architectures or earlier ARM
> versions.  The Thumb-2 routines may be applicable to the Cortex-M and
> Cortex-R series but we will not optimise for them.
> I'd like Linaro to state this explicitly in the next round.
> defines a
> 'Standard ARMv7 Configuration' but there's no higher level statement
> justifying it, no statement restricting us to it, and it includes ARM,
> Thumb-2, and Thumb-1.

I think there are two aspects to this:

On the one hand, we need to improve the code formost for new CPUs looking
forward, so the latest generation of shiny high-end hardware is what
matters the most and needs to be the primary target. Today's high end
is tomorrow's mainstream, so sooner or later everyone will benefit from

On the other hand, I think we need to be relevant and provide code that
everyone can use. The market today mainly consists of stuff that's not
the primary focus, like ARM926 or some non-MMU cores. Refusing to do a
simple fix because it's not relevant for Cortex-A8/A9 will just manage
to piss off people [1].

Obviously there has to be a middle ground. We're building the binary
packages for the configuration Dave mentioned (v7A/Neon), but IMHO
that shouldn't prevent anyone from rebuilding it with our tool chain
without having to make significant changes. If there are patches readily
available for stuff that's not our primary focus (thumb1, non-cortex v7A
CPUs, vfp without neon, ...), I'd say we should still keep them or
get them upstream.



More information about the Linaro-dev mailing list