Patch to implement rotates by zero

cgd@broadcom.com cgd@broadcom.com
Sat Aug 17 23:40:00 GMT 2002


At 17 Aug 2002 22:41:31 +0100, Richard Sandiford wrote:
> > > Likewise
> > > "rol" and "ror" will use "sll" to give the correct sign extension
> > > on 64-bit targets.
> > 
> > Uh, this one makes less sense to me.
> > 
> > AFAIK, 'sll' w/ a shift of 0 is only guaranteed to sign-extend by
> > MIPS64.  I've seen no previous documentation that defined that it must
> > work that way.
> 
> Damn.  Really?  Showing my ignorance here. ;)

I perhaps should have been more clear: sll with any shift is
guaranteed by mips64 to sign-extend.

before mips64, AFAIK, it was implementation-dependent or
"unpredictable."  I don't know for sure, but would expect, that a
sign-extended input would produce a properly sign-extended output.

I.e., it's only a question for non-sign-extended input.  providing
non-sign-extended input to most 32-bits ops on a 64-bit processor
these days (MIPS64) invokes "UNPREDICTABLE" behaviour.  (sll is one
exception.)

I think it's safe to say that providing non-sign-extended input to a
'rol' or 'ror' macro would also safely produce 'unpredictable'
behaviour.

> The non-MIPS64 processors I'm working with guarantee it too, but
> looking back at the manuals, it does seem that they go out of
> their way to say so.  Hmm...
> 
> How about srl?

srl (and sra) are UNPREDICTABLE if input isn't sign-extended in
MIPS64.


Really, i think it's just safe to generally implement as sll / srl /
or.

(the sll will properly sign-extend on valid inputs, the srl should
DTRT as well, and since bit 31 comes from the result of the sll the
final result should be OK.)


> > I dunno, from a consistency standpoint, it would make sense to simply
> > remove the check for the count being non-zero.  i.e. if you ask for
> > rol/rot/etc. and get the macro, you always end up with a 3-instruction
> > sequence being generated.
> 
> Wouldn't the effect be the same?  The sequence would still include
> a sll of zero.  Like you say, if shifts by zero aren't always
> well-defined, it does seem consistent from one POV.

the end effect would be same.  ((d)sll by 0, (d)srl by 0 ... you get
the same result from each, and or them together.)

it just makes the binutils code simpler.  People who do rotate by 0
and expect an optimization should lose.  it wouldn't happen if they
had real rotate instructions (i.e., they'd get an actual instruction).
So, they might as well get the 'normal' rotate macro expansion.



cgd



More information about the Binutils mailing list