Complete ARM only Instruction Set (as promissed).

[DavidS]

ARM Instructions In a Couple Pages:
Keeping a Promise:
In 2012 I had made a promise on these forums that one day I would prove how small the ARM instruction set is by posting the entire ARM opcodes on a space that could be printed in a couple of pages. This is me keeping that promise, which I had forgotten about for a while.

What Instructions Again:
These are the ARM instructions, that is none of the coprocessors, just the ARM ops. So NO VFP/NEON, etc, just the actuall ARM instructions (up to ARMv8 AARCH32, so only the real 32 bit mode ARM instructions).

Also this is only ARM, so No Thumb

And this is an opcode reference, not a programmers manual.

The Opcodes: Start here:
Data Processing Instructions take the form (all instructions are 32-bits wide):

Code: Select all

Bits   |   Meaning
-------+-------------------------------------------------------------------
31-28  |   Condition code, only execute op if true:
       |     0x0 = EQ     If equal, zero flag set.
       |     0x1 = NE     If not equal, zero flag cleared.
       |     0x2 = CS     If carry flag set.
       |     0x3 = CC     If Carry flag cleared.
       |     0x4 = MI     Minus, negitive.
       |     0x5 = PL     Plus, positive.
       |     0x6 = VS     Overflow flag set.
       |     0x7 = VC     Overflow Flag cleared.
       |     0x8 = HI     Unsigned higher.
       |     0x9 = LS     Lower or Same, unsigned.
       |     0xA = GE     Greater than or equal, signed.
       |     0xB = LT     Less than, signed.
       |     0xC = GT     Greater or equal, signed.
       |     0xD = LE     Less than or equal, signed.
       |     0xE = AL     Always true, unconditional.
       |     0xF = NV     RESERVED, used to extend opcodes in later ARMs.
27-26  |   Set to 0 for these instructions.
25     |   Imediat Operand specifier (if 0 Opr2 is register with optional
       |     shift applied, if 1 Opr2 is imed val see below for format).
24-21  |   Opcode:
       |     0x0 = AND    Bitwise AND.
       |     0x1 = EOR    Bitwise Exclusive OR.
       |     0x2 = SUB    Subtract.
       |     0x3 = RSB    Reverse subtract.
       |     0x4 = ADD    Add.
       |     0x5 = ADC    Add with carry.
       |     0x6 = SBC    Subtract with carry.
       |     0x7 = RSC    Reverse Subtract With Carry.
       |     0x8 = TST    TST bits.
       |     0x9 = TEQ    Test if equal.
       |     0xA = CMP    Compare.
       |     0xB = CMN    Compare negitive.
       |     0xC = ORR    Bitwise OR.
       |     0xD = MOV    Copy value.
       |     0xE = BIC    Bit Clear.
       |     0xF = MVN    Move negitive.
20     | S flag, if 1 condition codes are set based on operation, if 0
       |    condition codes disgarded.
19-16  | Rn, the first source register.
15-12  | Rd, the destination register.
11-0   | Operand 2 (Opr2).  Can be immed or register depending on bit 25.
       |   If bit 25 is set this is an imediate operand and the format is:
       |     8-11 = Shift amount.
       |     0-7  = 8 Bit immediate value.
       |   If bit 25 is clear, it is a register value, with the form:
       |     4-11 = Shift value.
       |     0-3  = Register

Next up is the Branch Opcode, which takes the form:

Code: Select all

bit    | Meaning
-------+--------------------------------------------------------------------
31-28  |  Condition (same as above). If condition is 0xF and bit 24 clear
       |    Then this becomes BLX
27-25  |  Constant 0b101.
24     |  Link bit, if set branch with link, if clear just branch.
23-0   |  Offset to branch.

Note that BX takes the form of 0xZ12FFF1R where Z is the condition code and R is the register number. Yes it is almost the same as TEQ.

Next up is Multiply and Multiply With Accumulate:

Code: Select all

bit    | Meaning
-------+--------------------------------------------------------------------
31-28  | Condition, same as Data Processing.
27-24  | Constant 0b0000.
23     | Long, if set this is a long (64-bit dest) multiply.
22     | For Long Multiply only, U flag, set if unsigned, clear if signed.
21     | Accumulate, if set multiply with accumulate, if clear just multiply.
20     | S bit, if set condition codes are updated, otherwise discarded.
19-16  | Register for high word of dest.
15-12  | Register for low word of dest.
11-8   | source reg.
7-4    | Constant 0b1001.
3-0    | Multiplicand register.

LDR/SDR

Code: Select all

 BIT   | Meaning
-------+--------------------------------------------------------------------
31-28  | Condition same as data processing.
27-26  | Constant 0b01.
25     | Imediate specifier.
24     | Post Indexed if clear, pre indexed if set.
23     | Up/Down bit, offset added if set, offset subtracted if clear.
22     | If clear word transfer, if set byte transfer.
21     | If set the final used address is written into the base address.
20     | If set this is a load, if clear it is a store.
19-16  | Base register.
15-12  | Destination Register.
11-0   | Offset.

