| To: | Nigel Stephens <nigel@mips.com> |
|---|---|
| Subject: | Re: Strange instruction |
| From: | Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> |
| Date: | Thu, 14 Oct 2004 14:36:15 +0200 |
| Cc: | "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org |
| In-reply-to: | <416E6E32.5080009@mips.com> |
| 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> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.5.6i |
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. 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. Thiemo |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Strange instruction, Nigel Stephens |
|---|---|
| Next by Date: | Re: Strange instruction, Kevin D. Kissell |
| Previous by Thread: | Re: Strange instruction, Nigel Stephens |
| Next by Thread: | Re: Strange instruction, Kevin D. Kissell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |