assemblyx86-64gnu-assembleratt

Should the box at the bottom be %rax instead of %rbx in Fig 6-1 of Jonathan Barlett's book?


I've been reading a book called "Learn to Program with Assembly, Jonathan Barlett". In which , I didn't understand the Figure 6-1.a diagram with some boxes and arrows pointing to/from a memory array

Context: The author is explaining register-indirect mode, using mov (%rbx), %rax.

I suspect that the bottom box should be labeled %rax instead of %rbx. But I'm not 100% confident. Since I'm new to assembly. Am I missing something that I must know or did the author make a mistake?


Solution

  • For mov (%rbx), %rax, the load result is written to RAX.
    RBX is unmodified, only read.
    (Unlike ARM, x86 doesn't have any post-increment or pre-increment addressing-modes that write anything back to the addressing-mode registers. Except with rep movsb and so on, but those use fixed registers, not normal ModRM addressing modes.)

    %rax could make sense for the bottom box, as the destination of the arrow from memory.
    But the text outside the box already covers that.

    A likely interpretation of the bottom box is the response from memory for address %rbx.
    With the text above it saying where it's assigned.

    In terms of how CPUs work, if the cache line(s) holding that qword aren't already hot in L1d cache, the load execution unit handling this micro-op will have to send out a request. If it also misses in L2 cache, it will have to send a request "off core", over the interconnect between cores and memory controllers. (Assuming a typical modern x86 with 3 levels of cache, the inner two being per-core private.)
    So conceptually, memory requests can be a big deal and take some time (or can be very cheap for repeated access to the same line). Other loads to the same cache line can also attach themselves to the same buffer to wait for the incoming data. Anyway, it makes sense to me to draw a diagram with the request and response separate, so I think that's what's going on.

    I don't know if the author has established a convention for block diagrams like that; if so then there's less room for fitting an interpretation.
    A while ago I spent a few minutes skimming Jonathan's previous book, Programming from the Ground Up (free, GFDL, covering i386 using AT&T syntax, which is linked from the x86 tag wiki along with other useful resources), and he does talk some about how real CPUs and real OSes do things.