当前位置：文江博客话题详情

内存块和标签

发布于 2025-02-13 09:11:35 字数 320 浏览 0 评论 0原文

假设我们有一个带有缓存的CPU，该CACHE由128个块组成。 8个字节可以将内存保存到每个块上。我可以找到每个地址属于哪个块？另外，每个地址标签是什么？

以下是我的思维方式。

以32位地址1030为例。如果我做1030 * 4 = 4120，则具有字节格式的地址。然后，我以8byte格式4120 /8 = 515。

然后我做515％128 = 3，即（8byte地址）％（块数）（块数）以找到此地址已打开的块（块编号3）。

然后，我做515 /128 = 4，以发现地址在第3号块上的可能性。那么标签= 4。

我的思维方式正确吗？任何评论都受到欢迎！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

深海少女心 2025-02-20 09:11:35

我们一般知道的是：

一个缓存将地址分解为字段，即：标签字段，索引字段和块偏移字段。＆nbsp;对于任何给定的高速缓存，场尺寸都是固定的，并且知道它们的宽度（位数）使我们可以像缓存一样分解地址。

一个简单数字的地址：

+---------------------------+
|          address          |
+---------------------------+

我们将地址视为未签名的整数，而用于地址的位数为地址空间大小。＆nbsp;由于缓存将其分解为字段：

+----------------------------+
|    tag    | index | offset |
+----------------------------+

每个字段使用整数数量的宽度。

我们从您的问题陈述中知道的：

块大小为8个字节，因此
- 块偏移字段宽度为log ₂（字节中的块大小）
地址空间（地址中的位总数）为32位，因此/p>
- 标签宽度 +索引宽度 +偏移宽度= 32

因为没有给出有关关联性的信息，我们应该假设高速缓存是直接映射的。＆nbsp;没有提供相反的信息，并且直接映射的卡车在课程的早期很常见。＆nbsp;我将验证或否则要明确指出直接映射缓存的假设。

因此，直接映射的缓存有128个块
- 缓存数组中有128个索引位置。
- （对于2条或4-方法，我们将分别除以2或4）
给定的128个索引位置
- 索引字段宽度为log ₂（索引位置的数量）
知道索引字段宽度，块偏移场宽度和总地址宽度，我们可以计算标签字段宽度
- 标签字段宽度= 32-索引字段宽度 - 块偏移字段宽度

只有当您具有这样的字段宽度时，块偏移范围宽度才有意义尝试解码给定的地址并提取该地址的字段的实际值。

由于有三个字段，因此提取的首选方法是简单地以二进制编写地址，然后根据字段及其宽度对位进行分组。

（可以使划分和模量可以正常工作，但使用（a）3个字段，（b）使用数学中的索引字段在中间有一个更复杂的复杂，因为要获得索引，我们必须分开（要删除索引块偏移量）和模量（要删除标签位），但这相当于其他方法。）

评论您的推理：

您需要知道1030是否为十进制或十位。＆nbsp;编写十进制符号的地址是不寻常的，因为十六进制符号将转换为二进制符号（因此，各个位字段）变得容易得多。＆nbsp; nbsp; （某些教育计算机使用小数符号用于地址，但是它们通常具有小得多的地址空间，例如3个小数位，当然不是32位地址空间。）
以32位地址1030为例。如果我做1030 * 4 = 4120我具有字节格式的地址。
除非某事确实与众不同，否则地址1030已经以字节格式了 - 所以不要这样做。
然后我以8byte格式转动4120 /8 = 515。< / p>
缓存的8个字节构成了块偏移字段，用于解码地址。＆nbsp;需要将地址解码为3个字段，不一定将其分开。

同样，关键是首先计算块大小，然后是索引大小，然后是标签大小。＆nbsp;进行给定的地址，转换为二进制，然后将位分组以了解二进制中的标签，索引和阻止偏移值（然后也许将这些值转换为十六进制（或者如果需要的（如果需要的（小数））））。

What we know generically:

A cache decomposes addresses into fields, namely: a tag field, an index field, and a block offset field. For any given cache the field sizes are fixed, and, knowing their width (number of bits) allows us decompose an address the same way that cache does.

An address as a simple number:

+---------------------------+
|          address          |
+---------------------------+

We would view addresses as unsigned integers, and the number of bits used for the address is the address space size. As decomposed into fields by the cache:

+----------------------------+
|    tag    | index | offset |
+----------------------------+

Each field uses an integer number of bits for its width.

What we know from your problem statement:

the block size is 8 bytes, therefore
- the block offset field width is log₂( block size in bytes )
the address space (total number of bit in an address) is 32 bits, therefore
- tag width + index width + offset width = 32

Since information about associativity is not given we should assume the cache is direct mapped. No information to the contrary is provided, and direct mapped caches are common early in coursework. I'd verify or else state the assumption explicitly of direct mapped cache.

there are 128 blocks, therefore, for a direct mapped cache
- there are 128 index positions in the cache array.
- (for 2- way or 4- way we would divide by 2 or 4, respectively)
Given 128 index positions in the cache array
- the index field width is log₂( number of index positions )
Knowing the index field width, the block offset field width, and total address width, we can compute the tag field width
- tag field width = 32 - index field width - block offset field width

Only when you have such field widths does it make sense to attempt to decode a given address and extract the fields' actual values for that address.

Because there are three fields, the preferred approach to extraction is to simply write out the address in binary and group the bits according to the fields and their widths.

(Division and modulus can be made to work but with (a) 3 fields, and (b) the index field being in the middle using math there is a arguable more complex, since to get the index we have to divide (to remove the block offset) and modulus (to remove the tag bits), but this is equivalent to the other approach.)

Comments on your reasoning:

You need to know if 1030 is in decimal or hex. It is unusual to write an addresses in decimal notation, since hex notation converts into binary notation (and hence the various bit fields) so much easier. (Some educational computers use decimal notation for addresses, but they generally have a much smaller address space, like 3 decimal digits, and certainly not a 32-bit address space.)
Take the 32bit address 1030 for example. If I do 1030 * 4 = 4120 I have the address in a byte format.
Unless something is really out of the ordinary, the address 1030 is already in byte format — so don't do that.
Then I turn it in a 8byte format 4120 / 8 = 515.
The 8 bytes of the cache make up the block offset field for decoding an address. Need to decode the address into 3 fields, not necessarily divide it.

Again the key is to first compute the block size, then the index size, then the tag size. Take a given address, convert to binary, and group the bits to know the tag, index, and block offset values in binary (then maybe convert those values to hex (or decimal if you must)).

回复收藏 0 原文

~没有更多了~