On Tue, Mar 26, 2019 at 08:18:07PM +1100, Michael Ellerman wrote:
> Segher Boessenkool <seg...@kernel.crashing.org> writes:
> > On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote:
> >> Segher Boessenkool <seg...@kernel.crashing.org> writes:
> >> > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
> >> >> + clrldi r6,r4,(64-12) // r6 = r4 & 0xfff
> >> >
> >> > You can just write
> >> > rlwinm r6,r4,0,0x0fff
> >>
> >> > if that is clearer? Or do you still want a comment with that :-)
> >>
> >> I don't think it's clearer doing a rotate of zero bits :)
> >>
> >> And yeah I'd probably still leave the comment, so I'm inclined to stick
> >> with the clrldi?
> >
> > I always have to think what the clrldi etc. do exactly, while with rlwinm
> > it is obvious. But yeah this may be different for other people who are
> > used to different idiom.
>
> Interesting, I'm the opposite. You know ppc assembler better than me so
> I guess I just need to spend more time on it and embrace the zen of the
> rotate instructions.
There is only one rlwinm instruction, but there are 9 extended mnemonics
for it. (And similarly for the 64-bit ops, where there are 3 basic
mnemonics but 9 extended mnemonics). Of course I use {s,rot}{l,r}{w,d}i,
those are actually *simpler* than rlwinm / rldic{,l,r}, but not the other
stuff.
It may also be because the disassembler doesn't show these things. Dunno.
> I'm not sure it's vastly more hostile though than `andi. 6,4,0xffff`
> being valid but `andi. 6,4,0x1ffff` being not valid.
But that is the same for *all* UIMM insns.
> Yeah, I guess a new `andi` instruction is the only real answer :)
Too bad there is no space in the opcode map for it, already not in the
original POWER architecture (where this is "andil.") :-/
Segher
