Segher Boessenkool [off-list ref] writes:

On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote:

quoted

Segher Boessenkool [off-list ref] writes:

quoted

On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:

quoted

+	clrldi	r6,r4,(64-12)	// r6 = r4 & 0xfff

You can just write
  rlwinm r6,r4,0,0x0fff

quoted

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.

quoted

Would be nice if the assembler could support:

	andi	r6, r4, 0x0fff

And turn it into the rlwinm, or rldicl :)

The extended mnemonics are *simple*, *one-to-one* mappings.

It would still be simple and 1:1, but would only be valid for certain
constants :)

Having "andi. 6,4,0x0f0f" a valid insn, but an extended mnemonic "andi 6,4,0x0f0f"
that is not (and the other way around for say 0xff0000ff) would violate that.

I agree that's a bit of a foot gun.

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.

The assembler could print a nice error saying you need to use a
contiguous mask. And I mean how often do you andi. with a mask that
isn't contiguous?

You could do some assembler macro, that can also expand to multiple insns
where that is useful.  Also one for loading constants, etc.  The downside
to that is you often do care how many insns are generated.

Instead you could do a macro for only those cases that can be done with *one*
insn.  But that then is pretty restricted in use, and people have to learn
what values are valid.

I don't see a perfect solution.

Yeah, I guess a new `andi` instruction is the only real answer :)

cheers