SHR SHL question

[CJ]

when shifing data in assembly, what is written to c, the last bit shifted off the 32 bit workspace or the first bit?

say you have %0100 and shift it right 3 bits, what would be written to c?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

[SSteve]

It looks to me like C doesn't get written by shr or shl. I hooked an LED up to A0 and wrote the attached code. The LED will blink slowly if C is set and quickly if C is not set. When I run this program, the LED blinks quickly, suggesting that C is not set.

I'm not 100% confident, though. It seems like C should get shifted into. Experiment with it and see if you get the same results.

Don't forget that you have to append WC to the line when you want C to be updated.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

[cgracey]

For all shift instructions (ROR/ROL/SHR/SHL/RCR/RCL/SAR/REV D,S) either the initial LSB or MSB of D can be written to the C flag. You must use·a 'wc' after the operands to affect C:

······· ROR·· A,#3····wc············ 'rotate A right by three bits,·old bit 0 of A into C flag
········SHL·· A,#1····wc············ 'shift A left by one bit,·old bit·31 of A into C flag
······· SAR·· A,B· ····wc············ 'shift arithmetic A right by B bits,·old bit 0 of A into C flag

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

[SSteve]

So it doesn't matter how many bits D is shifted by, C always gets the original bit 0 (or bit 31) of D?

Can you take a look at the CarryInAsm.spin program I posted? I can't figure out why the "if_c" line is never executed. If I change it to "if_nc", it is always executed. I tried all kinds of combinations of shl/shr/ror/rol and different values for test_value. Edit: Never mind. Please take a look at this thread instead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Post Edited (SSteve) : 6/1/2006 8:21:19 AM GMT

[Phil Pilgrim (PhiPi)]

Chip,

It's easy to understand why this carry behavior might cause confusion. I think the natural inclination among assembly programmers is that a shift of n followed by a shift of m would be equivalent to a shift of m+n in all respects:

      shl     dest, #5
      shl     dest, #4    wc

is expected to be equivalent to

      shl     dest, #9    wc

This is particularly vexing/confusing as it pertains to RCL and RCR. In fact, now I'm having difficulty understanding what's going on with these two instructions. Usually, rotates such as these include the carry bit in a circular shift. In the Propeller's case this would amount to a 33-bit circular register that gets rotated by the specified number of bits, leaving the last bit shifted into the carry intact. This is important because, including the carry, no bits get lost, and the instruction can be used for packing and unpacking data. (This would really come in handy in conjuction with MOVI and MOVS for packing bytes, since one extra bit could be "protected" in the carry from the 9-bit moves.)

So I'm wondering if maybe you could shed more light on the behavior of RCL and RCR and, perhaps, let us in on the reasoning behind choosing a "first-shift" behavior for the carry as opposed to the expected "last-shift" behavior.

Thanks,
Phil