ASR #32

Long shift is easy; I've prepared a document about it (which is in the queue to being published; I just need to finish the ones before that one first).

-Starting from the msb end, it goes something like ... [A/L]SRS : RRX : RRX : RRX : RRX : ... : RRX

Notice: The condition codes do not need to be updated by RRX!

If you need to shift by larger amounts than just 1, then it's a good idea to use LSR and BFI only; this means you'll need to start from the lsb end.

Now that I've been going through the instructions in case PC is used as the destination I realize that about half of the instructions look like once-in-a-lifetime instructions.

I've found good use for them on a Cortex-M, for instance the ADD, where PC is the destination.

This can be used to synchronize an interrupt to a Timer Counter on the exact clock cycle (and daith mentions a couple of other use cases too).

-If you're in a situation, where every clock cycle is important (this usually happens when you need your device to run on very low frequencies in order to save power - or when you need to do high-speed I/O on a device), then it's important to have the "strange options", where you can find a solution to an otherwise unsolvable problem.

Long shift is easy; I've prepared a document about it (which is in the queue to being published; I just need to finish the ones before that one first).

-Starting from the msb end, it goes something like ... [A/L]SRS : RRX : RRX : RRX : RRX : ... : RRX

Notice: The condition codes do not need to be updated by RRX!

If you need to shift by larger amounts than just 1, then it's a good idea to use LSR and BFI only; this means you'll need to start from the lsb end.

Now that I've been going through the instructions in case PC is used as the destination I realize that about half of the instructions look like once-in-a-lifetime instructions.

I've found good use for them on a Cortex-M, for instance the ADD, where PC is the destination.

This can be used to synchronize an interrupt to a Timer Counter on the exact clock cycle (and daith mentions a couple of other use cases too).

-If you're in a situation, where every clock cycle is important (this usually happens when you need your device to run on very low frequencies in order to save power - or when you need to do high-speed I/O on a device), then it's important to have the "strange options", where you can find a solution to an otherwise unsolvable problem.

Starting from the msb end, it goes something like ... [A/L]SRS : RRX : RRX : RRX : RRX : ... : RRX

That's what I thought - longer shifts won't work.

BTW, nice post (the Cortex-M0 tricks).

I was rather thinking about uqadd16, uxtab, qdadd, and the like.

Not used in every program.

Well I was thinking of something simple like testing the top two bits of a register. (I haven't tested this)

     MOVS   r0, r1, ASR #31

     BHI      starts_11     ; Z clear C set

     BMI     starts_10

     BCS     starts_01

     ...          starts_00

using MVNS you can test for 01 first.

p.s. I don't think this sort of thing makes for happy colleagues though it might ensure a living for years to come.

That definitely qualifies for a cool trick. If you want to avoid branching, you could combine it with the sbcs instruction like SBCS r3,r3,r3 after a BMI.

(or of course use conditional execution). Using it as a mask for a conditional AND would probably also be useful.

... MVNS r0,r1,asr#31 might also prove useful, if you need to invert the sign.