blocks|key|1651866|text|指令将永久存储在海量存储设备上的二进制可执行文件中。当程序执行时，可执行文件的内容被加载到主存储器(RAM)中。一般来说，CPU和RAM之间的所有通信都通过缓存；可执行文件所包含的指令也是如此。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1651867|缓存可以包含指令、数据或两者。对于Intel，有两个L1缓存:数据的L1d缓存和指令的L1i缓存；L2和L3是共享的。以下图像非常清楚地说明了这一点：|1651868|​|1651869|📷|atomic|offset|length|1651870|1651871|图像源|1651872|这是简单的答案。如果你想学得更多，周围有很多好材料。Ulrich的每个程序员都应该知道关于内存的事情是一个伟大的阅读。|1651873|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://developer.qcloudimg.com/http-save/yehe-900000/a6a607dc024be3c420cc5cf4b83e53d7.png|imageAlt|1|LINK|MUTABLE|url|https://lwn.net/Articles/252125/|2|https://lwn.net/Articles/250967/^0|0|0|0|0|1|0|0|0|0|3|1|0|X|H|2|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|18|8|@]|9|@$I|19|J|1A|1|1B]]|A|$]]|$1|K|3|E|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@]|9|@$I|1E|J|1F|1|1G]]|A|$]]|$1|N|3|O|5|6|7|1H|8|@]|9|@$I|1I|J|1J|1|1K]]|A|$]]|$1|P|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W|X|-4]]|Y|$5|Z|T|10|A|$11|12]]|13|$5|Z|T|10|A|$11|14]]]]

The instructions are stored permanently in the binary executable file on your mass storage device. When the program is executed, the contents of the executable file are loaded into primary memory (RAM). Generally speaking, all traffic between the CPU and RAM goes through a cache; so do the instructions contained by the executable.

A cache may contain instructions, data, or both. In the case of Intel CPUs, there are two L1 caches: L1d for data and L1i for instructions; L2 and L3 are shared. The following image illustrates this quite clearly:

<a href="https://i.stack.imgur.com/d4rQO.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/d4rQO.png" alt="Cache hierarchy"></a>

<a href="https://lwn.net/Articles/252125/" rel="nofollow noreferrer">Image source</a>

That is the short answer. If you wish to learn more, there is plenty of good material around. Ulrich Drepper's <a href="https://lwn.net/Articles/250967/" rel="nofollow noreferrer">What every programmer should know about memory</a> is a great read for one.

blocks|key|806543|text|磁盘上的可执行文件逻辑上是内存-映射到新进程的虚拟地址空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|806544|与虚拟内存一样，触摸可执行文件的4k页可能会触发页面错误，如果数据不是DRAM+(硬页错误)，或者是DRAM(硬页错误)，但是HW页表没有“连接”该页面。软页错误在每次重复运行时仍可能发生，因为OSes通常“懒得”连接页表，即使文件数据位于内核的分页缓存中。|806545|(x86使用4kiB虚拟内存页。这是一个常见的页面大小，但是其他一些ISA会使用或可以使用其他页面大小，比如8k或16k)。|806546|内核可以通过确保至少包含进程入口点的页面在进入用户空间之前从磁盘加载并连接起来来进行优化。否则，它将只是页面错误，立即返回到内核。例如，早期的Linux，比如0.11，就是这样工作的，这是在开发之前的一个工作步骤。|806547|当数据在DRAM中时，执行工作由CPU执行-通过L1i+/+L2+/+L3缓存进行代码提取。这与数据加载完全一样，但假设机器具有拆分的L1缓存，则需要通过L1+i-缓存而不是L1+D-缓存。缓存的外部级别(假设它们存在)几乎总是统一的。现代x86+CPU和其他高端芯片(如POWER+)通常都有3级缓存，通常L1i/d和L2都是私有的，有一个大型共享L3。否则，您可能只有私有的L1i/L1d和共享的L2，或者在一个单核系统中可能只有1到2个级别的缓存。|offset|length|style|BOLD|806548|这些缓存在大多数CPU上的行大小为64字节(包括自P4+/Core2左右以来的所有P4+CPU)。缓存丢失没有错误，核心只需等待线路到达即可。如果仍有任何无序执行仍未完成，则在代码缓存丢失正在运行时仍有可能发生这种情况。但是，否则CPU就会被困在没有任何事情可做的地方。|806549|(TLB失误也是一回事。)大多数ISAs都有硬件页面遍历，这使得它对软件透明，但是一个iTLB缺失也可以同样地延缓指令的取取，而不需要做任何排队的工作。因此，i-cache+/i丢失甚至比数据缓存/+d-TLB遗漏的情况还要糟糕，在这些遗漏/未命中/未命中以及无序执行的情况下，可以继续进行一些有用的工作。)|806550|在现代x86+CPU中，解码指令被缓存在一个非常小的非常快的"uop缓存“中，以及在L1i缓存中缓存机器代码字节。|806551|奔腾4没有L1i缓存，只有一个跟踪缓存，但效果不太好。而且，它没有足够的晶体管或电源预算，无法在跟踪缓存丢失的情况下快速建立跟踪。这是NetBurst微架构的几个主要缺点之一。|806552|entityMap^0|0|0|0|0|0|13|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@$J|12|K|13|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|16|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|17|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|W|$]]

