On Fri, 12 Mar 1999, Nicholas Clark wrote:
> For a distribution kernel you'd answer RiscPC,ARM6,StrongARM on the assumption
> that most people have StrongARMs, but some only have ARM6, so you'd like it to
> run on everything, but run fastest on StrongARM.
This would be equivalent to compiling with
-march=armv3l -mtune=strongarm110
and is feasible now.
> And when I build my personal kernel I'd like to say RiscPC,StrongARM,StrongARM
> and get 64 bit multiplies, sign extending byte loads and other StrongARM
> instructions, with arch/arm/Makefile clever enough to realise that it'll
> have to tell gcc to prevent generation of LDRH and STRH.
There's no way, AFAICS, of turning off and on LDRH/STRH separately from
the rest of the v4 instruction set: look in `egcs/gcc/config/arm/arm.h'.
There *are* these two options:
{"short-load-words", -ARM_FLAG_SHORT_BYTE}, \
{"no-short-load-words", ARM_FLAG_SHORT_BYTE}, \
but I suspect they do something else?
> Currently it seems that both PhilB and Russell's work arounds to cope with
> *****y Acorn's card basically generate ARM7 kernels. Am I missing much
> performance not getting the armv4 instructions?
You're right; unless you specify `--with-cpu', or your machine name
begins with `armv2' (see `egcs/configure.in'), the target CPU is simply
set to `generic', which if you look in egcs/gcc/config/arm/arm.h is
currently a synonym for ARM610.
I don't think you're missing much performance, no. I don't believe gcc
can use (`open code'?) most of the v4-over-v3 improvments.
> (Can gcc already do -march=armv4 with another -m to stop LDRH/STRH?)
See above.
> Is this an optimal way of doing things? Or have I missed something?
Patch arm.[ch].
--
Chris <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
