[RFC] Optimize swab operations on mips_r2 cpu

[RFC] Optimize swab operations on mips_r2 cpu

[Franck]

Here is a little patch to optimize swab operations by using "wsbh"
instruction available on mips revision 2 cpus. I do not know what
condition I should use to compile this only for mips r2 cpu though.

Comments ?

Thanks
--
               Franck

--- linux.git/include/asm-mips/byteorder.h~old	2006-01-25
09:39:33.000000000 +0100
+++ linux.git/include/asm-mips/byteorder.h	2006-01-25 10:30:10.000000000 +0100
@@ -8,15 +8,39 @@
 #ifndef _ASM_BYTEORDER_H
 #define _ASM_BYTEORDER_H

+#include <linux/compiler.h>
 #include <asm/types.h>

 #ifdef __GNUC__

+/* FIXME: MIPS_R2 only */
+static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 x)
+{
+	__asm__(
+		"wsbh	%0, %1\n"
+		: "=r" (x)
+		: "r" (x));
+	return x;
+}
+
+static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 x)
+{
+	__asm__(
+		"wsbh	%0, %1\n\t"
+		"rotr	%0, %0, 16\n"
+		: "=r" (x)
+		: "r" (x));
+	return x;
+}
+
 #if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
 #  define __BYTEORDER_HAS_U64__
 #  define __SWAB_64_THRU_32__
 #endif

+#define __arch__swab16(x)	___arch__swab16(x)
+#define __arch__swab32(x)	___arch__swab32(x)
+
 #endif /* __GNUC__ */

 #if defined (__MIPSEB__)

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Wed, Jan 25, 2006 at 10:36:46AM +0100, Franck wrote:

> Here is a little patch to optimize swab operations by using "wsbh"
> instruction available on mips revision 2 cpus. I do not know what
> condition I should use to compile this only for mips r2 cpu though.
> 
> Comments ?

Looks good aside of the one issue you've already raised yourself:

> +/* FIXME: MIPS_R2 only */

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

Hi Ralf

2006/1/25, Ralf Baechle <ralf@linux-mips.org>:
> On Wed, Jan 25, 2006 at 10:36:46AM +0100, Franck wrote:
>
> > Here is a little patch to optimize swab operations by using "wsbh"
> > instruction available on mips revision 2 cpus. I do not know what
> > condition I should use to compile this only for mips r2 cpu though.
> >
> > Comments ?
>
> Looks good aside of the one issue you've already raised yourself:
>
> > +/* FIXME: MIPS_R2 only */
>

I was actually asking for advices :)

I can see only two simple ways to do that:
(a) we can define a couple of new macro ie CONFIG_MIPS32_ISET_R[12]
that can be set depending on the selected CPU;
(b) define a new macro CONFIG_CPU_HAS_WSBH;

What do you think ?

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

Franck wrote:
> Hi Ralf
> 
> 2006/1/25, Ralf Baechle <ralf@linux-mips.org>:
>> On Wed, Jan 25, 2006 at 10:36:46AM +0100, Franck wrote:
>>
>>> Here is a little patch to optimize swab operations by using "wsbh"
>>> instruction available on mips revision 2 cpus. I do not know what
>>> condition I should use to compile this only for mips r2 cpu though.
>>>
>>> Comments ?
>> Looks good aside of the one issue you've already raised yourself:
>>
>>> +/* FIXME: MIPS_R2 only */
> 
> I was actually asking for advices :)
> 
> I can see only two simple ways to do that:
> (a) we can define a couple of new macro ie CONFIG_MIPS32_ISET_R[12]
> that can be set depending on the selected CPU;
> (b) define a new macro CONFIG_CPU_HAS_WSBH;

Don't we already have CONFIG_CPU_MIPS32R2?

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Wed, Jan 25, 2006 at 03:11:49PM +0100, Kevin D. Kissell wrote:

> >>>Comments ?
> >>Looks good aside of the one issue you've already raised yourself:
> >>
> >>>+/* FIXME: MIPS_R2 only */
> >
> >I was actually asking for advices :)
> >
> >I can see only two simple ways to do that:
> >(a) we can define a couple of new macro ie CONFIG_MIPS32_ISET_R[12]
> >that can be set depending on the selected CPU;
> >(b) define a new macro CONFIG_CPU_HAS_WSBH;
> 
> Don't we already have CONFIG_CPU_MIPS32R2?

We have CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, CPU_MIPS64_R2.
Based on those we also define CPU_MIPS32, CPU_MIPS64, CPU_MIPSR1,
and CPU_MIPSR2 as short cuts.

In this particular case

#include <linux/config.h>

#ifdef CONFIG_CPU_MIPSR2
...
#else
...

would be what we want.

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/25, Ralf Baechle <ralf@linux-mips.org>:
> On Wed, Jan 25, 2006 at 03:11:49PM +0100, Kevin D. Kissell wrote:
>
> > >>>Comments ?
> > >>Looks good aside of the one issue you've already raised yourself:
> > >>
> > >>>+/* FIXME: MIPS_R2 only */
> > >
> > >I was actually asking for advices :)
> > >
> > >I can see only two simple ways to do that:
> > >(a) we can define a couple of new macro ie CONFIG_MIPS32_ISET_R[12]
> > >that can be set depending on the selected CPU;
> > >(b) define a new macro CONFIG_CPU_HAS_WSBH;
> >
> > Don't we already have CONFIG_CPU_MIPS32R2?
>
> We have CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, CPU_MIPS64_R2.
> Based on those we also define CPU_MIPS32, CPU_MIPS64, CPU_MIPSR1,
> and CPU_MIPSR2 as short cuts.
>

