有一些 DSP（例如，TI C54x）无法处理小于 16 位的值，并且一些音频 DSP 使用 24 位。但是，几乎所有通用代码都使用 8 位值，因此所有通用 CPU 都支持它。

并且仅仅因为用于内存地址的最小单位是 8 位字节并不意味着这将是总线上实际使用的最大单位；大多数 CPU 使用其本机字大小（16/32 位）甚至更大的大小来寻址内存，并且在使用字节访问时，会自动从较大的字中提取字节。

例如，PCI 总线总是使用 32 位事务，但用于访问的字节使能信号必须更小。

16 位或 32 位微控制器通常需要处理只有 8 位宽（一个字节）的数据。例如，文本字符串通常以每个字节一个字符的形式存储。通过具有允许对每个单独字节进行寻址的存储器寻址方案，微控制器可以有效地处理 8 位宽的数据。这意味着 32 位数据通常驻留在 4 字节的倍数的地址上，例如 04、08、0C 等。但是如果存储器是 32 位宽，那么微控制器可以在一个读取周期内读取 32 位. Micro 经常有机器指令可以对不同长度的数据进行操作，所以你会发现一条移动数据指令（MOV）可以有 MOV.B、MOV.W 和 MOV.L 三种形式来移动 8、16 和 32 位一条指令中的数据。

这实际上是一种设计选择，没有硬性理由必须如此。回到过去，当大容量商品处理器以 8 位值运行时，映射更一致地是 1:1。随着设计演变为现代 32 位和 64 位处理器，为了保持一致性，即使数据总线增加（实现成本权衡不断变化），保留旧的字节寻址映射也是有意义的。一些 32 位 MCU 可能仍然只为某些内存实现 16 位数据总线，高端处理器将具有 256 位或更高，并且能够在单个内存事务中加载多个内核寄存器。宽接口适用于突发或流式操作。

较小的可寻址内存大小不仅在处理代码中的字节值的情况下很有用，而且在处理内存中的结构（如需要读取或修改特定字节的以太网数据包）时很有用。通常这种操作需要能够执行小操作但非常有效。

还有一些场景需要对大端、小端或混合端数据进行操作。现在通常有专门的硬件支持，但同样，内存的字节寻址将使这种类型的操作在某些情况下更有效。

最近，寄存器中的地址位数一直是地址空间的限制因素，因此在 10 到 15 年前，浪费 2 位来寻址字节而不是 32 位字并不是什么大问题（并且现在有 64 位指针，通常实现 48 位或 56 位宽的字节地址）。介绍性计算机科学教学仍然有点停留在刚刚发布的大型机时代，并且并不总是非常清楚地解决进化方面的问题。在小批量高成本架构（在最一般意义上）开始被更多资源受限和更注重商品的处理器设计补充的时候，许多术语开始使用（和定义）。

我没有专门针对 MCU 回答，架构边界并不像您想象的那么清晰。即使是现代的基础 MCU 设计也很有可能与多核服务器处理器集成在一起，或者仅作为可扩展产品集中的一个点存在；无论哪种方式，访问内存的一致方法对需要编写或移植代码的最终用户都是有益的。

我在追溯计算 SE上提出了一个关于寄存器大小的问题，以跟进这个问题的历史方面。

基本答案是“因为这是一个字节的长度”。使用大量已建立的代码做出该假设，破坏它会导致各种问题。

早在早期，没有既定的代码体。如其他答案所示，处理器经常会使用各种奇怪的架构。然而，当 16 位处理器问世时，已经有足够的代码假设 8 位数据的可用性，如果不能使这变得容易，将成为采用的真正障碍。

每个地址有一个 32 位字不会对内存速度造成任何不利影响。在 32 位系统上，较低的 2 个地址位通常不会进入内存。处理器通常会读取整个 32 位字并在该字中选择（或屏蔽）它需要的 8 位字节。只要您的地址空间可以存储足够的数据（在 32 位系统中限制为 2^32 字节），就不用担心了。事实上，在许多 16 位/32 位处理器上，处理字节值比处理原生字长值需要更长的时间——读取 32 位字并丢弃该字的一部分显然需要额外的操作，与仅读取 32 位字相比。

相反，如果您有一个需要有效使用内存的系统，那么您需要能够访问单个字节。如果你不能，你将耗尽内存。考虑到这一点，能够引用单个字节显然是必要的，因此将内存按字节分块是有意义的。