Re: Which ARM architectures need support? (was Re: Restructuring trapframe)

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 20 Sep, 2013, at 20:18 , Matt Thomas <matt%3am-software.com@localhost> wrote:
> using the -mcpu= or -march will do the right thing for C and C++.
> 
> For assembly, we have some macros to help.
> 
> RET expand to mov pc, lr or bx lr 
> 
> Note that earm defaults to armv5te so we get clz, blx reg, ldrd/strd,
> and a few others.
> 
> It's one reason we have earmv{4,5,6,7}{,hf}{,eb}
> If you want earm for shark/cats/netwinder/etc use earmv4 and 
> the non-armv4 instructions will be avoided.

Yes, but I've been writing inline __asm() and some short assembly
functions for a few things that are significantly improved by that,
so instructions are only avoided if I avoid them.  Using umull in a
__asm() statement requires earlyclobber constraints on the destination
registers for pre-armv6 which you wouldn't necessarily want there for
armv6 or later, while if you have a problem in assembly code for which
clz provides the answer the alternatives to that can take a whole lot
more instructions.

I think I get now that all assembly code needs to be runnable on
armv4.  Am I right that the architecture defines used in <arm/cdefs.h>
can be relied upon to tell you what the compiler is compiling for, so
that if what is required to make it run on armv4 seems offensively
expensive a nicer alternative when compiling for more modern CPUs
can be #ifdef'd in?  Also, if __builtin_clz() and __builtin_clzll() are
used in a kernel compiled for a CPU missing the instructions, are the
run-time functions it instead emits calls to available?

Dennis Ferguson