LDM/STM

Code: Select all

 BIT   | Meaning
-------+--------------------------------------------------------------------
31-28  | Condition, same as data processing.
27-25  | Constant 0b100.
24-16  | Same meanings as LDR/STR.
15-0   | Register List.  Where bit 0 set for R0, bit 2 R2 ... bit 15 R15.

SWI takes the form:
0xYFVVVVVV
Where VVVVVVV is the number SWI is called with. The ARM ignores this number,
it is there for the operating system to determine the call. Y is the normal conditional feild same as other ops.

Coprocessor Data Transfer:

Code: Select all

 BIT   | Meaning
-------+--------------------------------------------------------------------
31-28  | Condition, same as data processing.
27-25  | Constant 0b110.
24     | Pre index if set, if clear post index.
23     | Up/Down bit, if set add offset, if clear subtract offset.
22     | Length of transfer.
21     | If set used address written to ARM base register.
20     | If set load from coprocessor, if clear store to coprocessor.
19-16  | ARM Base register.
15-12  | Coprocessor Register.
11-8   | Coprocessor number.
7-0    | Offset.

Coprocessor Data operation:

Code: Select all

 BIT   | Meaning
-------+--------------------------------------------------------------------
31-28  | Condition, same as data processing.
27-24  | Constant 0b1110
23-20  | Operation part 1 (Op1) code.
19-16  | Coprocessor register.
15-12  | Coprocessor destination reg/ ARM reg if bit 4 is set.
11-8   | Coprocessor number.
7-5    | Operation part 2 (Op2) code.
3-0    | Coprocessor register m.

And there you have the entire ARM 32 bit mode instruction set, though only the ARM instructions set (no NEON, etc)

I omited the SWP instruction because it has become depricated.

Also I did not list the UDIV/SDIV instructions, these I can not find an accurate reference on and I do not use. Some references give one form and some another, and they conflict with each other, using the recommend mnemonic will not assemble, giving a format error (so I can not compare the generated opcode).

As stated above not going into any of the coprocessors here, only worried about the ARM. It is especially important to remember that many extensions are coprocessors now that many are a standard part of the chip. Knowing that they are indeed cooprocessors will help with optimization.

[DavidS]

While this fulfills what I had promissed already, should I give some of the coprocessor ops (perhaps at least the CP15 stuff, and maybe VFP/NEON)? They are very usefull, and (in the case of CP15) needed for many things once you go bare metal.

[Heater]

I think that if GCC can generate it then it should be in the list. After all, they are the instructions actually being used by our software.

If I understand correctly GCC will generate also thumb instructions where appropriate. I have not been able to verify this.

[dave j]

I think that if GCC can generate it then it should be in the list. After all, they are the instructions actually being used by our software.

If I understand correctly GCC will generate also thumb instructions where appropriate. I have not been able to verify this.

GCC can generate thumb instructions but since ARMv6 supports thumb 1 instructions and ARMv7 and neither supports the other, it might not be worth doing if people want portable code.

Of more use would be the extended multiply instructions, the parallel add/subtracts, etc. They get variously described as Media, DSP and SIMD32 instructions and are supported on all Pis.

GCC uses some of these assuming you have data appropriately packed into registers.

They provide, limited, integer vector operations on ARMv6 which wouldn't otherwise have them as VFP is floating point only.

[Heater]

Ah OK.

All that I was getting that is that if one were to disassemble all of Raspbian, for example, then all the instructions found there should be in David's document. They are the instructions we are actually using.

Of course that is only this week, the ARM instruction set keeps changing all the time, next week if Raspbian goes 64 bit a lot of stuff gets thrown out and we have a different instruction set again.

[jahboater]

Also I did not list the UDIV/SDIV instructions - using the recommend mnemonic will not assemble, giving a format error (so I can not compare the generated opcode).

I don't know if this helps? If you want anything else assembled, just say:

Code: Select all

  12F311E7 	sdiv    r1, r2, r3
  12F331E7 	udiv    r1, r2, r3

[jahboater]

If I understand correctly GCC will generate also thumb instructions where appropriate. I have not been able to verify this.

Yes it does, and I use it all the time.
For ARMv6 (Pi Zeros and old Pi models) -mthumb produces thumb1 which is 16-bit only and useless.
For the later models Pi2 onwards, -mthumb produces thumb2 which is supurb. The resultant executable is about 25% smaller and fractionally faster.
Thumb2 is a complete ISA (some ARM CPU models support thumb2 and nothing else). It is mixed 16 and 32 bit (just like the RISC V "C" extension).

