【问题标题】:How processor read memory? [duplicate]处理器如何读取内存? [复制]
【发布时间】:2020-02-09 00:38:32
【问题描述】:

我正在尝试学习计算机如何安排和处理内存,但我不明白对齐的概念。

例如,在 32 位架构中,如果短(2 个字节)完全适合单个 32 位字,为什么我们说它们是未对齐的,即使它们不位于偶数地址?

因为如果处理器按 32 位读取 32 位,并且 char 位于地址 x0 处,那么后面跟着一个 short(地址 x01 和 x02),然后是另一个 char (x03)。突然就没有问题了,因为处理器读取了4个字节,所以不会有cut数据。

所以short 是对齐的,不是吗?

【问题讨论】:

  • 如果 short 不在字节 1 和 2 中而是在字节 3 和 4 中会发生什么?
  • 会有一个问题,因为在这种情况下处理器必须读取 2 次才能获取信息。但在我指定的情况下,没有不对齐
  • 基本上是后续how does the processor read memory?的副本

标签: c memory cpu-architecture ram memory-alignment


【解决方案1】:

这个问题建议一个处理器有 32 根线连接到总线,用于数据,可能还有其他线用于控制。当它想要从内存中获取数据时,它会在总线上放置一个地址,请求从内存中读取数据,等待数据,然后通过这 32 根线读取数据。

在典型的处理器设计中,这 32 根线连接到一些临时内部寄存器,该寄存器本身也连接到其他寄存器。将这 32 位作为一个块移动很容易,每个位都在自己的线路上。

如果我们想移动 32 位中的一些位,我们需要移动它们。这可以通过各种硬件来完成,例如我们将位放入的移位单元,请求一定量的移位并从中读取结果。在内部,该变速单元将有各种连接和开关来完成其工作。

通常,这样的移位单元将能够将八个位从四个位置中的任何一个(从位 0、8、16 或 24 开始)移动到基本位置 (0)。这样,诸如“加载字节”之类的指令可以通过从内存中读取 32 位来实现(因为它仅以 32 位块的形式出现),然后使用移位单元获取所需的字节。该移位单元可能没有将任意一组位(例如,从 7、13 或 22 开始)移动到基本位置所需的电线和开关。那将需要更多的电线和开关。

处理器还需要能够执行加载 16 位指令。为此,移位单元将能够将 16 位从位置 0 或 16 移动到位置 0。当然,工程师可以将其设计为也将 16 位从位置 8 移动到位置 0。但这需要更多的电线和开关,这会增加成本金钱、硅和能源。在许多处理器中,都认为这笔费用不值得,因此没有实现该功能。

因此,硬件在加载过程中根本无法将数据从字节 1 和 2 转移到字节 0 和 1。 (处理器中可能还有其他移位器,例如在用于实现移位指令的通用逻辑单元中,但它们通常是独立的,并通过指令调度和控制机制访问。它们不在用于从加载的组件行中记忆。)

【讨论】:

  • 感谢您的解释。但是,如果我理解正确,处理器将采用这 32 位并将它们解释为单个值。但这是否意味着内存中的一个 char 会占用 8 个字节的空间,对吧?
  • 许多处理器允许不对齐的访问,但会降低性能。
  • @Progear 不,根据定义,一个字节的读取或写入总是对齐的。
  • 为什么?因为如果我的处理器一次占用 32 个字节,它会意外占用其他字符并具有错误的值!不是吗?
  • @Progear:当进程读取字节时,它将读取字节所在的 32 位字。这 32 位从总线进入与负载一致的移位单元单元。所需的 8 位来自移位单元,并进入它们被加载到的通用处理器寄存器(或等效寄存器)。处理器可以设计成与读取整个 32 位字相比没有性能损失——移位单元可能始终是加载路径的可用部分。
【解决方案2】:

对齐是一个定义。假设 8 位字节并且存储器是字节可寻址的。 8 位字节(无符号字符)不能不对齐。要对齐的 16 位半字必须具有 lsbit 零。一个 32 位字低两位零,64 位双字三位零,依此类推。因此,如果您的 16 位无符号 short 在奇数地址上,则它是未对齐的。

“32 位系统”并不意味着 32 位总线,总线宽度不一定与处理器寄存器的大小或指令大小等相匹配。没有理由做出这样的假设。话虽如此,如果您在谈论 MIPS 或 ARM,那么是的,对于它们的 32 位寄存器处理器,总线很可能是 32 位或 64 位,对于 64 位处理器,可能是 64 位或 128 位,可能是 64 位。但是 x86 有 8 位指令和 8、16、32、64 位寄存器和可变长度指令,当你把它可能占用的字节加起来时,没有办法对它的大小进行分类,它是一个 8 位处理器,它的 8 位指令 32 或 64 是由于其较大的寄存器大小或 128,256,512 等由于其总线大小?

