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