Advantage of byte addressable memory over word addressable memory

Question

What is the reason that almost all computers (besides some DSPs) use byte addressable memory? With byte addressable memory and a 32 bit address you can have 4GB while with word addressable memory you can have 4GB * wordsize. Are single bytes used that much that you can't use routines that filter out single bytes from a word because there is an advantage of having more memory?

Answer 1

For 32-bit addresses and 32-bit words, the benefit of being able to address a larger memory is relatively minor, adding only two generations of Moore's Law to the lifetime of the architecture. Compared to a transition from 16-bit addresses to 32-bit addresses (sixteen generations), this is a relatively minor extension.

For the CDC 6600, having 18-bit addresses and 60-bit words and targeting technical computing, the use of word addressing made more sense. Technical computing emphasizes performance over price (so wasting some memory was less important than fast memory access) and has less use for finer-grained accesses.

Many 16-bit DSPs use word addressing. This more significantly increases addressing range than for a 32-bit processor and the benefit of finer-grained access is much smaller for the targeted workloads.

For business and general purpose computing, system cost is a more significant consideration and data element size is more variable. The cost of memory provides an incentive to use smaller data elements. Not supporting direct access to such elements not only increases instruction count (which somewhat directly relates to performance) but code size (which increases memory pressure).

Having a single flat address space simplifies software development. If sub-word addressing requires special handling, this has an effect similar to segmentation where some accesses have to be treated differently than others. Even if such is handled by the compiler, such makes performance less transparent (as well as making compiler development more complex, reducing the resources spent on other features).

Word addressing also requires the use of atomic read-modify-write operation to support simple sub-word stores. (The atomicity requirement may only be with respect to interrupts, but this does add complexity.) A further complication occurs for memory-mapped I/O, where read-modify-write cannot be used since accesses can have side effects. While this issue can be managed by having regions that translate word addresses to specific sub-word granularities, such is an awkward solution. This was how the Alpha 21064 handled byte I/O addresses without byte loads or stores (also 2-byte I/O accesses). (Some 32-bit microcontrollers use bit-banding regions, where an address region uses bit-granular addressing.)

A large part of the reason that byte-addressing (with 8-bit bytes) is popular is, in fact, historical. Not only did IBM's S/360 have a strong influence on the de facto standardization on byte addressing and 8-bit bytes, but the IBM's choice of Intel's 8088 further solidified this trend. With early microprocessors, 8-bit processors would naturally use 8-bit word addressing, maximizing the use of existing software (often written in assembly language) would increase the incentive for using byte-addressed memory. (Note: Reasonable alternatives to the 8086/8088 also used byte-addressing, though IBM's requiring a cheaper and more compatible 8-bit interface may also have been a significant factor. I am not suggesting that word-addressing was only avoided because of the choice of Intel's 8088 for the IBM PC.)

As noted, compatibility with existing I/O interfaces can be particularly problematic.

As Richard L. Sites notes in "Alpha AXP Architecture" (PDF) perhaps more significant benefits of word addressing are avoiding extra shifting of the load result and supporting moderate overhead ECC in a fast writeback cache. Traditional SECDED ECC would require 7 extra bits over 32-bit granules (22% overhead) versus 4 extra bits over 8-bit granules (50% overhead). (Sites' argument about library writers being lazy and using simplistic byte-based string operations is less convincing; forcing extra effort may encourage a moderate addition of effort for higher performance code but it may simply annoy programmers.)

A similar issue applies to unaligned memory accesses. Architecturally disallowing unaligned accesses can simplify hardware but makes some not uncommon operations significantly more complex. Even with MIPS-like load/store unaligned, software must special case unaligned accesses since such instructions increase dynamic instruction count and should not be used if the accesses are known to be aligned. Support for unaligned memory accesses can be particularly beneficial for short vector operations where the individual elements might be properly aligned (e.g., 16-bit elements aligned at 16-bit granularity) but the start of the vector might not be aligned. (This is effectively the same problem as string handling.)

---

It might be worth noting that software-based pointer compression has some popularity. On a 64-bit architecture, software can choose to use simple 32-bit pointers or even exploit structure alignment to store larger pointers in 32-bit memory locations. (A similar software technique uses bits that can be ignored based on known alignment to store metadata. SPARC even architecturally defined such use by supporting tagged arithmetic operations. Storing metadata in the more significant bits of a pointer is also a common technique. ARM's AArch64 allows the most significant 8 bits to be used for metadata without requiring extra masking, and Azul Systems' Vega processor used the most significant 16 bits for metadata.) In pointer-intensive programs, the reduction in cache misses may justify the additional left shift when loading a pointer. Obviously, this technique has limited use since it requires knowing that the data set will fit within the smaller region and that the objects will be aligned. These factors are easier to enforce at the application or even virtual machine software level than at the architectural/hardware level, especially for a merchant processor (a processor sold to various system vendors).

(Using segments identified by the least significant two bits might be better than word addressing. Like word addressing, such would extend the reach of 32-bit pointers by exploiting structure alignment but it would allow further reach by changing segment addresses. This would require special instructions to distinguish dynamic segment specification (which masks out two bits) and static segment specification (which allows byte granular addresses). HP PA-RISC used a similar segmentation system, but used the most significant two bits to identify the segment — allowing simple byte-granular addressing in dynamically specified segments within a GiWord region but making the 64-bit transition messier than if the least significant bits were used. This choice may hint at how important byte granular addressing is for general purpose computing.)

Answer 2

Historically, computers addressed memory as bytes, and since then computers have had to be compatible with older ones. So this has passed down through the generations of computers, however modern CPUs can address words as well as bytes from the RAM, but addressability-wise, a 32 bit address can select any of the 4*1024*1024 bytes in the 4GB memory range. Using words instead would be more confusing to program too, and sometimes the CPU needs single bytes - having to input a whole word and filter that byte out would take precious CPU time. But, if the CPU needs to, it can address a word - it just gets two bytes back. I hope this helps somewhat.