[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm
Subject:    Re: StrongARM cards in RiscPC
From:       <pb () nexus ! co ! uk>
Date:       1998-08-25 18:10:31
[Download RAW message or body]

On Fri, 12 Mar 1999, Nicholas Clark wrote:

> However, I don't understand what the sa110 changes are in order to propagate
> them into proc-arm6,7.S, and remove the offending:
> 
> 		teq	r0, #0
> 		moveq	r0, #DOM_KERNELDOMAIN
> 		movne	r0, #DOM_USERDOMAIN

The domain word is now stored directly in the tss.  You should just be
able to copy the code from proc-sa110.S.  Sorry about that; the ARM6/7
stuff must have slipped through my exhaustive test procedures. :-)

> However, I'm not sure why I need to get the MMU stuff for an ARM7 when I have
> a StrongARM in my RiscPC.

It's so small that it's not worth taking it out.  You'd only save a few
hundred bytes and the code would become more complicated as a result.

> What architecture are you compiling for?		[RiscPC here]
> What is the minimum CPU required to run?	[eg ARM6 or StrongARM]
> Tune for which CPU?

The objective is to have the minimum number of options.  As things stand
now if you ask for a RiscPC kernel you know it will work on any RiscPC
with any processor.  Adding the "minimum CPU required" thing would break
this, and as I said above I don't think it buys much.

> 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?
> 
> (Can gcc already do -march=armv4 with another -m to stop LDRH/STRH?)

No, there is no way to turn off halfword operations without other ARMv4
instructions.  It would be possible to add a new -mbroken-like-acorn 
option to do this but again the gain is so small that it doesn't seem
worth adding to the proliferation of compiler switches we already have.  I
would be very surprised if you can even measure the performance difference
between a kernel with long multiplies and one without.

If you're at the stage where you're worried about performance to the
extent that every last cycle counts, then firstly you should seriously
consider upgrading your cpu in any case, and secondly there are plenty of
places in the kernel and GCC where there is the opportunity to save far
more time than you'd typically gain from long multiplies.

p.

unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]