• State Accepted Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 349 subscribers
  • Views 6161 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

The madman strikes again - ADD/SUB SP

Juha Aaltonen

Is there something special in the instructions ADD (SP plus register, ARM) and SUB (SP minus register)?

I didn't find anything different from the basic ADD  (register) and SUB (register) except the documentation:

<Rd> The destination register. If S is specified and <Rd> is the PC, see SUBS PC, LR and related

instructions (ARM) on page B9-2012. This register can be SP. If omitted, <Rd> is SP. This register

can be the PC, but ARM deprecates using the PC.

If S is not specified and <Rd> is the PC, the instruction is a branch to the address calculated by the

operation. This is an interworking branch, see Pseudocode details of operations on ARM core

registers on page A2-47. ARM deprecates this use of the PC.

Yet in the pseudocode:

(result, carry, overflow) = AddWithCarry(SP, shifted, ‘0’);

if d == 15 then

ALUWritePC(result); // setflags is always FALSE here

And nothing in the errata.

If Rd is PC, then the result is written into SP, and the program jumps to the address?

With any other register (than PC) as Rd, the Rd is ignored and the result is written into SP?

  • 0

    Hello,

    I cannot understand what your question is.

    "ADD/SUB SP" have anything different from the basic ADD  (register) and SUB (register) INCLUDING the documentation.

    The reason why these instruction are listed would be for Thumb encoding.

    In the ARM case, it is not special encoding.

    What is the concerning point?

    Best regards,

    Yasuhiko Koumoto.

  • 0

    Hello again,

    do you say about the <Rd> description "If omitted, <Rd> is SP"?

    It mentions only the assembler syntax.

    That is,

    ADD SP,#4

    is the same as

    ADD  SP,SP,#4.

    If Rd is PC, then the result is written into SP, and the program jumps to the address?

    With any other register (than PC) as Rd, the Rd is ignored and the result is written into SP?

    Regarding the above your comments, I cannot find any back ground.

    Are there any misunderstanding?

    Best regards,

    Yasuhiko Koumoto.

  • 0 in reply to Yasuhiko Koumoto

    If it wasn't ARM, I'd suspect error in the documentation, but I've learned that with ARM, everything is possible.

    Oops, it was always SP that is added to Rm and the result is written to Rd. That makes sense.

    There was a misunderstanding - or mis-reading. New pair of glasses don't fix this problem. ;-)

    The question still remains, why is it specifically documented.

    I copied the description here (bolding is mine):

    A8.8.11      ADD (SP plus register, ARM)
                        This instruction adds an optionally-shifted register value to the SP value, and writes the result to the destination
                        register.
                        Encoding A1         ARMv4*, ARMv5T*, ARMv6*, ARMv7
                        ADD{S}<c> <Rd>, SP, <Rm>{, <shift>}
                         31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
                            cond  0 0 0 0 1 0 0 S 1 1 0 1            Rd      imm5type 0  Rm
                        For the case when cond is 0b1111, see Unconditional instructions on page A5-216.
                        if Rd == '1111' && S == '1' then SEE SUBS PC, LR and related instructions;
                        d = UInt(Rd); m = UInt(Rm); setflags = (S == '1');
                        (shift_t, shift_n) = DecodeImmShift(type, imm5);
                  Assembler syntax
                  ADD{S}{<c>}{<q>}{<Rd>,} SP, <Rm>{, <shift>}
                  where:
                  S           If S is present, the instruction updates the flags. Otherwise, the flags are not updated.
                  <c>, <q>    See Standard assembler syntax fields on page A8-287.
                  <Rd>        The destination register. If S is specified and <Rd> is the PC, see SUBS PC, LR and related
                                  instructions (ARM) on page B9-2012. This register can be SP. If omitted, <Rd> is SP. This register
                                  can be the PC, but ARM deprecates using the PC.
                                  If S is not specified and <Rd> is the PC, the instruction is a branch to the address calculated by the
                                  operation. This is an interworking branch, see Pseudocode details of operations on ARM core
                                  registers on page A2-47. ARM deprecates this use of the PC.
                                           Note
                                  Before ARMv7, this was a simple branch.
                  <Rm>        The register that is optionally shifted and used as the second operand. This register can be the PC,
                                  but ARM deprecates using the PC. This register can be the SP, but ARM deprecates using the SP.
                  <shift>     The shift to apply to the value read from <Rm>. If omitted, no shift is applied and any encoding is
                                  permitted. Shifts applied to a register on page A8-291 describes the shifts and how they are
                                  encoded.
                  The pre-UAL syntax ADD<c>S is equivalent to ADDS<c>.
                  Operation
                  if ConditionPassed() then
                      EncodingSpecificOperations();
                      shifted = Shift(R[m], shift_t, shift_n, APSR.C);
                      (result, carry, overflow) = AddWithCarry(SP, shifted, '0');
                      if d == 15 then
                           ALUWritePC(result); // setflags is always FALSE here
                      else
                           R[d] = result;
                           if setflags then
                               APSR.N = result<31>;
                               APSR.Z = IsZeroBit(result);
                               APSR.C = carry;
                               APSR.V = overflow;
                  Exceptions
                  None.
  • 0 in reply to Juha Aaltonen

    Hello.

    The question still remains, why is it specifically documented.

    It would be because why the descriptions would relate between ARM and Thumb instructions for one by one.

    ARM instructions would be almost symmetric but Thumb instruction is asymmetric.

    However, in the specification document, ARM want to describe their instructions such as ARM and Thumb are equivalent.

    Best regards,

    Yasuhiko Koumoto.

  • 0 in reply to Yasuhiko Koumoto

    So, if there is a special description for Thumb instruction, there is a special description for ARM instruction too

    whether really needed or not? Just for symmetry in documentation?

  • 0 in reply to Juha Aaltonen

    My personal opinion is that ARM and Thumb should be described separately.

    Current style has too many information.

    Probably ARM wants to share the explanation of an instruction behavior.

    Best regards,

    Yasuhiko Koumoto.

  • 0 in reply to Yasuhiko Koumoto

    My personal opinion is that ARM and Thumb should be described separately.

    I agree.

  • 0 Arm Employee Badge in reply to Juha Aaltonen

    Hi turboscrew,

    Symmetry of documentation is probably the reason - documenting the strange Thumb encoding and not specifying an ARM encoding for the exact same operation (even if ADD{S} covers it with r13 as Rn) means it isn't 100% obvious as to why that extra Thumb instruction exists. It also has some very, very specific behaviour when PC is Rd which bears documenting - even though it's deprecated to use that behaviour. Most of the uses regarding the PC are all to do with using the stack as a dynamic veneer/trampoline. ADDS PC, SP, RX makes very little sense, but there are some very interesting exception return possibilities from System mode possible, for example (an OS causing the next BX LR to execute code from the stack..). Using the SP like this got almost blanket deprecated in later versions of the Architecture (see the end of the ARM ARM, section D9.3) because there are better ways to do it, or no way of encoding them as a Thumb instruction - they're essentially concessions to UAL with extra cleaning power for the instruction set definition

    Ta,

    Matt

  • 0 in reply to Matt Sealey

    Yes, I have noticed the abundance (an understatement) of ways of returning from an exception.