hm I should have missed something, but what about CPUs which have
their own CPU_XXX (different form CPU_MIPS32_R[12]) and which are a
mips32-r2 compliant for example ? (I'm thinking of 4KSD for example)

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Wed, Jan 25, 2006 at 03:32:22PM +0100, Franck wrote:

> > We have CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, CPU_MIPS64_R2.
> > Based on those we also define CPU_MIPS32, CPU_MIPS64, CPU_MIPSR1,
> > and CPU_MIPSR2 as short cuts.
> >
> 
> hm I should have missed something, but what about CPUs which have
> their own CPU_XXX (different form CPU_MIPS32_R[12]) and which are a
> mips32-r2 compliant for example ? (I'm thinking of 4KSD for example)

The 4KSD is still a MIPS32 processor - just one with an ASE.

The real bug here - and what's causing your confusion - is that the
processor configuration is mixing up all the architecture variants
(MIPS I - IV, MIPS32 and MIPS64 R1/R2, weirdo variants ...) and the
processor types.  Example: 4K, 4KE, 24K, 24KE, 34K, AMD Alchemy are all
MIPS32 (either R1 or R2).  R4000, R4400, R4600 are all MIPS III.  But
what we actually offer in the processor configuration is R4X00, MIPS32_R1,

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/25, Ralf Baechle <ralf@linux-mips.org>:
> On Wed, Jan 25, 2006 at 03:32:22PM +0100, Franck wrote:
>
> > > We have CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, CPU_MIPS64_R2.
> > > Based on those we also define CPU_MIPS32, CPU_MIPS64, CPU_MIPSR1,
> > > and CPU_MIPSR2 as short cuts.
> > >
> >
> > hm I should have missed something, but what about CPUs which have
> > their own CPU_XXX (different form CPU_MIPS32_R[12]) and which are a
> > mips32-r2 compliant for example ? (I'm thinking of 4KSD for example)
>
> The 4KSD is still a MIPS32 processor - just one with an ASE.
>
> The real bug here - and what's causing your confusion - is that the
> processor configuration is mixing up all the architecture variants
> (MIPS I - IV, MIPS32 and MIPS64 R1/R2, weirdo variants ...) and the
> processor types.  Example: 4K, 4KE, 24K, 24KE, 34K, AMD Alchemy are all
> MIPS32 (either R1 or R2).  R4000, R4400, R4600 are all MIPS III.  But
> what we actually offer in the processor configuration is R4X00, MIPS32_R1,
>

OK. So the patch I sent to you 3 months ago that adds support for
4ks[cd] cpu and smartmips extension is wrong. It added new
CONFIG_CPU_4KS[CD] macro whereas it must have used MIPS32_R[12] macros
like Kevin suggested...

BTW, any chances to get smartmips support merged into your tree ?

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

Franck wrote:
> 2006/1/25, Ralf Baechle <ralf@linux-mips.org>:
>> On Wed, Jan 25, 2006 at 03:32:22PM +0100, Franck wrote:
>>
>>>> We have CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, CPU_MIPS64_R2.
>>>> Based on those we also define CPU_MIPS32, CPU_MIPS64, CPU_MIPSR1,
>>>> and CPU_MIPSR2 as short cuts.
>>>>
>>> hm I should have missed something, but what about CPUs which have
>>> their own CPU_XXX (different form CPU_MIPS32_R[12]) and which are a
>>> mips32-r2 compliant for example ? (I'm thinking of 4KSD for example)
>> The 4KSD is still a MIPS32 processor - just one with an ASE.
>>
>> The real bug here - and what's causing your confusion - is that the
>> processor configuration is mixing up all the architecture variants
>> (MIPS I - IV, MIPS32 and MIPS64 R1/R2, weirdo variants ...) and the
>> processor types.  Example: 4K, 4KE, 24K, 24KE, 34K, AMD Alchemy are all
>> MIPS32 (either R1 or R2).  R4000, R4400, R4600 are all MIPS III.  But
>> what we actually offer in the processor configuration is R4X00, MIPS32_R1,
>>
> 
> OK. So the patch I sent to you 3 months ago that adds support for
> 4ks[cd] cpu and smartmips extension is wrong. It added new
> CONFIG_CPU_4KS[CD] macro whereas it must have used MIPS32_R[12] macros
> like Kevin suggested...

Not really.  As we discussed at the time, the 4KSc is a superset of
MIPS32 which includes some, but not all MIPS32R2 features (plus other
stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
information is required to express the desired support.  I was just pointing
out, in the case of the SWAB optimizations, that there was no need to invent
yet another way of describing MIPS32R2.

	Regards,

	Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/25, Kevin D. Kissell <kevink@mips.com>:
> Franck wrote:
> > OK. So the patch I sent to you 3 months ago that adds support for
> > 4ks[cd] cpu and smartmips extension is wrong. It added new
> > CONFIG_CPU_4KS[CD] macro whereas it must have used MIPS32_R[12] macros
> > like Kevin suggested...
>
> Not really.  As we discussed at the time, the 4KSc is a superset of
> MIPS32 which includes some, but not all MIPS32R2 features (plus other
> stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
> information is required to express the desired support.  I was just pointing
> out, in the case of the SWAB optimizations, that there was no need to invent
> yet another way of describing MIPS32R2.
>

Let's say that the 4KSC has "wsbh" instruction which is part of
MIPS32R2 instructrion set (I haven't checked it). The question is how
the 4KSC would use the SWAB optimizations since it doesn't define
CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

Franck wrote:
> 2006/1/25, Kevin D. Kissell <kevink@mips.com>:
>> Franck wrote:
>>> OK. So the patch I sent to you 3 months ago that adds support for
>>> 4ks[cd] cpu and smartmips extension is wrong. It added new
>>> CONFIG_CPU_4KS[CD] macro whereas it must have used MIPS32_R[12] macros
>>> like Kevin suggested...
>> Not really.  As we discussed at the time, the 4KSc is a superset of
>> MIPS32 which includes some, but not all MIPS32R2 features (plus other
>> stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
>> information is required to express the desired support.  I was just pointing
>> out, in the case of the SWAB optimizations, that there was no need to invent
>> yet another way of describing MIPS32R2.
> 
> Let's say that the 4KSC has "wsbh" instruction which is part of
> MIPS32R2 instructrion set (I haven't checked it). The question is how
> the 4KSC would use the SWAB optimizations since it doesn't define
> CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...

The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
"wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
it's part of the SmartMIPS ASE.  Our options here include:

* Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
   with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.

* Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
   make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)

* Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
   the 4KSc and 4KSd.  In that case code using ROTR could be conditional on
   #if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).

I personally think that the third option is the cleanest and most conceptually
correct, but I'm not the guy operationally responsible for maintaining
that code.

		Regards,

		Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Kevin D. Kissell <kevink@mips.com>:
> Franck wrote:
> > Let's say that the 4KSC has "wsbh" instruction which is part of
> > MIPS32R2 instructrion set (I haven't checked it). The question is how
> > the 4KSC would use the SWAB optimizations since it doesn't define
> > CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...
>
> The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
> "wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
> it's part of the SmartMIPS ASE.  Our options here include:
>
> * Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
>    with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.
>
> * Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
>    make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)
>
> * Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
>    the 4KSc and 4KSd.  In that case code using ROTR could be conditional on
>    #if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).
>
> I personally think that the third option is the cleanest and most conceptually
> correct, but I'm not the guy operationally responsible for maintaining
> that code.
>

I think we will have to use second _and_ third options. I can't find
out an example, but since 4KSC has some MIPS32_R2 instructions it will
need to use some specific MIPS32_R2 code sometimes.

Anyways I'm going to send to Ralf a new patch for swab optimizations.

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Franck wrote:
> > > Let's say that the 4KSC has "wsbh" instruction which is part of
> > > MIPS32R2 instructrion set (I haven't checked it). The question is how
> > > the 4KSC would use the SWAB optimizations since it doesn't define
> > > CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...
> >
> > The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
> > "wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
> > it's part of the SmartMIPS ASE.  Our options here include:
> >
> > * Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
> >    with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.
> >
> > * Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
> >    make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)
> >
> > * Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
> >    the 4KSc and 4KSd.  In that case code using ROTR could be conditional on
> >    #if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).
> >
> > I personally think that the third option is the cleanest and most conceptually
> > correct, but I'm not the guy operationally responsible for maintaining
> > that code.
> 
> I think we will have to use second _and_ third options. I can't find
> out an example, but since 4KSC has some MIPS32_R2 instructions it will
> need to use some specific MIPS32_R2 code sometimes.

You don't understand. There is nothing in the 4KSc that is not in the SmartMIPS ASE.
The 4KSc implements MIPS32+SmartMIPS.  The 4KSd implementes MIPS32R2+SmartMIPS.
You're getting confused because some elements of SmartMIPS made it into MIPS32R2.
If we have a CONFIG_CPU_SMARTMIPS flag, there would be no need for a
CONFIG_CPU_MIPS4KSC flag.

        Regards,

        Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Franck wrote:
> > > Let's say that the 4KSC has "wsbh" instruction which is part of
> > > MIPS32R2 instructrion set (I haven't checked it). The question is how
> > > the 4KSC would use the SWAB optimizations since it doesn't define
> > > CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...
> >
> > The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
> > "wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
> > it's part of the SmartMIPS ASE.  Our options here include:
> >
> > * Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
> >    with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.
> >
> > * Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
> >    make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)
> >
> > * Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
> >    the 4KSc and 4KSd.  In that case code using ROTR could be conditional on
> >    #if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).
> >
> > I personally think that the third option is the cleanest and most conceptually
> > correct, but I'm not the guy operationally responsible for maintaining
> > that code.
> 
> I think we will have to use second _and_ third options. I can't find
> out an example, but since 4KSC has some MIPS32_R2 instructions it will
> need to use some specific MIPS32_R2 code sometimes.

You don't understand. There is nothing in the 4KSc that is not in the SmartMIPS ASE.
The 4KSc implements MIPS32+SmartMIPS.  The 4KSd implementes MIPS32R2+SmartMIPS.
You're getting confused because some elements of SmartMIPS made it into MIPS32R2.
If we have a CONFIG_CPU_SMARTMIPS flag, there would be no need for a
CONFIG_CPU_MIPS4KSC flag.

        Regards,

        Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Kevin D. Kissell <kevink@mips.com>:
> > > Franck wrote:
> > > > Let's say that the 4KSC has "wsbh" instruction which is part of
> > > > MIPS32R2 instructrion set (I haven't checked it). The question is how
> > > > the 4KSC would use the SWAB optimizations since it doesn't define
> > > > CONFIG_CPU_MIPS32_R2  ? The 4KSC might not be the only one case...
> > >
> > > The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
> > > "wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
> > > it's part of the SmartMIPS ASE.  Our options here include:
> > >
> > > * Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
> > >    with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.
> > >
> > > * Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
> > >    make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)
> > >
> > > * Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
> > >    the 4KSc and 4KSd.  In that case code using ROTR could be conditional on
> > >    #if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).
> > >
> > > I personally think that the third option is the cleanest and most conceptually
> > > correct, but I'm not the guy operationally responsible for maintaining
> > > that code.
> >
> > I think we will have to use second _and_ third options. I can't find
> > out an example, but since 4KSC has some MIPS32_R2 instructions it will
> > need to use some specific MIPS32_R2 code sometimes.
>
> You don't understand. There is nothing in the 4KSc that is not in the SmartMIPS ASE.
> The 4KSc implements MIPS32+SmartMIPS.  The 4KSd implementes MIPS32R2+SmartMIPS.
> You're getting confused because some elements of SmartMIPS made it into MIPS32R2.
> If we have a CONFIG_CPU_SMARTMIPS flag, there would be no need for a
> CONFIG_CPU_MIPS4KSC flag.
>

I think I was confused by your previous description of 4KSC:

"""
the 4KSc is a superset of MIPS32 which includes some, but not all
MIPS32R2 features (plus other stuff),
"""

I understood it like:
        The 4KSC implements MIPS32 + SmartMIPS + a_part_of(MIPS32R2)
But now you're saying:
        The 4KSC implements MIPS32 + SmartMIPS

I didn't understand that a_part_of(MIPS32R2) elements were part of the
SmartMIPS extension....

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

Kevin

2006/1/25, Kevin D. Kissell <kevink@mips.com>:
> Not really.  As we discussed at the time, the 4KSc is a superset of
> MIPS32 which includes some, but not all MIPS32R2 features (plus other
> stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
> information is required to express the desired support.  I was just pointing
> out, in the case of the SWAB optimizations, that there was no need to invent
> yet another way of describing MIPS32R2.
>

I'm trying to use CPU_MIPS32_R2 instead of CPU_4KD in order to get rid
of the last macro. So now to compile the kernel I'm using somthing
like:

        mipsel-linux-gcc -march=mips32r2 -Wa,-32 -Wa,-mips32r2 -msmartmips

instead of

        mipsel-linux-gcc -march=4ksd -Wa,-32 -Wa,-mips32r2 -msmartmips

Now the size of the kernel code is 33Ko bigger ! I have no idea
why...I tried to add -mips16e option but it fails to compile...Do you
have an idea ?

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

Could you please post your mipsel-linux-gcc -v output?   It might help.
I've never tried building Linux with any of the Sc/Sd/SmartMIPS options,
so I really don't know what you could be experiencing.  One thought that
comes to mind is that the -march=4ksd option may be treated as a hint to
generate compact code (for smart cards) in a way that -march=mips32r2
is not.  I'll ask around...

        Regards,

        Kevin K.

----- Original Message ----- 
From: "Franck" <vagabon.xyz@gmail.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: <linux-mips@linux-mips.org>
Sent: Thursday, January 26, 2006 4:02 PM
Subject: Re: [RFC] Optimize swab operations on mips_r2 cpu


> Kevin
> 
> 2006/1/25, Kevin D. Kissell <kevink@mips.com>:
> > Not really.  As we discussed at the time, the 4KSc is a superset of
> > MIPS32 which includes some, but not all MIPS32R2 features (plus other
> > stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
> > information is required to express the desired support.  I was just pointing
> > out, in the case of the SWAB optimizations, that there was no need to invent
> > yet another way of describing MIPS32R2.
> >
> 
> I'm trying to use CPU_MIPS32_R2 instead of CPU_4KD in order to get rid
> of the last macro. So now to compile the kernel I'm using somthing
> like:
> 
>         mipsel-linux-gcc -march=mips32r2 -Wa,-32 -Wa,-mips32r2 -msmartmips
> 
> instead of
> 
>         mipsel-linux-gcc -march=4ksd -Wa,-32 -Wa,-mips32r2 -msmartmips
> 
> Now the size of the kernel code is 33Ko bigger ! I have no idea
> why...I tried to add -mips16e option but it fails to compile...Do you
> have an idea ?
> 
> Thanks
> --
>                Franck
> 
> 

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

Could you please post your mipsel-linux-gcc -v output?   It might help.
I've never tried building Linux with any of the Sc/Sd/SmartMIPS options,
so I really don't know what you could be experiencing.  One thought that
comes to mind is that the -march=4ksd option may be treated as a hint to
generate compact code (for smart cards) in a way that -march=mips32r2
is not.  I'll ask around...

        Regards,

        Kevin K.

----- Original Message ----- 
From: "Franck" <vagabon.xyz@gmail.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: <linux-mips@linux-mips.org>
Sent: Thursday, January 26, 2006 4:02 PM
Subject: Re: [RFC] Optimize swab operations on mips_r2 cpu


> Kevin
> 
> 2006/1/25, Kevin D. Kissell <kevink@mips.com>:
> > Not really.  As we discussed at the time, the 4KSc is a superset of
> > MIPS32 which includes some, but not all MIPS32R2 features (plus other
> > stuff), and the 4KSd is a strict superset of MIPS32R2.  So some additional
> > information is required to express the desired support.  I was just pointing
> > out, in the case of the SWAB optimizations, that there was no need to invent
> > yet another way of describing MIPS32R2.
> >
> 
> I'm trying to use CPU_MIPS32_R2 instead of CPU_4KD in order to get rid
> of the last macro. So now to compile the kernel I'm using somthing
> like:
> 
>         mipsel-linux-gcc -march=mips32r2 -Wa,-32 -Wa,-mips32r2 -msmartmips
> 
> instead of
> 
>         mipsel-linux-gcc -march=4ksd -Wa,-32 -Wa,-mips32r2 -msmartmips
> 
> Now the size of the kernel code is 33Ko bigger ! I have no idea
> why...I tried to add -mips16e option but it fails to compile...Do you
> have an idea ?
> 
> Thanks
> --
>                Franck
> 
> 

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Kevin D. Kissell <kevink@mips.com>:
> Could you please post your mipsel-linux-gcc -v output?   It might help.

sure,

Reading specs from /usr/lib/gcc/mipsel-linux/3.4.4/specs
Configured with:
/var/tmp/releasetool-rpm.tmp/bank-20051114-1545/B-i386-linux-rpm/rpmbuild/BUILD/mipssde-6.03.01/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--disable-gdbtk --enable-languages=c
--with-local-prefix=/mipsel-linux/local --disable-multilib
--disable-shared --enable-static --disable-threads
--target=mipsel-linux --host=i386-linux --build=i386-linux
Thread model: single
gcc version 3.4.4 mipssde-6.03.01-20051114

> I've never tried building Linux with any of the Sc/Sd/SmartMIPS options,
> so I really don't know what you could be experiencing.  One thought that
> comes to mind is that the -march=4ksd option may be treated as a hint to
> generate compact code (for smart cards) in a way that -march=mips32r2

Yes, that's why I tried to pass -mips16e option.

> is not.  I'll ask around...
>

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Nigel Stephens]

Kevin D. Kissell wrote:

>Could you please post your mipsel-linux-gcc -v output?   It might help.
>I've never tried building Linux with any of the Sc/Sd/SmartMIPS options,
>so I really don't know what you could be experiencing.  One thought that
>comes to mind is that the -march=4ksd option may be treated as a hint to
>generate compact code (for smart cards) in a way that -march=mips32r2
>is not.  I'll ask around...
>  
>

Assuming that this is the SDE compiler, then I think that the only 
significant thing which -march=4ksd will do differently from 
-march=mips32r2 is to allow the compiler to generate branch-likely 
instructions -- they're deprecated for generic mips32 code but carry no 
penalty on the 4K core. It will also cause the compiler's "4kc" pipeline 
description to be used for instruction scheduling, instead of the 
default "24kc", but that should only change the order of instructions 
and shouldn't really make a significant difference to the code size.

>
>>Now the size of the kernel code is 33Ko bigger ! I have no idea
>>why...I tried to add -mips16e option but it fails to compile...Do you
>>have an idea ?
>>
>>    
>>

You certainly can't compile the kernel with -mips16e: too much inline 
asm code which won't work in mips16.

Nigel

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Nigel Stephens <nigel@mips.com>:
>
>
> Kevin D. Kissell wrote:
>
> >Could you please post your mipsel-linux-gcc -v output?   It might help.
> >I've never tried building Linux with any of the Sc/Sd/SmartMIPS options,
> >so I really don't know what you could be experiencing.  One thought that
> >comes to mind is that the -march=4ksd option may be treated as a hint to
> >generate compact code (for smart cards) in a way that -march=mips32r2
> >is not.  I'll ask around...
> >
> >
>
> Assuming that this is the SDE compiler, then I think that the only

yes it is (see my previous post)

> significant thing which -march=4ksd will do differently from
> -march=mips32r2 is to allow the compiler to generate branch-likely
> instructions -- they're deprecated for generic mips32 code but carry no
> penalty on the 4K core. It will also cause the compiler's "4kc" pipeline
> description to be used for instruction scheduling, instead of the
> default "24kc", but that should only change the order of instructions

Do you mean that the code can be run faster when using -march=4ksd ?

> and shouldn't really make a significant difference to the code size.
>

yes but I have :(

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > ...the only significant thing which -march=4ksd will do differently from
> > -march=mips32r2 is to allow the compiler to generate branch-likely
> > instructions -- they're deprecated for generic mips32 code but carry no
> > penalty on the 4K core. It will also cause the compiler's "4kc" pipeline
> > description to be used for instruction scheduling, instead of the
> > default "24kc", but that should only change the order of instructions
> 
> Do you mean that the code can be run faster when using -march=4ksd ?

Not necessarily, if it's just a question of branch-likelies.  It could be a little
faster, but it could also be a little slower.  In any case, the effect should be
minor.
 
> > and shouldn't really make a significant difference to the code size.
> 
> yes but I have :(

You report a 33K delta on the Linux kernel.  I would imagine that you're
probably building a pretty small kernel configuration, but even if you've got
it down to 1MB of text, that's still only about 3% bloat.  Undesirable, but
not catastrophic.

If we want to do something about this, however, I would argue that it should
not be strictly in the context of the 4KSd, because it's not only for that core
that people may have an interest in having the smallest possible kernel, and
it's not only that compiler option that could have an effect on the footprint.
I postulate (without proposing to actually do the work ;o) some kind of
CONFIG_<mumble>_COMPACT configuration option that would do
things like (but not limited to) forcing the use of branch-likely where appropriate,
regardless of the ISA level selected.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > ...the only significant thing which -march=4ksd will do differently from
> > -march=mips32r2 is to allow the compiler to generate branch-likely
> > instructions -- they're deprecated for generic mips32 code but carry no
> > penalty on the 4K core. It will also cause the compiler's "4kc" pipeline
> > description to be used for instruction scheduling, instead of the
> > default "24kc", but that should only change the order of instructions
> 
> Do you mean that the code can be run faster when using -march=4ksd ?

Not necessarily, if it's just a question of branch-likelies.  It could be a little
faster, but it could also be a little slower.  In any case, the effect should be
minor.
 
> > and shouldn't really make a significant difference to the code size.
> 
> yes but I have :(

You report a 33K delta on the Linux kernel.  I would imagine that you're
probably building a pretty small kernel configuration, but even if you've got
it down to 1MB of text, that's still only about 3% bloat.  Undesirable, but
not catastrophic.

If we want to do something about this, however, I would argue that it should
not be strictly in the context of the 4KSd, because it's not only for that core
that people may have an interest in having the smallest possible kernel, and
it's not only that compiler option that could have an effect on the footprint.
I postulate (without proposing to actually do the work ;o) some kind of
CONFIG_<mumble>_COMPACT configuration option that would do
things like (but not limited to) forcing the use of branch-likely where appropriate,
regardless of the ISA level selected.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Nigel Stephens]

Franck wrote:

>>-march=mips32r2 is to allow the compiler to generate branch-likely
>>instructions -- they're deprecated for generic mips32 code but carry no
>>penalty on the 4K core. It will also cause the compiler's "4kc" pipeline
>>description to be used for instruction scheduling, instead of the
>>default "24kc", but that should only change the order of instructions
>>    
>>
>
>Do you mean that the code can be run faster when using -march=4ksd ?
>  
>

Yes, though the difference is likely to be small. The -march=4ksd option 
also enables the SmartMIPS ASE, but you've already done that explicitly 
with -msmartmips.

>  
>
>>and shouldn't really make a significant difference to the code size.
>>
>>    
>>
>
>yes but I have :(
>  
>

Then you'll have to have a look at the resulting disassembled code and 
figure what's changed. :)

Thinking about this in more detail:

1) Using -march=4ksd reduces the cost of a multiply by 1 instruction 
(from 5 to 4 cycles), so a few more constant multiplications, previously 
expanded into a sequence of shifts, adds and subs, may now be replaced 
by a shorter sequence of "li" and "mul" instructions.

2) Enabling branch-likely may allow some instructions to be moved into a 
branch delay slot which previously couldn't be -- but usually these are 
duplicates of the code at the original branch target, so have little 
effect on overall code size.

3) Using -march=mips32r2 with -O1 and above (but not -Os) enables 64-bit 
alignment of functions and frequently-used branch targets (e.g. loop 
headers); whereas -march=4ksc will not do that. This will add some 
additional "nops" to the code.

Nigel

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Nigel Stephens <nigel@mips.com>:
>
> Then you'll have to have a look at the resulting disassembled code and
> figure what's changed. :)
>
> Thinking about this in more detail:
>
> 1) Using -march=4ksd reduces the cost of a multiply by 1 instruction
> (from 5 to 4 cycles), so a few more constant multiplications, previously
> expanded into a sequence of shifts, adds and subs, may now be replaced
> by a shorter sequence of "li" and "mul" instructions.
>

Is it really specific to 4ksd cpu ? Could this behaviour be triggered
by other options ?

> 2) Enabling branch-likely may allow some instructions to be moved into a
> branch delay slot which previously couldn't be -- but usually these are
> duplicates of the code at the original branch target, so have little
> effect on overall code size.
>
> 3) Using -march=mips32r2 with -O1 and above (but not -Os) enables 64-bit
> alignment of functions and frequently-used branch targets (e.g. loop
> headers); whereas -march=4ksc will not do that. This will add some
> additional "nops" to the code.
>

I noticed your last point when staring at the disassembled code. And
it seems to be ack by these figures:

   text    data     bss     dec     hex filename
2099642  110784   81956 2292382  22fa9e vmlinux-4ksd
2136269  110784   81956 2329009  2389b1 vmlinux-mips32r2
1953086  110784   81956 2145826  20be22 vmlinux-4ksd-Os
1954489  110784   81956 2147229  20c39d vmlinux-mips32r2-Os

I now have to check that your first and second points don't have too
much bad impact on the overall speed although I don't know how to
measure that...But if so, I could safely use -march=mips32r2 -Os
options.

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Nigel Stephens]

Franck wrote:

>2006/1/26, Nigel Stephens <nigel@mips.com>:
>  
>
>>1) Using -march=4ksd reduces the cost of a multiply by 1 instruction
>>(from 5 to 4 cycles), so a few more constant multiplications, previously
>>expanded into a sequence of shifts, adds and subs, may now be replaced
>>by a shorter sequence of "li" and "mul" instructions.
>>
>>    
>>
>
>Is it really specific to 4ksd cpu ? Could this behaviour be triggered
>by other options ?
>  
>

Yes, when you use -Os the compiler uses the instruction cost (1) of a 
mul, instead of the cycle cost (4), so it will be even more likely to 
replace the expanded shift/add sequence by a mul.

>>   text    data     bss     dec     hex filename
>>2099642  110784   81956 2292382  22fa9e vmlinux-4ksd
>>2136269  110784   81956 2329009  2389b1 vmlinux-mips32r2
>>1953086  110784   81956 2145826  20be22 vmlinux-4ksd-Os
>>1954489  110784   81956 2147229  20c39d vmlinux-mips32r2-Os
>>
>>I now have to check that your first and second points don't have too
>>much bad impact on the overall speed although I don't know how to
>>measure that...But if so, I could safely use -march=mips32r2 -Os
>>options.
>>    
>>

You could, but why not stick with -march=4ksd if that's your CPU of 
choice? It appears to result in  marginally smaller code even when using 
-Os, and should have (slightly) better performance than a generic 
mips32r2 kernel?

Nigel

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/26, Nigel Stephens <nigel@mips.com>:
>
> You could, but why not stick with -march=4ksd if that's your CPU of
> choice? It appears to result in  marginally smaller code even when using
> -Os, and should have (slightly) better performance than a generic
> mips32r2 kernel?
>

Just to avoid a new CPU_4KSD definition in the kernel code as
suggested by Kevin. Basically all mips32r2 specific code is the same
as 4ksd specific code (except the code that deals with SmartMIPS
extension). So it can use CONFIG_CPU_MIPS32_R2 macro. But I was not
aware of -march=4ksd and -march=mips32r2 differences. Maybe now it is
needed to have a new CPU_4KSD definition ?

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > You could, but why not stick with -march=4ksd if that's your CPU of
> > choice? It appears to result in  marginally smaller code even when using
> > -Os, and should have (slightly) better performance than a generic
> > mips32r2 kernel?
> 
> Just to avoid a new CPU_4KSD definition in the kernel code as
> suggested by Kevin. Basically all mips32r2 specific code is the same
> as 4ksd specific code (except the code that deals with SmartMIPS
> extension). So it can use CONFIG_CPU_MIPS32_R2 macro. But I was not
> aware of -march=4ksd and -march=mips32r2 differences. Maybe now it is
> needed to have a new CPU_4KSD definition ?

Configuration hacks that are specific to a single core create cruft and
maintenence problems.  As I said yesterday, I think we'd be much better
off to have a CONFIG_CPU_MIPS_SMALL or some such option
that could cause -Os to be used, allow branch-likelies, etc. The optimizations
under discussion aren't at all specific to the 4KSd, and I would think that
for every 4KSd embedded Linux platform there are several 4KEc platforms
that would benefit from a smaller kernel footprint.

It's Linux, and people can do what they want, but I'd prefer not to see more
core-specifc cruft work its way back into the linux-mips or kernel.org reference
trees.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > You could, but why not stick with -march=4ksd if that's your CPU of
> > choice? It appears to result in  marginally smaller code even when using
> > -Os, and should have (slightly) better performance than a generic
> > mips32r2 kernel?
> 
> Just to avoid a new CPU_4KSD definition in the kernel code as
> suggested by Kevin. Basically all mips32r2 specific code is the same
> as 4ksd specific code (except the code that deals with SmartMIPS
> extension). So it can use CONFIG_CPU_MIPS32_R2 macro. But I was not
> aware of -march=4ksd and -march=mips32r2 differences. Maybe now it is
> needed to have a new CPU_4KSD definition ?

Configuration hacks that are specific to a single core create cruft and
maintenence problems.  As I said yesterday, I think we'd be much better
off to have a CONFIG_CPU_MIPS_SMALL or some such option
that could cause -Os to be used, allow branch-likelies, etc. The optimizations
under discussion aren't at all specific to the 4KSd, and I would think that
for every 4KSd embedded Linux platform there are several 4KEc platforms
that would benefit from a smaller kernel footprint.

It's Linux, and people can do what they want, but I'd prefer not to see more
core-specifc cruft work its way back into the linux-mips or kernel.org reference
trees.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/27, Kevin D. Kissell <kevink@mips.com>:
> > > You could, but why not stick with -march=4ksd if that's your CPU of
> > > choice? It appears to result in  marginally smaller code even when using
> > > -Os, and should have (slightly) better performance than a generic
> > > mips32r2 kernel?
> >
> > Just to avoid a new CPU_4KSD definition in the kernel code as
> > suggested by Kevin. Basically all mips32r2 specific code is the same
> > as 4ksd specific code (except the code that deals with SmartMIPS
> > extension). So it can use CONFIG_CPU_MIPS32_R2 macro. But I was not
> > aware of -march=4ksd and -march=mips32r2 differences. Maybe now it is
> > needed to have a new CPU_4KSD definition ?
>
> Configuration hacks that are specific to a single core create cruft and
> maintenence problems.  As I said yesterday, I think we'd be much better
> off to have a CONFIG_CPU_MIPS_SMALL or some such option
> that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> under discussion aren't at all specific to the 4KSd,

no some are. As we said previously:

        1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
        2/ with -march=4ksd can do (slightly) better optimizations

> for every 4KSd embedded Linux platform there are several 4KEc platforms
> that would benefit from a smaller kernel footprint.
>

-Os can already be choosen by user in kernel configuration. Your
CONFIG_CPU_MIPS_SMALL option brings nothing more except that the user
is stuck with -Os option. BTW, I think it may be the default option in
the near future for mainline...

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Fri, Jan 27, 2006 at 11:13:44AM +0100, Kevin D. Kissell wrote:

> Configuration hacks that are specific to a single core create cruft and
> maintenence problems.  As I said yesterday, I think we'd be much better
> off to have a CONFIG_CPU_MIPS_SMALL or some such option
> that could cause -Os to be used, allow branch-likelies, etc.

There is already CONFIG_CC_OPTIMIZE_FOR_SIZE.

Unfortunately gcc has begun to avoid gcc totally since it was marked
"deprecated" in the architecture spec even though in the real world
branch likely often is a win.

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Fri, Jan 27, 2006 at 11:45:34AM +0100, Franck wrote:

> no some are. As we said previously:
> 
>         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
>         2/ with -march=4ksd can do (slightly) better optimizations
> 
> > for every 4KSd embedded Linux platform there are several 4KEc platforms
> > that would benefit from a smaller kernel footprint.
> >
> 
> -Os can already be choosen by user in kernel configuration. Your
> CONFIG_CPU_MIPS_SMALL option brings nothing more except that the user
> is stuck with -Os option. BTW, I think it may be the default option in
> the near future for mainline...

Not before demonstrating that it is a clear win under all circumstances.

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Configuration hacks that are specific to a single core create cruft and
> > maintenence problems.  As I said yesterday, I think we'd be much better
> > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > under discussion aren't at all specific to the 4KSd,
> 
> no some are. As we said previously:
> 
>         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
>         2/ with -march=4ksd can do (slightly) better optimizations.

This is very possibly due to the compiler knowing about the SmartMIPS
scaled, indexed load instructions, which were added to improve virtual
machine performance, but which also save on address calculation instructions.
If -march=mips32r2 combined with -msmartmips and -Os don't produce
pretty much the same result as -march=4ksd, I'd be interested in knowing
why. Regardless, if this is what's going on, there really is no other core 
in production today that will run that code.  But that doesn't mean
that there won't be others in the future.

All I'm really trying to do here is to get away from core-specific config
cruft.  If the best result under-the-hood for 4KSd is obtained by using 
-march=4ksd, that's what people should get, but I'd rather that users
and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather 
than a choice of 4KSd as a one-off.

        Regards,

        Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Configuration hacks that are specific to a single core create cruft and
> > maintenence problems.  As I said yesterday, I think we'd be much better
> > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > under discussion aren't at all specific to the 4KSd,
> 
> no some are. As we said previously:
> 
>         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
>         2/ with -march=4ksd can do (slightly) better optimizations.

This is very possibly due to the compiler knowing about the SmartMIPS
scaled, indexed load instructions, which were added to improve virtual
machine performance, but which also save on address calculation instructions.
If -march=mips32r2 combined with -msmartmips and -Os don't produce
pretty much the same result as -march=4ksd, I'd be interested in knowing
why. Regardless, if this is what's going on, there really is no other core 
in production today that will run that code.  But that doesn't mean
that there won't be others in the future.

All I'm really trying to do here is to get away from core-specific config
cruft.  If the best result under-the-hood for 4KSd is obtained by using 
-march=4ksd, that's what people should get, but I'd rather that users
and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather 
than a choice of 4KSd as a one-off.

        Regards,

        Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Nigel Stephens]

Franck wrote:

>2006/1/26, Nigel Stephens <nigel@mips.com>:
>  
>
>>You could, but why not stick with -march=4ksd if that's your CPU of
>>choice? It appears to result in  marginally smaller code even when using
>>-Os, and should have (slightly) better performance than a generic
>>mips32r2 kernel?
>>
>>    
>>
>
>Just to avoid a new CPU_4KSD definition in the kernel code as
>suggested by Kevin. Basically all mips32r2 specific code is the same
>as 4ksd specific code (except the code that deals with SmartMIPS
>extension). So it can use CONFIG_CPU_MIPS32_R2 macro.
>

Not that I'm a Linux hacker, but aren't those separate things? Can't you 
compile with -march=4ksd to get the CPU-specific compiler optimisations, 
but then use the more generic CONFIG_CPU_MIPSR2 and/or 
CONFIG_CPU_SMARTMIPS to select the appropriate code inside the kernel 
source (i.e. no need for CONFIG_CPU_4KSD)?

Nigel

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/27, Kevin D. Kissell <kevink@mips.com>:
> > > Configuration hacks that are specific to a single core create cruft and
> > > maintenence problems.  As I said yesterday, I think we'd be much better
> > > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > > under discussion aren't at all specific to the 4KSd,
> >
> > no some are. As we said previously:
> >
> >         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
> >         2/ with -march=4ksd can do (slightly) better optimizations.
>
> This is very possibly due to the compiler knowing about the SmartMIPS
> scaled, indexed load instructions, which were added to improve virtual
> machine performance, but which also save on address calculation instructions.
> If -march=mips32r2 combined with -msmartmips and -Os don't produce
> pretty much the same result as -march=4ksd, I'd be interested in knowing
> why.

well, Nigel gave us some answers here, no ? I'm not sure it's a good
idea to use -march=mips32r2 whatever the mips32r2 cpu is used. Even if
the gain is small, we should use a specific cpu description. If the
configuration makes it hard, it should be reworked, isn't it ?

> Regardless, if this is what's going on, there really is no other core
> in production today that will run that code.  But that doesn't mean
> that there won't be others in the future.
>
> All I'm really trying to do here is to get away from core-specific config
> cruft.  If the best result under-the-hood for 4KSd is obtained by using
> -march=4ksd, that's what people should get, but I'd rather that users
> and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather
> than a choice of 4KSd as a one-off.
>

Ok what about this patch. It allows to choose a specific cpu when
MIPS32R2 architecture is selected ?

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8b9002a..a6d168c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1290,6 +1302,30 @@ config SYS_HAS_CPU_RM9000
 config SYS_HAS_CPU_SB1
 	bool

+#
+# CPU model tuning.
+#
+choice
+	prompt "CPU model"
+	default CPU_GENERIC
+	help
+	  When configuring kernel building to MIPS32 architecture,
+	  whatever the release number, it can be interesting to narrow
+	  your choice for speed and size optimizations.
+
+config CPU_GENERIC
+	bool "Generic"
+	help
+	  It's safe to select this if your CPU model doesn't appear in the list.
+
+config CPU_4KSD
+	bool "4KSD"
+	depends on SYS_HAS_CPU_MIPS32_R2
+	help
+	  MIPS Technologies 4KSd-series processors.
+
+endchoice
+
 endmenu

 #
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index bc99c2d..c11df11 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -165,82 +167,92 @@ echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_
 #
 # CPU-dependent compiler/assembler options for optimization.
 #
-cflags-$(CONFIG_CPU_R3000)	+= \
+
+__cflags-$(CONFIG_CPU_R3000)	+= \
 			$(call set_gccflags,r3000,mips1,r3000,mips1,mips1)

-cflags-$(CONFIG_CPU_TX39XX)	+= \
+__cflags-$(CONFIG_CPU_TX39XX)	+= \
 			$(call set_gccflags,r3900,mips1,r3000,mips1,mips1)

-cflags-$(CONFIG_CPU_R6000)	+= \
+__cflags-$(CONFIG_CPU_R6000)	+= \
 			$(call set_gccflags,r6000,mips2,r6000,mips2,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_R4300)	+= \
+__cflags-$(CONFIG_CPU_R4300)	+= \
 			$(call set_gccflags,r4300,mips3,r4300,mips3,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_VR41XX)	+= \
+__cflags-$(CONFIG_CPU_VR41XX)	+= \
 			$(call set_gccflags,r4100,mips3,r4600,mips3,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_R4X00)	+= \
+__cflags-$(CONFIG_CPU_R4X00)	+= \
 			$(call set_gccflags,r4600,mips3,r4600,mips3,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_TX49XX)	+= \
+__cflags-$(CONFIG_CPU_TX49XX)	+= \
 			$(call set_gccflags,r4600,mips3,r4600,mips3,mips2)  \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_MIPS32_R1)	+= \
-			$(call set_gccflags,mips32,mips32,r4600,mips3,mips2) \
-			-Wa,--trap
-
-cflags-$(CONFIG_CPU_MIPS32_R2)	+= \
-			$(call set_gccflags,mips32r2,mips32r2,r4600,mips3,mips2) \
-			-Wa,--trap
-
-cflags-$(CONFIG_CPU_MIPS64_R1)	+= \
-			$(call set_gccflags,mips64,mips64,r4600,mips3,mips2) \
-			-Wa,--trap
-
-cflags-$(CONFIG_CPU_MIPS64_R2)	+= \
-			$(call set_gccflags,mips64r2,mips64r2,r4600,mips3,mips2) \
-			-Wa,--trap
-
-cflags-$(CONFIG_CPU_R5000)	+= \
+__cflags-$(CONFIG_CPU_R5000)	+= \
 			$(call set_gccflags,r5000,mips4,r5000,mips4,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_R5432)	+= \
+__cflags-$(CONFIG_CPU_R5432)	+= \
 			$(call set_gccflags,r5400,mips4,r5000,mips4,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_NEVADA)	+= \
+__cflags-$(CONFIG_CPU_NEVADA)	+= \
 			$(call set_gccflags,rm5200,mips4,r5000,mips4,mips2) \
 			-Wa,--trap
 #			$(call cc-option,-mmad)

-cflags-$(CONFIG_CPU_RM7000)	+= \
+__cflags-$(CONFIG_CPU_RM7000)	+= \
 			$(call set_gccflags,rm7000,mips4,r5000,mips4,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_RM9000)	+= \
+__cflags-$(CONFIG_CPU_RM9000)	+= \
 			$(call set_gccflags,rm9000,mips4,r5000,mips4,mips2) \
 			-Wa,--trap


-cflags-$(CONFIG_CPU_SB1)	+= \
+__cflags-$(CONFIG_CPU_SB1)	+= \
 			$(call set_gccflags,sb1,mips64,r5000,mips4,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_R8000)	+= \
+__cflags-$(CONFIG_CPU_R8000)	+= \
 			$(call set_gccflags,r8000,mips4,r8000,mips4,mips2) \
 			-Wa,--trap

-cflags-$(CONFIG_CPU_R10000)	+= \
+__cflags-$(CONFIG_CPU_R10000)	+= \
 			$(call set_gccflags,r10000,mips4,r8000,mips4,mips2) \
 			-Wa,--trap

+__cflags-$(CONFIG_CPU_4KSD)	+= \
+			$(call set_gccflags,4ksd,mips32r2,4kec,mips32r2) \
+			-Wa,--trap
+
+# Fallback options for MIPS32 architectures
+ifndef __cflags-y
+__cflags-$(CONFIG_CPU_MIPS32_R1)	+= \
+			$(call set_gccflags,mips32,mips32,r4600,mips3,mips2) \
+			-Wa,--trap
+
+__cflags-$(CONFIG_CPU_MIPS32_R2)	+= \
+			$(call set_gccflags,mips32r2,mips32r2,r4600,mips3,mips2) \
+			-Wa,--trap
+
+__cflags-$(CONFIG_CPU_MIPS64_R1)	+= \
+			$(call set_gccflags,mips64,mips64,r4600,mips3,mips2) \
+			-Wa,--trap
+
+__cflags-$(CONFIG_CPU_MIPS64_R2)	+= \
+			$(call set_gccflags,mips64r2,mips64r2,r4600,mips3,mips2) \
+			-Wa,--trap
+endif
+
+cflags-y	+= $(__cflags-y)
+
 ifdef CONFIG_CPU_SB1
 ifdef CONFIG_SB1_PASS_1_WORKAROUNDS
 MODFLAGS	+= -msb1-pass1-workarounds

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/27, Nigel Stephens <nigel@mips.com>:
>
> Not that I'm a Linux hacker, but aren't those separate things? Can't you
> compile with -march=4ksd to get the CPU-specific compiler optimisations,
> but then use the more generic CONFIG_CPU_MIPSR2 and/or
> CONFIG_CPU_SMARTMIPS to select the appropriate code inside the kernel
> source (i.e. no need for CONFIG_CPU_4KSD)?
>

To use -march=4ksd, you need to tell to the building process that
you're using a 4KSD cpu. The only way to do that is to define a new
CPU_4KSD. But, if I understood mips configuration script, you cannot
define CPU_4KSD _and_ CPU_MIPS32R2 at the same time; at least easily.

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Maciej W. Rozycki]

On Fri, 27 Jan 2006, Franck wrote:

> To use -march=4ksd, you need to tell to the building process that
> you're using a 4KSD cpu. The only way to do that is to define a new
> CPU_4KSD. But, if I understood mips configuration script, you cannot
> define CPU_4KSD _and_ CPU_MIPS32R2 at the same time; at least easily.

 You may still specify "-mtune=4ksd" at the command line.  This option is 
not going to be overridden as it's nowhere used in Makefiles.

  Maciej

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Not that I'm a Linux hacker, but aren't those separate things? Can't you
> > compile with -march=4ksd to get the CPU-specific compiler optimisations,
> > but then use the more generic CONFIG_CPU_MIPSR2 and/or
> > CONFIG_CPU_SMARTMIPS to select the appropriate code inside the kernel
> > source (i.e. no need for CONFIG_CPU_4KSD)?
> >
> 
> To use -march=4ksd, you need to tell to the building process that
> you're using a 4KSD cpu. The only way to do that is to define a new
> CPU_4KSD. But, if I understood mips configuration script, you cannot
> define CPU_4KSD _and_ CPU_MIPS32R2 at the same time; at least easily.

The point is not to set CPU_4KSD and CPU_MIPS32R2 at the same time,
the point is to not have to define CPU_4KSD *at all*, and use the combination
of MIPS32R2 and SMARTMIPS to drive the options, e.g.:

ifdef CONFIG_CPU_SMARTMIPS
cflags-$(CONFIG_CPU_MIPS32R1)   += \
                        $(call set_gccflags,mips32,smartmips,4kec,mips3,mips2)\
                        -Os, -Wa,--trap

cflags-$(CONFIG_CPU_MIPS32R2)   += \
                        $(call set_gccflags,4ksd,mips32r2,4kec,mips3,mips2) \
                        -Wa,--trap
else
cflags-$(CONFIG_CPU_MIPS32R1)   += \
                        $(call set_gccflags,mips32,mips32,r4600,mips3,mips2) \
                        -Wa,--trap

cflags-$(CONFIG_CPU_MIPS32R2)   += \
                        $(call set_gccflags,mips32r2,mips32r2,r4600,mips3,mips2)
 \
                        -Wa,--trap
endif


That's almost certainly not the cleanest way to do it (and I really don't know
if the values I threw in for the MIPS32R1+SmartMIPS (e.g. 4KSc) combination
would actually work.  I just want to point out that it isn't that hard to do.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Kevin D. Kissell]

> > Not that I'm a Linux hacker, but aren't those separate things? Can't you
> > compile with -march=4ksd to get the CPU-specific compiler optimisations,
> > but then use the more generic CONFIG_CPU_MIPSR2 and/or
> > CONFIG_CPU_SMARTMIPS to select the appropriate code inside the kernel
> > source (i.e. no need for CONFIG_CPU_4KSD)?
> >
> 
> To use -march=4ksd, you need to tell to the building process that
> you're using a 4KSD cpu. The only way to do that is to define a new
> CPU_4KSD. But, if I understood mips configuration script, you cannot
> define CPU_4KSD _and_ CPU_MIPS32R2 at the same time; at least easily.

The point is not to set CPU_4KSD and CPU_MIPS32R2 at the same time,
the point is to not have to define CPU_4KSD *at all*, and use the combination
of MIPS32R2 and SMARTMIPS to drive the options, e.g.:

ifdef CONFIG_CPU_SMARTMIPS
cflags-$(CONFIG_CPU_MIPS32R1)   += \
                        $(call set_gccflags,mips32,smartmips,4kec,mips3,mips2)\
                        -Os, -Wa,--trap

cflags-$(CONFIG_CPU_MIPS32R2)   += \
                        $(call set_gccflags,4ksd,mips32r2,4kec,mips3,mips2) \
                        -Wa,--trap
else
cflags-$(CONFIG_CPU_MIPS32R1)   += \
                        $(call set_gccflags,mips32,mips32,r4600,mips3,mips2) \
                        -Wa,--trap

cflags-$(CONFIG_CPU_MIPS32R2)   += \
                        $(call set_gccflags,mips32r2,mips32r2,r4600,mips3,mips2)
 \
                        -Wa,--trap
endif


That's almost certainly not the cleanest way to do it (and I really don't know
if the values I threw in for the MIPS32R1+SmartMIPS (e.g. 4KSc) combination
would actually work.  I just want to point out that it isn't that hard to do.

            Regards,

            Kevin K.

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/27, Kevin D. Kissell <kevink@mips.com>:
>
> ifdef CONFIG_CPU_SMARTMIPS
> cflags-$(CONFIG_CPU_MIPS32R1)   += \
>                         $(call set_gccflags,mips32,smartmips,4kec,mips3,mips2)\
>                         -Os, -Wa,--trap
>
> cflags-$(CONFIG_CPU_MIPS32R2)   += \
>                         $(call set_gccflags,4ksd,mips32r2,4kec,mips3,mips2) \
>                         -Wa,--trap
> else
> cflags-$(CONFIG_CPU_MIPS32R1)   += \
>                         $(call set_gccflags,mips32,mips32,r4600,mips3,mips2) \
>                         -Wa,--trap
>
> cflags-$(CONFIG_CPU_MIPS32R2)   += \
>                         $(call set_gccflags,mips32r2,mips32r2,r4600,mips3,mips2)
>  \
>                         -Wa,--trap
> endif
>
>
> That's almost certainly not the cleanest way to do it (and I really don't know
> if the values I threw in for the MIPS32R1+SmartMIPS (e.g. 4KSc) combination
> would actually work.  I just want to point out that it isn't that hard to do.

I agree it's not hard to do. But it becomes more tricky if you want
something clean that gives best results for every cpus...Moreover I
don't think your solution avoids maintenence problems IMHO.

Ralf, could you give your opinion ?

Thanks
--
               Franck

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Ralf Baechle]

