All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Nigel Stephens" <nigel@mips.com>,
	"Thiemo Seufer" <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: <linux-mips@linux-mips.org>
Subject: Re: Strange instruction
Date: Thu, 14 Oct 2004 15:12:13 +0200	[thread overview]
Message-ID: <00ae01c4b1ef$6ca4b450$10eca8c0@grendel> (raw)
In-Reply-To: 20041014123615.GB1398@rembrandt.csv.ica.uni-stuttgart.de

> Nigel Stephens wrote:
> > Thiemo Seufer wrote:
> > >GNU as has "move" as builtin macro which is expanded differently for
> > >32 and 64 bit mode. This simplifies the task of writing code for both
> > >models. Unfortunately the expansion was broken for a while and
> > >generated always the 64 bit version if the toolchain was 64bit
> > >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> > 
> > Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> > generate "or $rd,$0,$rs", since that will work correctly in either mode?
> 
> For CPUs with two adders the instruction scheduling is a bit better.

For CPUs with two adders, only one of which can do ORs, you mean.
Isn't that a pretty small population of MIPS CPUs?

> Ther are also many other macros which are expanded in dependence of
> the 32/64 bit address/register size, a different "move" macro
> expansion won't help much if the assembler invocation was wrong.

Perhaps, but it strikes me as being only prudent to remove unnecessarily
fragile artifacts like this.  I'm sure that there are some macros that cannot
be implemented in a 32/64-bit independent manner, but it's clear that some
of them could be, but are not. And those that can be, should be, as a matter 
of software engineering principle.  Now, finding the time/money to actually 
do the work may be another story...  ;o)

            Regards,

            Kevin K. 

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Nigel Stephens <nigel@mips.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Strange instruction
Date: Thu, 14 Oct 2004 15:12:13 +0200	[thread overview]
Message-ID: <00ae01c4b1ef$6ca4b450$10eca8c0@grendel> (raw)
Message-ID: <20041014131213.9D5507XZw1E4H3BDQjBS2Ty9MoN5iq-vdBCQTjgXHbk@z> (raw)
In-Reply-To: 20041014123615.GB1398@rembrandt.csv.ica.uni-stuttgart.de

> Nigel Stephens wrote:
> > Thiemo Seufer wrote:
> > >GNU as has "move" as builtin macro which is expanded differently for
> > >32 and 64 bit mode. This simplifies the task of writing code for both
> > >models. Unfortunately the expansion was broken for a while and
> > >generated always the 64 bit version if the toolchain was 64bit
> > >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> > 
> > Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> > generate "or $rd,$0,$rs", since that will work correctly in either mode?
> 
> For CPUs with two adders the instruction scheduling is a bit better.

For CPUs with two adders, only one of which can do ORs, you mean.
Isn't that a pretty small population of MIPS CPUs?

> Ther are also many other macros which are expanded in dependence of
> the 32/64 bit address/register size, a different "move" macro
> expansion won't help much if the assembler invocation was wrong.

Perhaps, but it strikes me as being only prudent to remove unnecessarily
fragile artifacts like this.  I'm sure that there are some macros that cannot
be implemented in a 32/64-bit independent manner, but it's clear that some
of them could be, but are not. And those that can be, should be, as a matter 
of software engineering principle.  Now, finding the time/money to actually 
do the work may be another story...  ;o)

            Regards,

            Kevin K. 

  reply	other threads:[~2004-10-14 13:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-14 11:53 Strange instruction Dmitriy Tochansky
2004-10-14  8:34 ` Kevin D. Kissell
2004-10-14  8:34   ` Kevin D. Kissell
2004-10-14 12:12   ` Thiemo Seufer
2004-10-14 12:16     ` Nigel Stephens
2004-10-14 12:36       ` Thiemo Seufer
2004-10-14 13:12         ` Kevin D. Kissell [this message]
2004-10-14 13:12           ` Kevin D. Kissell
2004-10-14 13:34           ` Thiemo Seufer
2004-10-14  8:45 ` Fuxin Zhang
     [not found]   ` <000b01c4b1da$6e049f00$10eca8c0@grendel>
     [not found]     ` <416E5B62.8050508@ict.ac.cn>
2004-10-14 11:13       ` Kevin D. Kissell
2004-10-14 11:13         ` Kevin D. Kissell
2004-10-14 13:45 ` Dan Malek
2004-10-14 19:06   ` Dan Malek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00ae01c4b1ef$6ca4b450$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=ica2_ts@csv.ica.uni-stuttgart.de \
    --cc=linux-mips@linux-mips.org \
    --cc=nigel@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.