When the Alpha architecture was introduced, it was unique amongst RISC
architectures for eschewing 8-bit and 16-bit loads and stores. It supported
32-bit and 64-bit loads and stores (longword and quadword, in Digital's
nomenclature). The co-architects (Dick Sites, Rich Witek) justified this
decision by citing the advantages:

Byte support in the cache and memory
sub-system tends to slow down accesses for 32-bit and 64-bit quantities.

Byte support makes it hard to build high-speed error-correction
circuitry into the cache/memory sub-system.

Alpha compensates by providing powerful instructions for
manipulating bytes and byte groups within 64-bit registers. Standard
benchmarks for string operations (e.g., some of the Byte benchmarks) show
that Alpha performs very well on byte manipulation.

The absence of byte loads and stores impacts some software semaphores and
impacts the design of I/O sub-systems. Digital's solution to the I/O problem is
to use some low-order address lines to specify the data size during I/O
transfers, and to decode these as byte enables. This so-called Sparse
Addressing wastes address space and has the consequence that I/O space is
non-contiguous (more on the intricacies of Sparse Addressing when I get around
to writing it). Note that I/O space, in this context, refers to all system
resources present on the PCI and therefore includes both PCI memory space and
PCI I/O space.

With the 21164A introduction, the Alpha archtecture was ECO'd to include
byte addressing. Executing these new instructions on an earlier CPU will cause
an OPCDEC PALcode exception, so that the PALcode will handle the access. This
will have a performance impact. The ramifications of this are that use of these
new instructions (IMO) should be restricted to device drivers rather than
applications code.

These new byte load and stores mean that future support chipsets will be
able to support contiguous I/O space.