linux-mips
[Top] [All Lists]

Re: Strange instruction

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Strange instruction
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Date: Thu, 14 Oct 2004 15:34:57 +0200
Cc: Nigel Stephens <nigel@mips.com>, linux-mips@linux-mips.org
In-reply-to: <00ae01c4b1ef$6ca4b450$10eca8c0@grendel>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20041014115304.3edbe141.toch@dfpost.ru> <01d901c4b1c8$996b7b30$10eca8c0@grendel> <20041014121242.GA1398@rembrandt.csv.ica.uni-stuttgart.de> <416E6E32.5080009@mips.com> <20041014123615.GB1398@rembrandt.csv.ica.uni-stuttgart.de> <00ae01c4b1ef$6ca4b450$10eca8c0@grendel>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.6i
Kevin D. Kissell wrote:
> > 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.

Yes.

> Isn't that a pretty small population of MIPS CPUs?

Sure, but there's little reason to deny this optimization.

> > 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.

It was an assembler bug.


Thiemo

<Prev in Thread] Current Thread [Next in Thread>