assemblyarmbit-shiftcarryflagstatus-register

what is the carry-out from the shifter of ARM CPU


I'm reading 'ARM Architecture Reference Manual' to write a Game Boy Advance emulator which has an ARM7TDMI CPU. I'm not familiar with ARM architecture. The manual mentions 'the carry-out from the shifter'.

The < shifter_operand > value is formed by rotating (to the right) an 8-bit immediate value to any even bit position in a 32-bit word. If the rotate immediate is zero, the carry-out from the shifter is the value of the C flag, otherwise, it is set to bit[31] of the value of < shifter_operand > .

What is that? What is it used for? Do I need to implement it? Are there any relations between the C flag of CPSR and 'the carry-out from the shifter'?


Solution

  • Other quotes from the ARM ARM some near your quote.

    As well as producing the shifter operand, the shifter produces a carry-out which some instructions write into the Carry Flag.

    ...

    Data-processing operands - Immediate

    and a diagram that shows 27:25 = 0b001, 11:8 is rotate_imm and 7:0 is immed_8

    The shifter_operand value is formed by rotating (to the right) an 8-bit immediate value to any even bit position in a 32-bit word. If the rotate immediate is zero, the carry-out from the shifter is the value of the C flag, otherwise, it is set to bit[31] of the value of <shifter_operand>.

    Think about what instructions would want to rotate but are not driving the Carry flag, ADD is not one of them for example

    C Flag = CarryFrom(Rn + shifter_operand)

    But MOV would be a prime candidate

    C Flag = shifter_carry_out

    So if the rotate_imm is zero which means the immediate is between 0x00000000 and 0x000000FF right? Then shifter_carry_out is the C flag, basically the C flag doesn't change or get updated. But if the rotate_imm is non-zero then the shifter_carry_out comes from bit 31 of the resulting shift which for the MOV instruction (and perhaps some others)(with the S bit set) becomes the new C flag.

    Not vague at all, quite clearly documented.

    Note there are many documented and undocumented gems like this that are used to see if a clone is indeed a clone and/or is stolen IP. There weren't that many clones that made it AFAIK. google picoturbo And to make it you needed to be an accurate clone and get all of these instructions right including the UNPREDICTABLE RESULTS ones of which some were predictable.

    ARM released the Armulator source code years ago, basically the code that made ARM, the logic had to match armulator. And we can take and use that and one would assume are legally free to do so based on the license. QEMU has an instruction set simulator out there and there are some others, so while dancing around legal language to make a simulator and possibly publish it in some form (some ARM docs specifically call this out), they so far have allowed those to exist. But certainly don't try to turn this into a clone in logic for yourself or to sell/publish.

    So you can try this against hardware but you are further dancing on the fringes of legality. Don't think you need to as your quote is covered within that same document.