小编Yuj*_*jie的帖子

我已经在github上发布了一个Release v1.0.0。并在 Zenodo 获得了 DOI。但现在我添加了一些脚本并发布了v1.0.1。但是当我在Zenodo中检查它时，它仍然显示v1.0.0。如何更新此版本并获取 DOI？

存储库是https://github.com/Yujie-Cui/WB-channels

另外，当我点击页面前面的上传时，它显示

这里公众显示0。但是草稿显示1。草稿显示我发布的内容。但我已经获得了最早版本的DOI。

谢谢！

我正在学习AMD处理器L1缓存的访问过程。但我反复看了AMD的手册，还是看不懂。

我对Intel的L1数据缓存的理解是：
L1缓存是虚拟索引和物理标记的。因此，利用虚拟地址的索引位来查找对应的缓存集合，最终根据标记确定缓存集合中的哪条缓存行。
（Intel 使他们的 L1d 缓存足够关联且足够小，索引位仅来自页内偏移，与物理地址相同。因此，他们获得了 VIPT 的速度，没有任何别名问题，表现得像 PIPT .)

但AMD使用了一种新方法。在 Zen 1 中，它们有一个 32 KB、8 路组关联 L1d 缓存，该缓存（与 64KB 4 路 L1i 不同）足够小，可以在没有微标签的情况下避免别名问题。
来自AMD 2017年软件优化手册，第2.6.2.2节“AMD系列17h处理器的微架构”（Zen 1）：

L1 数据缓存标签包含一个基于线性地址的微标签 (utag)，它使用最初用于访问缓存行的线性地址来标记每个缓存行。负载使用此 utag 来确定使用其线性地址读取缓存的哪条路，该线性地址在通过 TLB 确定负载的物理地址之前可用。utag 是负载线性地址的哈希值。这种基于线性地址的查找使得能够在读取高速缓存数据之前非常准确地预测高速缓存行的定位方式。这允许负载仅读取单个缓存方式，而不是全部 8 个。这可以节省电量并减少存储体冲突。

utag 有可能在两个方向上都是错误的：它可以在访问将丢失时预测命中，并且在访问可能命中时预测丢失。无论哪种情况，都会发起对 L2 缓存的填充请求，并且当 L2 响应填充请求时更新 utag。

当两个不同的线性地址映射到同一物理地址时，就会发生线性别名。这可能会导致加载和存储别名缓存行的性能下降。对在 L1 DC 中有效但在不同线性别名下的地址的加载将看到 L1 DC 未命中，这需要发出 L2 缓存请求。延迟通常不会大于 L2 缓存命中的延迟。然而，如果多个别名加载或存储同时进行，则它们每个都可能会遇到 L1 DC 缺失，因为它们使用特定的线性地址更新 utag 并删除另一个能够访问高速缓存行的线性地址。

如果两个不同的线性地址没有别名到同一物理地址，那么它们也可能在 utag 中发生冲突（如果它们具有相同的线性哈希）。在给定的 L1 DC 索引 (11:6) 下，任何时候都只能访问具有给定线性哈希的一个缓存行；任何具有匹配线性散列的缓存行在 utag 中都被标记为无效并且不可访问。

1. utag在两个方向上都有可能出错

第二段这句话的具体场景是什么？什么情况下命中预测为未命中，未命中预测为命中？当CPU从内存访问数据到cache时，会根据utag计算出一条cache way。然后就把它放在这里？即使其他缓存路为空？

2. 当两个不同的线性地址映射到同一物理地址时，就会发生线性别名。

不同的线性地址如何映射到同一个物理地址？

3. 然而，如果多个别名加载或存储同时进行，则它们每个都可能会遇到 L1 …