What ISA is used by Cortex-M/R/A?

What is the difference between arm-none-eabi and arm-elf-gcc? Are there any other compilers for ARM devices worth mentioning?

  • \$\begingroup\$ "#2.1 This one is only for Cortex-M/R right?" The gcc-arm-none-eabi cross-compiler should work with any ARM microcontroller/microprocessor. \$\endgroup\$
    – m.Alin
    Feb 10, 2017 at 13:53
  • 1
    \$\begingroup\$ 1) No, v7a and v7r are full v7 (arm+thumb), but v7m is thumb only, and no, just like you can not (easily) run a (any) windows program on a linux computer, there's more to worry about than ISA. 2) mostly GCC or clang variants, none-eabi stands for no OS and EABI as ABI. os could also be linux and others, ABI could be gun-eabi/gnu-eabi-hf, etc. 2.1) no, you can still use it for v7a, v6, etc, as long as no-os and EABI is what you need. 3) it uses a different abi: elf, an earlier version of ARM ABI. \$\endgroup\$ Feb 10, 2017 at 14:00
  • \$\begingroup\$ @user3528438 Is it right there is the traditional ARM IS (32Bit), then there is Thumb-1(16Bit) and the "new" one Thumb-2 (32Bit)? Ok, I'll remove that. What I wanted to say is that Cortex-A understands, instructions of a program build for Cortex-M beside of having the same registers etc. But as I understand this is true so. As for 3) do have any more information about it? And thank you a lot for your help. \$\endgroup\$ Feb 10, 2017 at 14:13
  • \$\begingroup\$ @user3528438 I remarked that arm-none-eabi-gcc still generates object files with elf-format. \$\endgroup\$ Feb 12, 2017 at 13:34
  • \$\begingroup\$ Since you changed the question. Which ISA is used is documented in the architectural reference manuals. all support thumb plus various levels of thumb2 extensions. Some jazelle and floating point, some not. thumb2 are formerly undefined thumb1 instructions, technically if you find the right arm info by the time thumb2 extensions started (armv6m) that was like the fifth thumb instruction set or something, they dont use those terms normally thumb2 has at least two major flavors and are extensions to thumb1 not a separate deal. \$\endgroup\$
    – old_timer
    Feb 12, 2017 at 15:13

1 Answer 1


For every other processor you own (even if you dont know you do) you probably have at least one ARM based thing if not more than one. You cant escape them they are everywhere. Likewise toolchains, there are a number of them but GNU works just fine and is easy to come by. Can easily build your own from scratch or get a pre-built, I may add some links later in comments.

The predecessors to the cortex name being used the ARMV4T (ARM7TMDI) to that point all supported ARM instructions and thumb instructions. The cortex-m family is a thumb only machine, it does not execute ARM instructions. There have been some thumb-2 extensions, a small number in armv6m (cortex-m0 and m0+) and over 100 in the armv7m (cortex-m3 -m4 -m7), plus the full sized cortex-a also supports a number of thumb2 extensions, they are just formerly undefined thumb instructions (16 bit) that became variable length (two instructions wide) instructions to gap the bridge between thumb limitations and full sized arm features. thumb support was added in gcc 3.x.x, and has been maintained ever since, the current 5.x.x and 6.x.x know about the various arm instruction sets including thumb and arm. So you are not limited using the gnu toolchain you can develop for the cortex-a, cortex-r and cortex-m families. Note the cortex-r is a full sized arm although I think an older one, but two cores tied in lockstep or such that if one takes a different path than the other an alarm of some sort happens. They are for security/health stuff. Can buy some eval boards from TI but other than that I have not seen them (and I bricked at least two of my TI boards btw).

The armv8 is a new beast, it has aarch32 (which is the traditional ARM instruction with 32 bit registers) then aarch64 which is the new 64 bit instruction set, the instructions are 32 bits wide but the GPRs are now 64 bits. It is a completely incompatible instruction set, completely new. GNU supports it but in gnu fashion you have to build the toolchain for the aarch64 target. The generic arm gnu toolchain target will build for all the pre armv8 cores, even back to the arm3 and maybe arm2 (see the amber core at opencores for example, can use the gnu arm target tools for it).

