Title: arm and thumb instruction set
Tags: arm
Question: How to differentiate arm instruction and thumb instruction? For example:

```add r1, r2, r3 ;add r2 and r3, then store the result in r1 register
```

How does the above instruction work in terms of arm and thumb instruction?

Comment: Are you asking how they are different?  Or if they are different?  Or how they do the addition?  Your actual question is not clear to me. :-)


Here is another answer: Well go to infocenter.arm.com and get the architectural reference manual for the architecture in question, or just get the ARMv7 manual (not the -M but the -A or -R) which will include all instruction codings to date from ARMv4 to ARMv7 including thumb and the most mature thumb2 extensions. (you might need multiple architectural reference manuals and/or technical reference manuals as the encoding of instructions is hit or miss in the arm manuals)

Under thumb instructions look at the register based ADD instruction, there is one encoding with three registers Encoding T1 which is listed as all thumb variants (ARMv4T to the present(ARMv4T, ARMv5, ARMv6, ARMv7 and likely ARMv8))

bits 15 to 9 are 0b0001100 three bits of rm, three bits of rn and three bits of rd (typically thumb instructions are limited to r0-r7 needing three bits to encode, thumb2 extensions and a few special thumb instructions allow higher numbered registers (four bits of encoding)).

The instruction is listed as ADDS rd,rn,rm in the description, the S means save flags which is from the parent ARM instruction from which the thumb instruction was derived, for ARM instructions you have the choice to modify flags or not, thumb instructions you do not (thumb2 has a way to control this but it has limitations (for the add instruction)).

ADDS rd,rn,rm

0001100 rm rn rd

So ADDS r1,r2,r3  would be this chunk of bits

0001100 011 010 001 = 0001100011010001 = 0001 1000 1101 0001 = 0x18D1

looking at the ADD instruction in ARM mode you start with a condition field, as you have written your question this is an ALWAYS or a 1110 pattern (always execute) also as you have written your question you wrote add not adds so not saving flags so the s bit is zero in the encoding 

so add rd,rn,shifter operand we start off with the bit pattern 0b111000I01000 then four
bits for rn four for rm and 11 for the shifter operand.  Yes that is an I an bit position 25 not a one.  the I is part of the shifter operand encoding

Now go to the section of the manual that describes the shifter operand encoding. the encoding that is just a register rm is bit 25 (the I bit) is zero, and 11 to 4 are zero with 3 to 0 being rm  so add rd,rn,rm

1110 00 0 01000 rn rd 00000 000 rm

1110 00 0 01000 0001 0010 00000 000 0011 = 1110 0000 1000 0001 0010 0000 0000 0011 = 0xE0812003

Now we can test this, take this program

```add r1,r2,r3
.thumb
add r1,r2,r3
```

call it add.s assemble then disassemble

```arm-none-eabi-as add.s -o add.o
arm-none-eabi-objdump -D add.o 
```

and get

```Disassembly of section .text:

00000000 <.text&gt;:
   0:   e0821003    add r1, r2, r3
   4:   18d1        adds    r1, r2, r3
```

which matches the hand encoding.

Now if you are trying to disassemble a chunk of bytes that you dont know what kind they are, that is a different story, this can be very difficult at best, ideally you want to disassemble the whole binary by following the execution and mode changes (which you might not be able to figure out without simulating the execution).  One clue is that ARM instructions generally use the ALways condition which is 0xE at the beginning of the instruction so if you see lots of 32 bit words in the form 0xExxxxxxx those are likely arm instructions and not data and not thumb instructions.  Pure thumb will have a not so typical pattern say 0x6xxx and 0x7xxx but also a mixture of all other starting values.  Thumb2 extensions can start on either halfword boundary and will have a more distinctive start pattern for 32 bit words but because they are mixed with non-thumb2 extensions and not always aligned on 32 bit boundaries thumb with or without thumb2 extensions are not so easy to visually isolate from data only the ARM instructions are easy to visually isolate.

Comment for this answer: +1, great answer. I was trying something different.. I was compiling add.s with "gcc -mthumb" and it still didn't create a thumb binary. Do you know why?
Comment for this answer: I just noticed something else to do diff between arm/thumb in elf files. If you `readelf -s add.o`, in .symtab you get $a or $t depending on the encoding, see http://sourceware.org/binutils/docs/as/ARM-Mapping-Symbols.html
Comment for this answer: notice the .thumb in my code that tells the assembler that the code that follows is thumb.  .code 32 tells the assembler that the code is arm.   There is also the common syntax stuff and other things you can look up on your own.  Also notice that I used gnu assembler not gnu C compiler to assemble the assembly language. (as instead of gcc) even though gcc is going to pass it on to as, there may be pre-processing and the experience can be different than straight assembly.

Here is another answer: In practice, no reason to compile a library as arm unless you intentionally choose to make everything harder. 
Switching between the arm and thumb modes takes some nanoseconds, it's hardware backed, and is by the way much faster than switching between the kernel and user mode you usually experience.  
If you ask me why the whole set of Google's libraries is arm, I'll tell you that there's absolutely no reason albeit that they should keep the things backward compatible and consistent.


{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 1, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2012:00:12/05/12', 'FavoriteCount': 2.0, 'PostTypeId': 1, 'Tags': '<arm>', 'Title': 'arm and thumb instruction set', 'ViewCount': 2080, 'id': 13725878, 'user_AboutMe': None, 'user_AccountId': 2094893.0, 'user_DisplayName': 'prabu', 'user_Reputation': 7.0, 'user_Views': 10.0, 'user_id': 1863901.0}}