On Fri, Jan 27, 2006 at 06:32:15PM +0100, Franck wrote:

> > ifdef CONFIG_CPU_SMARTMIPS
> > cflags-$(CONFIG_CPU_MIPS32R1)   += \
> >                         $(call set_gccflags,mips32,smartmips,4kec,mips3,mips2)\
> >                         -Os, -Wa,--trap

-Os has no business here.  That's what CONFIG_CC_OPTIMIZE_FOR_SIZE is for.

> > if the values I threw in for the MIPS32R1+SmartMIPS (e.g. 4KSc) combination
> > would actually work.  I just want to point out that it isn't that hard to do.
> 
> I agree it's not hard to do. But it becomes more tricky if you want
> something clean that gives best results for every cpus...Moreover I
> don't think your solution avoids maintenence problems IMHO.
> 
> Ralf, could you give your opinion ?

I think I'm going to start by throwing the insane option selection
complexity which was needed for support of gcc 2.95 ... 3.1; a few days
gcc 3.2 became the minimum required to build a 2.6 kernel, then see what
can nicely be implemented.

  Ralf

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Maciej W. Rozycki]

On Sun, 29 Jan 2006, Ralf Baechle wrote:

> I think I'm going to start by throwing the insane option selection
> complexity which was needed for support of gcc 2.95 ... 3.1; a few days
> gcc 3.2 became the minimum required to build a 2.6 kernel, then see what
> can nicely be implemented.

 Amen to that!

  Maciej