So for example arm-none-eabi-gcc --target-help shows

  Known ARM CPUs (for use with the -mcpu= and -mtune= options):
    arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250
    arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d
    arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e
    arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a17 cortex-a17.cortex-a7 cortex-a32 cortex-a35 cortex-a5 cortex-a53 cortex-a57
    cortex-a57.cortex-a53 cortex-a7 cortex-a72 cortex-a72.cortex-a53 cortex-a8 cortex-a9 cortex-m0 cortex-m0.small-multiply cortex-m0plus
    cortex-m0plus.small-multiply cortex-m1 cortex-m1.small-multiply cortex-m3 cortex-m4 cortex-m7 cortex-r4 cortex-r4f cortex-r5 cortex-r7
    cortex-r8 ep9312 exynos-m1 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native
    qdf24xx strongarm strongarm110 strongarm1100 strongarm1110 xgene1 xscale

  Known ARM architectures (for use with the -march= option):
    armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6kz armv6s-m armv6t2 armv6z armv6zk armv7
    armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc armv8.1-a armv8.1-a+crc iwmmxt iwmmxt2 native

so armv2 to armv8. I am curious to know what that armv8 is I wonder if it is only aarch32.

But to digress you can build thumb based various thumb support and 32bit ARM programs with the one toolchain. The triplet for gnu naming is confusing and since I think you can sometimes override with whatever you want are not some global carved in stone thing. The current popular ones are arm-none-eabi- and arm-linux-gnueabi- the former has the notion of embedded using newlib or something like that, the latter is meant for building programs against glibc for running on linux. For bare metal if you write your code right you can use either interchangeably.

So cortex-m3 applications on your iphone, well no not because of thumb or thumb2, thumb, the original is the one instruction set that works on all cores from the armv4t to the present. but because cortex-m3 applications are bare metal or are for a small OS (RTOS like FreeRTOS), so your system calls are likely wrong and the binary format is likely wrong to run on your phone. The notion that knowledge of thumb instructions for a cortex-m also applies to an armv7, is correct. And the core on your phone can handle thumb instructions. But the programming language, the toolchain, and other items dictated by Apple may limit what you can or cant do for phone apps. They invested heavily in llvm so I think they use the llvm tools which also support at least thumb and arm in one toolchain (llvm by design supports all the targets in one toolchain to some extent, you dont have to do a new compile for each target other than the linker).

The launchpad link you posted is the link I was going to post, but that has now moved to an arm hosted tool which they do use the letters rm which are confusing as cortex-r is full sized arm instructions and cortex-m are thumb only. But the cortex-r and cortex-m are both families that target microcontrollers or that level of embedded design. So it makes sense from that perspective, and I would recommend that toolchain if you dont want to build your own. You are not going to be using that toolchain for building iphone apps though.

arm-elf-gcc is just another triplet, before the eabi abi, that was one of the popular triplets. they dont mean too much but when compiling the toolchain the triplet causes certain default choices to be made, and if it doesnt recognize the triplet or doesnt have a wildcard for one of the items then the stock build system will bail out. I have not tried building arm-elf or arm-none-elf in a while.

The launchpad toolchain and/or building for arm-none-eabi will work on all of those cores listed, you can build embedded (Bare metal, RTOS based, etc) for any of those cores from a quad core armv7 down to a cortex-m0+, but not link for linux binaries. Bare metal or whatever os support you provide

The binutils are generic, or can be, the assembler can take assembly and make an object. The linker can link objects based on the rules in the linker script. The compiler can take a file and make an object from it that can be linked with other objects. None of this is operating system dependent yet, it is when you combine all of these things plus external libraries desired by the programs gcclib, C library, and system calls are when you get OS specific. And all of the triples are going to allow you to build object files from asm or C and link them so long as you avoid external libraries. If you feel the need for those libraries even C libraries or even fixed or float division or multiplication in software (gcclib) it starts to become operating system dependent, external libraries start to get involved.

  • \$\begingroup\$ Thank you for your very, very detailled answer. This helped me a lot! \$\endgroup\$ Feb 12, 2017 at 13:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.