Your executable on disk is logically memory-mapped into the virtual address space of a new process.

As usually with virtual memory, touching a 4k pages of the executable may trigger a page fault if the data isn't actually in DRAM (hard page fault) or if it is but the HW page tables haven't "wired" that page. Soft page faults might still happen on each repeated runs because OSes are typically "lazy" about wiring up page tables, even when file data is in the kernel's pagecache.

(x86 uses 4kiB virtual memory pages. It's a common page size but some other ISA do or can use other page sizes like 8k or 16k.)

The kernel may optimize by making sure at least the page containing the process entry point is loaded from disk and wired up before entering user-space. Otherwise it will just page-fault right away back to the kernel. e.g. very early Linux, like 0.11, worked this way, as a get-it-working step in development before making it good.

<hr>

When data is in DRAM, execution works by the CPU doing code-fetch through L1i / L2 / L3 cache. This is exactly like data loads, but goes through L1 I-cache instead of L1 D-cache, assuming a machine with split L1 caches. Outer levels of cache (assuming they exist) are almost always unified. Modern x86 CPUs and other high-end chips like POWER do typically have 3 levels of cache, usually L1i/d and L2 are per-core private, with a large shared L3. Otherwise you might have just private L1i/L1d and shared L2, or in a single-core system maybe just 1 or 2 levels of cache.

These caches have a line size of 64 bytes on most CPUs (including all x86 CPUs since P4 / Core 2 or so). Cache misses don't fault, the core just has to wait for the line to arrive. If there's any out-of-order execution still not done, it can still be happening while a code-cache miss is in flight. But otherwise the CPU is stuck with nothing at all to do.

(TLB misses are also a thing. Most ISAs have hardware page-walk that makes it transparent to software, but an iTLB miss can similarly stall instruction fetch leaving the CPU without any queued up work to do. So i-cache / i-TLB misses are even worse than data-cache / d-TLB misses where miss-under-miss / hit-under-miss, and out-of-order execution, can let some useful work continue.)

<hr>

In modern x86 CPUs, decoded instructions are cached in a small, very fast "uop cache", as well as caching the machine-code bytes in L1i cache.

Pentium 4 didn't have an L1i cache, only a trace cache, but that didn't work out very well. And it didn't have the transistor or power budget for enough decoders to build traces fast on trace-cache misses. This was one of several major downsides of the NetBurst microarchitecture.

If i were to run a binary executable program, do all of the instructions have to be stored in the instruction cache? Is the instruction cache a location in one of the L1, L2, or L3 CPU caches or is it a different entity? I am not very clear on what physically happens when i run an executable and any sort of clarity would be greatly appreciated.

How and where are instructions cached?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如果我要运行一个二进制可执行程序，是否所有的指令都必须存储在指令缓存中？指令缓存是L1、L2或L3 CPU缓存中的一个位置，还是一个不同的实体？当我运行一个可执行文件时，我不太清楚物理上会发生什么，任何形式的清晰都是非常感激的。

问指令是如何和在哪里缓存的？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问指令是如何和在哪里缓存的？EN