Patchwork [0/1] MIPS/MIPS32 tune -> MIPS

login
register
mail settings
Submitter Mark Hatle
Date April 9, 2012, 11:31 p.m.
Message ID <cover.1334014014.git.mark.hatle@windriver.com>
Download mbox
Permalink /patch/25481/
State New
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib mhatle/mips-tune

Comments

Mark Hatle - April 9, 2012, 11:31 p.m.
The following is in reference to the recent discussion about the mips32
-package- arch changing from mips to mips32.  One of the potential options
was to get rid of the previous "mips" and replace it with the mips32
definition standard.  This patch does just that.

Working with Khem, we have moved the default "mips" (32-bit) tune to be
-march=mips32 based, and produce package with the package arch of "mips".

The side effect of this work is that the prior 'mips' tune was actually
"mips1".  I don't believe that was really desired by anyone, but it is a
change.  Also there is no longer a "mips32" tune, just an include file
that automatically inherits and chooses the "mips" tune.

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib mhatle/mips-tune
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/mips-tune

Mark Hatle (1):
  tune-mips32: Update the default MIPS tuning to be mips32

 meta/conf/machine/include/mips/arch-mips.inc |   13 +++++++++----
 meta/conf/machine/include/tune-mips32.inc    |   24 +-----------------------
 2 files changed, 10 insertions(+), 27 deletions(-)
Andreas Oberritter - April 10, 2012, 12:14 a.m.
On 10.04.2012 01:31, Mark Hatle wrote:
> The following is in reference to the recent discussion about the mips32
> -package- arch changing from mips to mips32.  One of the potential options
> was to get rid of the previous "mips" and replace it with the mips32
> definition standard.  This patch does just that.
> 
> Working with Khem, we have moved the default "mips" (32-bit) tune to be
> -march=mips32 based, and produce package with the package arch of "mips".
> 
> The side effect of this work is that the prior 'mips' tune was actually
> "mips1".  I don't believe that was really desired by anyone, but it is a
> change.  Also there is no longer a "mips32" tune, just an include file
> that automatically inherits and chooses the "mips" tune.

There's no backwards compatibility, but I'm fine with the new options.
The "mips" tune already gets selected by default in arch-mips.inc, so
you can remove it from tune-mips32.inc. Actually I'd prefer removing
tune-mips32.inc completely, so people will notice the
backwards-incompatible change.

Regards,
Andreas
Mark Hatle - April 10, 2012, 12:20 a.m.
On 4/9/12 7:14 PM, Andreas Oberritter wrote:
> On 10.04.2012 01:31, Mark Hatle wrote:
>> The following is in reference to the recent discussion about the mips32
>> -package- arch changing from mips to mips32.  One of the potential options
>> was to get rid of the previous "mips" and replace it with the mips32
>> definition standard.  This patch does just that.
>>
>> Working with Khem, we have moved the default "mips" (32-bit) tune to be
>> -march=mips32 based, and produce package with the package arch of "mips".
>>
>> The side effect of this work is that the prior 'mips' tune was actually
>> "mips1".  I don't believe that was really desired by anyone, but it is a
>> change.  Also there is no longer a "mips32" tune, just an include file
>> that automatically inherits and chooses the "mips" tune.
>
> There's no backwards compatibility, but I'm fine with the new options.
> The "mips" tune already gets selected by default in arch-mips.inc, so
> you can remove it from tune-mips32.inc. Actually I'd prefer removing
> tune-mips32.inc completely, so people will notice the
> backwards-incompatible change.

This is backwards compatible if someone was previously including the mips32 
tune.  It only "breaks" if someone was setting the default tune to "mips32" or 
"mips32el" manually.

If that is a concern, then adding a:

TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips}"
MIPSPKGSFX_VARIANT_tune-mips32 = "${MIPSPKGSFX_VARIANT_tune-mips}"
PACKAGE_EXTRA_ARCHS_tune-mips32 = "${PACKAGE_EXTRA_ARCHS_tune-mips}"

(and the same for mips32el).  That would ensure that they remain the same, and 
that the package arch of "mips" can't deviate.

--Mark

> Regards,
> Andreas