Why is word-addressable the exception, not the rule?

As stated on Wikipedia:

instead of word-addressable. Why is this case? Since the CPU processes words (of predominantly 64 bits or 8 bytes) now, wouldn't the word-addressable approach be more efficient?

• My guess: it comes from the era when memory was scarce and pushing bits paid off. You wanted the ability to store (and access) smalls numbers in the space a single larger one would take. On the other hand, you want to address multiple bits with one address so your address space can handle as much memory as possible. There's a tradeoff for you -- today's answers are probably very different from the ones back then, but we have inherited them via x86. – Raphael Mar 3 '16 at 8:02
• Thanks, @Raphael, for your comment. I'm not sure I understand your first point: "store (and access) smalls numbers in the space a single larger one would take" - why would we want this? It sounds like some space is being wasted. – Tosh Mar 4 '16 at 6:29
• I should have written "multiple small numbers". – Raphael Mar 7 '16 at 9:41

Byte operations will always be important because a lot of a modern workload involves bytes. Text processing and bytecode interpretation (including emulation of other CPUs) are obvious examples, but also device drivers often need to be able to manipulate bytes efficiently.

Byte-addressed memory can be emulated with word-addressed memory and a reasonable assortment of bit manipulation instructions, however this means that you need more instructions to do the same thing, and those instructions have long chains of data dependencies between them.

RAM is reasonably cheap, but the instruction pipeline in a modern CPU is not.

Every so often, ISA designers reason that byte and short word load/store instructions aren't that important. Within two revisions, those instructions inevitably get added. This was the case with MIPS and Alpha, for example. Code density, it turns out, is quite important.

Note that this isn't true of arithmetic and logic operations. Given a sufficient number of registers (which, I might add, 32-bit x86 and earlier did not have), there doesn't seem to be any gain in implementing byte and short-word arithmetic and logic instructions. Well, for non-vectored instructions, anyway.

• According to what I'm finding, Alpha was unique (among RISC ISAs) in omitting byte load/store. Wikipedia says first-gen MIPS had lb[u] and sb, and half-word store/load (also with sign or zero extension). Perhaps you're thinking of unaligned address support for lw / sw in MIPS, obsoleting lwr / lwl? (That wasn't guaranteed until MIP32/64 release 6 in 2014, though, according to Wiki. Specific implementations presumably had it, and that's fine for embedded software.) – Peter Cordes Oct 13 '17 at 3:38
• Oh, maybe I am. – Pseudonym Oct 13 '17 at 3:39
• Earlier non-RISC word-addressable machines didn't even have address bits for bytes within words (unlike Alpha), so partial-word loads would need an extra offset. But that was back before 8 bits per byte was even standard, so partial-word loads might have been 18 bits or 9 bits or whatever. (BTW, working on an answer for the related stackoverflow.com/questions/46721075/…) – Peter Cordes Oct 13 '17 at 3:41

In the end, what the CPU does when accessing data in cache is irrelevant, memory access is by cache line (i.e., 128 byte blocks for the Pentium 4).

• It is not quite irrelevant. One of the arguments for Alpha only supporting 32-bit and 64-bit memory accesses was that ECC support would either require read-modify-write or a relatively large number of extra bits. (Alpha did use byte addressing, in the sense that the addresses were byte addresses.) – Paul A. Clayton Mar 4 '16 at 3:46
• If I understand this correctly, "cache line" is to the CPU like a "page" is to main memory - basically a block of 128 bytes is swapped in and out at once. But I'm trying to make the connection to my original question...because the cache line doesn't require byte-addressing, we can just use word-addressing, right? Which seems more efficient... – Tosh Mar 4 '16 at 6:08