dave j,
There is no portability issue at all using thumb2 since no source code changes are required. It is simply adding the one compiler flag: -mthumb.
Brilliant!

[Paeryn]

There are quite a few ARM instructions missing from your list,

Synchronisation: DMB, DSB, ISB, LDREX, STREX, CLREX
Various system related: SEV, ERET, RFE, MSR / MRS, HVC, SMC, SETEND, PLD, PLI
Bit: BFC / BFI (Bit Field Clear / Insert), CLZ (Count Leading Zeros), REV (Reverse byte), RBIT (Reverse Bit)
Packing / selection: PKH, SEL
The DSP related instructions, (S|SH|Q|U|UHS|UQ)(ADD|SUB)(16|8), (also ASX|SAX with the same type prefixes but no size suffix as they are halfword only). These were from before NEON and work on the ARM registers.
There are probably a few more in there too.

UDIV / SDIV Rd, Rn, Rm is

Code: Select all

31-28  condition code
27-23  01110
22-20  0S1    S is set for UDIV, clear for SDIV
19-16  Rd
15-12  1111
11-8   Rm
7-4    0001
3-0    Rn

[jahboater]

DavidS,
Have you missed MLS multiply and subtract? (handy as it calculates the remainder from a division in one go).

What about CBZ and CBNZ ? extremely useful ARM instructions for obvious reasons.

Also SBFX and UBFX - Signed and Unsigned Bit Field eXtract (more useful than you might think)
I see @Paeryn has mentioned the other bit insns.

[jahboater]

While this fulfills what I had promissed already, should I give some of the coprocessor ops (perhaps at least the CP15 stuff, and maybe VFP/NEON)? They are very usefull, and (in the case of CP15) needed for many things once you go bare metal.

For most Pi's now (Pi2, Pi3, Pi3B+, Pi3A), NEON is not a coprocessor. It is a fixed part of the ARMv8 core ISA, guaranteed present.
However, there are an awful lot of NEON instructions, so maybe leave them out.

[dave j]

There is no portability issue at all using thumb2 since no source code changes are required. It is simply adding the one compiler flag: -mthumb.
Brilliant!

I was thinking of binary portability so you can have a single set of binaries that run on all Pis - same as Raspbian.

[DavidS]

Also I did not list the UDIV/SDIV instructions - using the recommend mnemonic will not assemble, giving a format error (so I can not compare the generated opcode).

I don't know if this helps? If you want anything else assembled, just say:

Code: Select all

  12F311E7 	sdiv    r1, r2, r3
  12F331E7 	udiv    r1, r2, r3

Thank you, I will compare with refs later and update once I figure out correctly the format. Thank you.

[DavidS]

If I understand correctly GCC will generate also thumb instructions where appropriate. I have not been able to verify this.

Yes it does, and I use it all the time.
For ARMv6 (Pi Zeros and old Pi models) -mthumb produces thumb1 which is 16-bit only and useless.
For the later models Pi2 onwards, -mthumb produces thumb2 which is supurb. The resultant executable is about 25% smaller and fractionally faster.
Thumb2 is a complete ISA (some ARM CPU models support thumb2 and nothing else). It is mixed 16 and 32 bit (just like the RISC V "C" extension).

dave j,
There is no portability issue at all using thumb2 since no source code changes are required. It is simply adding the one compiler flag: -mthumb.
Brilliant!

