Subject: Re: egcs 1.1.1 assembler output for 2.2. kernel compilation.

From: <[email-masked]>
Date: Fri, 21 Aug 1998 21:10:17 +0000 (UTC)

On Sat, 6 Mar 1999, Nicholas Clark wrote:

> Apart from LDRH/STRH is there anything that egcs will do that the ART
> StrongARM card won't like?

I don't think so.  If you use the latest -philb patch then the theory is
that it won't do halfwords either.  Judging by other messages this may be
a bit broken at the moment but it's probably due to my attempts to fix up
the MM code for ARM6/7 without adequately testing it, and it should be
easy enough to sort it out.

> (I had a look at arm.c and arm.h in gcc - erk, it's complex. Am I
> right in thinking that currently gcc doesn't attempt to reoder LDR
> instructions 

This is the sort of thing that -mtune=strongarm110 should turn on (which
is precisely what the above patch does in fact).  I don't have the GCC
sources handy right now so I can't comment on particular optimisations
being in or out.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: <[email-masked]>
Date: Sun, 23 Aug 1998 18:12:24 +0000 (UTC)

On Fri, 5 Mar 1999, Richard Atterer wrote:

> In article <[email-masked]>
>     Russell King - ARM Linux Admin <[email-masked]> wrote:
> 
> > The ARM2 data book says:
> > 
> > 'In the case of post-indexed addressing, the write back bit is
> > redundant, since the old base value can be retained by setting the
> > offset to zero.'
> > 
> > Hence, when specifing an offset of zero, since no writeback is
> > performed, the result is predictable.  However, the question now is,
> > does this apply to the later processors?  Have ARM updated their ARM
> > to include this? Did they purposely remove this?  Or what?
> 
> I don't read the above quote as
> 
>   "if the offset is 0, no writeback is performed",
>   
> rather as
> 
>   "since 0 is added, it's as if no writeback had taken place".

Agreed.  I've now had confirmation from ARM Ltd that LDRT Rm, [Rm] results
in UNPREDICTABLE behaviour.  So it appears that binutils is correct and we
should fix the kernel.

> IMHO egcs really ought to produce 'ldrbt r6,[r6,#0]' instead of
> 'ldrbt r6,[r6],#0'.

That would be even worse; it's not a legal instruction.  There is no
pre-indexed version of LDRT.

p.

---

From: <[email-masked]>
Date: Mon, 24 Aug 1998 08:13:33 +0000 (UTC)

On Thu, 11 Mar 1999, Nicholas Clark wrote:

> In the last mail [email-masked] said:
> 
> Whoa - that's not actually the culprit, is it?

Yes.  The LDRT is generated by an inline asm.  Those asms need to be given
constraints to tell the compiler that the input and output regs mustn't
overlap.  GCC itself never open codes an LDRT.

> code was generated with gcc -S and the same command line. I think I
> know why the problem may not have been noticed before - with gcc -O2
> -S I discover that all the LDRTs are optimised so that Rm never equals
> Rn. (One is usually ip or lr, but not quite always)

That may well be the case by chance at the moment but there's nothing to
guarantee it will always hold.

p.

---

From: <[email-masked]>
Date: Wed, 26 Aug 1998 16:35:41 +0000 (UTC)

> So is this the correct patch I've attached?
> (Still can't boot 2.2.2 :-( )
> 
> Nick
> 
> --- include/asm-arm/proc-armv/uaccess.h~        Fri Mar 12 17:10:47 1999
> +++ include/asm-arm/proc-armv/uaccess.h Sat Mar 13 00:36:56 1999
> @@ -133,7 +133,7 @@
>         "       .align  3\n"                                    \
>         "       .long   1b, 3b\n"                               \
>         "       .previous"                                      \
> -       : "=r" (err), "=r" (x)                                  \
> +       : "=r" (err), "=&r" (x)                                 \

Looks pretty good to me.  Does it remove the warnings you were seeing?

p.