Re: [RFC] Optimize swab operations on mips_r2 cpu

[Franck]

2006/1/29, Ralf Baechle <ralf@linux-mips.org>:
> On Fri, Jan 27, 2006 at 06:32:15PM +0100, Franck wrote:
>
> > > ifdef CONFIG_CPU_SMARTMIPS
> > > cflags-$(CONFIG_CPU_MIPS32R1)   += \
> > >                         $(call set_gccflags,mips32,smartmips,4kec,mips3,mips2)\
> > >                         -Os, -Wa,--trap
>
> -Os has no business here.  That's what CONFIG_CC_OPTIMIZE_FOR_SIZE is for.
>
> > > if the values I threw in for the MIPS32R1+SmartMIPS (e.g. 4KSc) combination
> > > would actually work.  I just want to point out that it isn't that hard to do.
> >
> > I agree it's not hard to do. But it becomes more tricky if you want
> > something clean that gives best results for every cpus...Moreover I
> > don't think your solution avoids maintenence problems IMHO.
> >
> > Ralf, could you give your opinion ?
>
> I think I'm going to start by throwing the insane option selection
> complexity which was needed for support of gcc 2.95 ... 3.1; a few days
> gcc 3.2 became the minimum required to build a 2.6 kernel, then see what
> can nicely be implemented.

Could you keep me informed on this ? When are you planning to start it ?

Thanks
--
               Franck