你提到了 32,让我们坚持下去。我想遍历一个字节数组,我想做写。我有一个 32 位宽的数据总线,这是您今天看到的典型设计之一。假设另一边是一个高速缓存,它由 32 位宽的 sram 构建以与处理器端总线对齐,我们不必担心 dram 在另一边是如何实现的。因此,您可能会拥有一条写数据总线、一条读数据总线,以及单独的写地址和读地址,或者一个地址总线,可以指示读/写事务。

就总线而言,所有事务都是 32 位的,您不一定希望未使用的字节通道浮动,z 状态,您希望它们对于该总线上的有效时钟为高或低(有效时钟之间循环确保总线可以达到高阻抗)。

读取事务通常是并且假设是与总线宽度对齐的地址,因此是 32 位对齐的地址(在总线上或在远端)。读取时通常没有启用字节通道的概念,处理器在内部隔离感兴趣的字节并丢弃其他字节。有些在地址总线上有一个有意义的长度字段。加上缓存控制信号和其他信号。

对齐的 32 位读取会说地址 0x1000 或 0x1004 长度为 0 (n-1),地址总线使用唯一的事务 id 进行握手,稍后在读取数据总线上理想情况下单个时钟周期将包含该具有该 id 的 32 位数据,处理器看到并完成事务(可能需要更多握手)并提取所有 4 个字节并按照指令所说的对它们执行操作。

在 32 位边界上对齐的 64 位访问将具有一个长度,一个地址总线握手,两个时钟周期的数据在读取数据总线上。 0x1000 或 0x1002 处的 16 位对齐事务将假设读取 0x1000 并且处理器将丢弃通道 0 和 1 或通道 2 和 3,一​​些总线设计对齐较低通道上的字节,因此您可能会看到总线对于 16 位读取,这两个字节总是在通道 0 和 1 上返回。

未对齐的 32 位读取需要两个总线周期、两倍的开销、两倍的时钟数 0x1002 32 位读取是一次 0x1000 读取,处理器保存 2 个字节,然后是 0x1004 读取,处理器保存两个这些字节中的一个将它们组合成 32 位数字,然后按照指令的说明执行操作,而不是 5 或 8 或任何该总线的最小值,现在它是原来的两倍,并且可能不是交错的,而是背靠背的。

地址 0x1001 处未对齐的 16 位可能是单个 32 位读取,但地址 0x1003 处未对齐的 16 位读取是两个事务,现在是时钟的两倍,一个位于 0x1000 处,另一个位于 0x1004 处,每个事务节省一个字节。

写入相同,但有额外的惩罚。对齐的 32 位写入,例如在 0x1000 一个总线事务、地址、写入数据,完成。在本例中,高速缓存为 32 位宽,可以在一个 sram 事务中简单地将这 32 位写入 sram。一个未对齐的 32 位写入比如在 0x1001,将是两个完整的总线事务,正如预期的那样,需要两倍的总线时钟,但 sram 也需要两个或更多的时钟,因为您需要读取-修改-写入您的 sram不能只写。为了将 0x1001 写入 0x1003 字节,您需要从 sram 读取 32 位,更改其中三个字节而不更改较低的字节,然后将其写回。然后,当另一个事务进入时,您写入 0x1004 字节,同时将其他三个字节保留在该 sram 位置。

所有字节写入都是一个单一的总线事务,但也都会产生读取-修改-写入。请注意,根据总线需要多少时钟以及一次可以进行多少事务,sram 的读取-修改-写入可能是不可见的,您可能无法以足够快的速度将数据获取到缓存中总线事务必须等待 sram 读取-修改-写入,但是在另一个类似的问题中,因为这里已经被问了很多次,所以有一个平台可以证明这一点。

所以你现在可以告诉我 16 位写事务将如何进行,它们还会在缓存中为每个事务产生读-修改-写,如果地址是 0x1003,那么你会得到两个总线事务和两个读-修改-写。

缓存的优点之一是即使 DRAM 有 8、16、32 位部分(计算一个 DRAM 棒上有多少芯片,通常是 8 或 9、4 或 5 或 2 或 3 或一些其中的倍数。8 可能是 64 位宽总线每部分 8 位、16 个 64 位宽、每部分 8 位、双列等)事务以 32 或 64 位宽度完成,这就是重点的缓存。如果我们必须以 dram 的慢速进行读取-修改-写入,这将是可怕的,我们以高速缓存/SRAM 速度读取-修改-写入,那么所有事务、高速缓存行驱逐和填充都是DRAM 总线宽度,因此每个高速缓存行 64 或 2x64 或 4x64 等。

【讨论】:

    猜你喜欢
    • 2020-05-24
    • 2013-04-09
    • 2020-05-28
    • 2011-06-08
    • 1970-01-01
    • 2020-09-28
    • 1970-01-01
    • 2018-07-14
    • 1970-01-01
    相关资源
    最近更新 更多