I think he meant binary portability (the ability to run on more ARM's).

[DavidS]

There are quite a few ARM instructions missing from your list,

Synchronisation: DMB, DSB, ISB, LDREX, STREX, CLREX
Various system related: SEV, ERET, RFE, MSR / MRS, HVC, SMC, SETEND, PLD, PLI
Bit: BFC / BFI (Bit Field Clear / Insert), CLZ (Count Leading Zeros), REV (Reverse byte), RBIT (Reverse Bit)
Packing / selection: PKH, SEL
The DSP related instructions, (S|SH|Q|U|UHS|UQ)(ADD|SUB)(16|8), (also ASX|SAX with the same type prefixes but no size suffix as they are halfword only). These were from before NEON and work on the ARM registers.
There are probably a few more in there too.

UDIV / SDIV Rd, Rn, Rm is

Code: Select all

31-28  condition code
27-23  01110
22-20  0S1    S is set for UDIV, clear for SDIV
19-16  Rd
15-12  1111
11-8   Rm
7-4    0001
3-0    Rn

Thank you for that. All of it I was not thinking about the sync instructions. I did not include the hypervisor only stuff on purpose.

I did seem to miss the bitfeild ops though, thank you again for the good review, and catch. Documenting is a lot more difficult than using.

Though the 8-bit ADD and such are there, look at the bits for data processing instructions.

[jahboater]

I think he meant binary portability (the ability to run on more ARM's).

Yes you are right, he did.

Its not something I ever do. I compile everything on the machine I am going to use it on (e.g. with -march=native). That way I get the fastest and smallest executable possible. Pi's are fast enough to compile anything, even a Pi Zero. I paid £32 for my Pi3B+ and I am not going to run ARMv6 code on it (Not my own code I mean).

[DavidS]

While this fulfills what I had promissed already, should I give some of the coprocessor ops (perhaps at least the CP15 stuff, and maybe VFP/NEON)? They are very usefull, and (in the case of CP15) needed for many things once you go bare metal.

For most Pi's now (Pi2, Pi3, Pi3B+, Pi3A), NEON is not a coprocessor. It is a fixed part of the ARMv8 core ISA, guaranteed present.
However, there are an awful lot of NEON instructions, so maybe leave them out.

Sorry, though even though it is included by requirement on the die as of ARMv8 on does not change the fact that NEON is a coprocessor. To be more precise it and VFP are CP10/CP11, and are a single coprocessor. And it is in all the RPi implementations, though it is a coprocessor.

[jahboater]

even though it is included by requirement on the die as of ARMv8 on does not change the fact that NEON is a coprocessor. To be more precise it and VFP are CP10/CP11, and are coprocessors. And it is in all the RPi implementations, though it is a coprocessor.

David, it has all changed!
ARMv8 has no coprocessors.
To use their own words:-

"The concept of a “coprocessor” is removed from the architecture."

See this doc:
https://www.element14.com/community/ser ... Manual.pdf

[DavidS]

even though it is included by requirement on the die as of ARMv8 on does not change the fact that NEON is a coprocessor. To be more precise it and VFP are CP10/CP11, and are coprocessors. And it is in all the RPi implementations, though it is a coprocessor.

David, it has all changed!
ARMv8 has no coprocessors.
To use their own words:-

"The concept of a “coprocessor” is removed from the architecture."

See this doc:
https://www.element14.com/community/ser ... Manual.pdf

I know what the marketing liturature says, I am aware of the marketing, though it is that.

You issue a NEON/VFP instruction by talking to CP10/CP11 with the coprocessor instructions, the coprocessor instructions are what run on the main pipeline. Then the NEON instructions are executed while the ARM core continues to execute other unrelated instructions, without any interference fromt the NEON. So regardless of the talk and marketing, which has even crept into the datasheets, they are still a coprocessor from the programmers point of view, which is what matters when talking about the ISA, as the ISA is used by the programmer/.

[jahboater]

That's not marketing by the way. The document I linked to is entitled:-

ARMv8 Instruction Set Overview
Architecture Group

Document number: PRD03-GENC-010197 15.0
Date of Issue: 11 November 2011

I hope it is authoritative.
The ARMv8 ARM is so big my poor old Ivybridge PC struggles to move around it
But it doesn't mention NEON coprocessors at all.

[DavidS]

That's not marketing by the way. The document I linked to is entitled:-

ARMv8 Instruction Set Overview
Architecture Group

Document number: PRD03-GENC-010197 15.0
Date of Issue: 11 November 2011

I hope it is authoritative.
The ARMv8 ARM is so big my poor old Ivybridge PC struggles to move around it
But it doesn't mention NEON coprocessors at all.

And that is one of the manuals that I said it has crept into. I have a copy of that.

I no longer bother with hard copies of the ARM ARM it has gotten way way to big. Instead I find smaller documents that cover what I need and print those, keeeping a copy of the ARM ARM on a flash storage device.

Though the way it is implemented in the AARCH64 ISA is quite missleading, though the AARCH64 ISA has about as much in common with ARM 32-bit ISA (I do not like the term AARCH32) as the ARM ISA has in common with the M680x0 ISA. They are worlds apart, to a surprising point, I would have thought that ARM wold have stuck a little closer to an ARM like ISA.

I can understand why they removed LDM/STM (we can work without those even in the old 32-bit ISA, they are nice to have though now that the bus is wider), these are the only ARM instructions that people can really use against ARM when attempting to put it down in terms of RISC.

[DavidS]

And that ISA manual is not what it claims, no opcodes, only mnemonics, and other information.

[jahboater]

And that ISA manual is not what it claims, no opcodes, only mnemonics, and other information.

It does say its just an overview.

ARMv8 Instruction Set Overview

[Heater]

Bah, humbug!

If I can't pull it out of it's socket then it is not a co-processor

[DavidS]

Bah, humbug!

If I can't pull it out of it's socket then it is not a co-processor

LOL.

[Heater]

DavidS,

I would have thought that ARM wold have stuck a little closer to an ARM like ISA.

Why?

The move from 32 to 64 bits is a big one. Requiring a lot of compiler and tools development and so on. It's a good opportunity to ditch all the junk you have been hoarding for years that never turned out to be useful. Perhaps adopt some new techniques.

Same happened with the move from Intel's 32 bit architecture to AMD's 64.