The ARM processor architecture: Somebody else’s introduction


While you wait for me to write the Alpha AXP processor architecture overview,¹ I'd like to direct your attention to the ARM processor architecture overview written up by Marion Cole over at the NT Debugging blog. I hope that'll keep you busy for a little while longer.

¹ Spoiler alert: Don't hold your breath.

Comments (15)
  1. Cesar says:

    It's interesting to compare this 3-part series with Raymond's 10-part series on the IA-64. ARM is way simpler! Simpler to understand, simpler to generate code for it, and simpler to implement in hardware (which is why it's popular as an embedded processor).

  2. Dan says:

    Awww, the AXP thing sounds great!  The Itanium series was far more interesting then I expected, and I learned a lot from it.  I hope you change your mind.  Do you have first hand experience on any other "novel" processor architectures?

    [The AXP series is coming, but I have to write it first! -Raymond]
  3. rw says:

    Also ARM has it's weirdness. Immediate values in opcodes are only 8 bit, which makes it hard to load registers with constants. Loading an address to a register would take (up to) 4 instructions, therefore ARM code usually loads the constants from memory. Problem still not solved, because now we need the address of the constant. As the PC is one of the general purpose registers (R15), constants are loaded from a PC relative address (Rd=[R15+offset]). This leads to blocks of constants between each function, which is disadvantageous for cache (how to prevent that constants are loaded to instruction cache) and MMU (how to ensure there are no execution rights on addresses with data). (Does not apply to ARMv8, which is a completely different beast)

  4. fabian says:

    @rw

    Actually, immediates can be 12 and 16 bits as well, for instance with "ldr r0, [r0, #0xfff]" or "movw r0, #0xdead".

    movw/movt is used to load any 32-bit value into a register.

  5. rw says:

    @fabian

    You are right, but movw/movt are relatively new opcodes. Introduced with the ARM11 in 2002, so not supported on the oh so famous ARM7. If you have to write portable code, you can't use movw/movt. I wrote a ROM monitor for ARM 10+ years ago, and haven't been in much touch with ARM since then.

  6. Myria says:

    It's an interesting decision on ARMv7-Thumb2 Windows NT, also known as Windows RT and Windows Phone, to have the kernel force the Thumb bit to 1 in the CPSR.  It means that runtime code generation cannot be used to generate ARM code, only Thumb2.

    Some people I know weren't able to port Chrome to Windows RT desktop mode because of this.

  7. sense says:

    @rw:

    Perhaps I'm wrong, because I'm not familiar with ARM, but it seems to me that loading the constants by an immediate value would NOT differ from what you describe:

    They will be loaded from "executable" memory. And they will put pressure on instruction cache I presume.

  8. SimonRev says:

    I presume if you start writing the AXP series that it will debut sometime in 2017.  (This is OK with me — while I enjoyed the Itanium series, I only care to delve at that low level every few years or so)

  9. Daniel Z says:

    I think it would be cool if Raymond wrote an overview of x86 idiosyncrasies and the things the windows team had to do to deal with them.

  10. rw says:

    @sense:

    Immediates inside instructions reach the register through an instruction fetch, whereas PC relative constants reach the register through a load. Instruction fetch (aka execution), data load and data store usually have separate permission flags in the memory management unit.

    Ideally you would want to have four separate address ranges: One for code with only execution permission, one for data with read/write permission, one for the stack (r/w), and one read-only for constants.

  11. Karellen says:

    @rw: Why would putting constants in the text section put pressure on the MMU w.r.t ensuring there are no execution rights on addresses with data? As these are constants, surely it would be possible to keep the text pages non-writeable, so there shouldn't be any danger of someone putting exploits there to execute?

    Or is it to protect against the data accidentally having a useful meaning in machine code, and being used that way. (Would that be a variant of ROP?)

    [It means that the constants occupy space both in the I-cache (sharing a cache line with live code) and in the D-cache (because they are accessed as data, causing other instructions to get pulled into D-cache too). -Raymond]
  12. rw says:

    @Karellen: If an attacker finds an exploit that allows dumping memory locations, it can be used to dump the program code, if the MMU gives read permission for text pages.

  13. Evan says:

    @Daniel Z: "overview of x86 idiosyncrasies"

    Intel has this much covered at least. It's called the "Intel® 64 and IA-32 Architectures Software Developer’s Manuals".

    </snark> :-)

  14. acq says:

    @Daniel Z: "overview of x86 idiosyncrasies"

    Raymond wrote about x86, in fact, it's the only CPU that is "being too nice" to the developers, forgiving what other CPUs (relevant to MSFT at the time the post was written) didn't:

    blogs.msdn.com/…/229387.aspx

    It seems that debugging is also often significantly easier with x86.

  15. I'm a bit of a lurker, but I wanted to thank you for the IA-64 series, it was great.  For a change!  Rimshot.  Just kidding, this blog is pretty much all great, even the 8-part series on scrollbars.

Comments are closed.

Skip to main content