Putting the "You" in CPU — Chapter 7: Epilogue

Ch. 7 — Epilogue / 尾声

原文：Putting the "You" in CPU — Chapter 7: Epilogue
作者：Lexi Mattick & Hack Club（2023 年 7 月）
来源：https://cpu.land/ ，源码以 MIT 许可证开源（ https://github.com/hackclub/putting-the-you-in-cpu ）
本文件为原文 + 简体中文对照译本，依 MIT 许可证保留署名。

---

Congratulations! We have now firmly placed the "you" in CPU. I hope you had fun.

恭喜！我们现在已经牢牢地把“你”（you）放进了 CPU 之中。希望你玩得开心。

I will send you off by emphasizing once more that all the knowledge you just gained is real and active. The next time you think about how your computer is running multiple apps, I hope you envision timer chips and hardware interrupts. When you write a program in some fancy programming language and get a linker error, I hope you think about what that linker is trying to do.

在送你离开之前，我想再强调一次：你刚刚获得的所有知识都是真实且鲜活的。下一次当你思考计算机是如何同时运行多个应用时，我希望你脑海中浮现出定时器芯片和硬件中断。当你用某种花哨的编程语言写程序、遇到链接器错误时，我希望你会去想那个链接器究竟想做什么。

If you have any questions (or corrections) about anything contained in this article, you should email me at lexi@hackclub.com or submit an issue or PR on GitHub.

如果你对本文中的任何内容有疑问（或需要更正），可以发邮件给我 lexi@hackclub.com，或者在 GitHub 上提交 issue 或 PR。

... but wait, there's more!

……但等等，还没完呢！

Bonus: Translating C Concepts / 附赠：翻译 C 语言中的那些概念

If you've done some low-level programming yourself, you probably know what the stack and the heap are and you've probably used malloc. You might not have thought a lot about how they're implemented!

如果你自己做过一些底层编程，你大概知道栈（stack）和堆（heap）是什么，也大概用过 malloc。但你可能没怎么认真想过它们是如何实现的！

First of all, a thread's stack is a fixed amount of memory that's mapped to somewhere high up in virtual memory. On most (although not all) architectures, the stack pointer starts at the top of the stack memory and moves downward as it increments. Physical memory is not allocated up-front for the entire mapped stack space; instead, demand paging is used to lazily allocate memory as frames of the stack are reached.

首先，一个线程的栈是一块固定大小的内存，被映射到虚拟内存中较高的某个位置。在大多数（尽管并非全部）架构上，栈指针从栈内存的顶部开始，随着它的“增长”而向下移动。物理内存并不会为整个被映射的栈空间预先分配好；相反，系统使用按需分页（demand paging），在到达栈的某一帧时才惰性地分配内存。

It might be surprising to hear that heap allocation functions like malloc are not system calls. Instead, heap memory management is provided by the libc implementation! malloc, free, et al. are complex procedures, and the libc keeps track of memory mapping details itself. Under the hood, the userland heap allocator uses syscalls including mmap (which can map more than just files) and sbrk.

听到像 malloc 这样的堆分配函数并不是系统调用，你可能会感到意外。实际上，堆内存管理是由 libc 的实现提供的！malloc、free 等等都是复杂的过程，libc 自己会追踪内存映射的各种细节。在底层，用户态的堆分配器会使用一些系统调用，包括 mmap（它能映射的不只是文件）和 sbrk。

Bonus: Tidbits / 附赠：花絮

I couldn't find anywhere coherent to put these, but found them amusing, so here you go.

这些内容我找不到一个连贯的地方放，但又觉得挺有意思，所以就放在这里给你了。

Most Linux users probably have a sufficiently interesting life that they spend little time imagining how page tables are represented in the kernel.

Jonathan Corbet, LWN

大多数 Linux 用户的生活大概足够有趣，以至于他们很少花时间去想象页表在内核中是如何表示的。

Jonathan Corbet，LWN

An alternate visualization of hardware interrupts:

关于硬件中断的另一种形象化表达：

A note that some system calls use a technique called vDSOs instead of jumping into kernel space. I didn't have time to talk about this, but it's quite interesting and I recommend reading into it.

提一句：有些系统调用会使用一种叫做 vDSO 的技术，而不是跳进内核空间。我没有时间讲这个，但它相当有趣，我推荐你去读一读。

And finally, addressing the Unix allegations: I do feel bad that a lot of the execution-specific stuff is very Unix-specific. If you're a macOS or Linux user this is fine, but it won't bring you too much closer to how Windows executes programs or handles system calls, although the CPU architecture stuff is all the same. In the future I would love to write an article that covers the Windows world.

最后，回应一下关于“太偏 Unix”的指责：我确实感到有些抱歉，很多与程序执行相关的内容都非常偏向 Unix。如果你是 macOS 或 Linux 用户，那没问题，但这对你理解 Windows 如何执行程序或处理系统调用并没有太大帮助——尽管 CPU 架构方面的内容都是一样的。将来我很想写一篇涵盖 Windows 世界的文章。

Acknowledgements / 致谢

I talked to GPT-3.5 and GPT-4 a decent amount while writing this article. While they lied to me a lot and most of the information was useless, they were sometimes very helpful for working through problems. LLM assistance can be net positive if you're aware of their limitations and are extremely skeptical of everything they say. That said, they're terrible at writing. Don't let them write for you.

在写这篇文章的过程中，我和 GPT-3.5 与 GPT-4 聊了不少。虽然它们经常对我撒谎，而且大部分信息都没什么用，但在梳理问题时它们有时非常有帮助。只要你清楚它们的局限、并对它们说的每句话都极度怀疑，大语言模型的辅助是可以净收益为正的。话虽如此，它们的写作能力糟透了。别让它们替你写作。

More importantly, thank you to all the humans who proofread me, encouraged me, and helped me brainstorm — especially Ani, B, Ben, Caleb, Kara, polypixeldev, Pradyun, Spencer, Nicky (who drew the wonderful elf in chapter 4), and my lovely parents.

更重要的是，感谢所有为我校对、鼓励我、帮我头脑风暴的人们——特别是 Ani、B、Ben、Caleb、Kara、polypixeldev、Pradyun、Spencer、Nicky（第 4 章里那只美妙的精灵就是他画的），以及我可爱的父母。

If you are a teenager and you like computers and you are not already in the Hack Club Slack, you should join right now. I would not have written this article if I didn't have a community of awesome people to share my thoughts and progress with. If you are not a teenager, you should give us money so we can keep doing cool things.

如果你是一名青少年、喜欢计算机、并且还没加入 Hack Club Slack，那你现在就该加进来。要不是有这样一个由厉害的人组成的社区，让我能分享我的想法和进展，我根本不会写出这篇文章。如果你不是青少年，那你应该给我们捐点钱，好让我们能继续做些酷炫的事情。

All of the mediocre art in this article was drawn in Figma. I used Obsidian for editing, and sometimes Vale for linting. The Markdown source for this article is available on GitHub and open to future nitpicks, and all art is published on a Figma community page.

本文中所有平庸的插画都是用 Figma 画的。我用 Obsidian 来编辑，有时用 Vale 来做文风检查（linting）。本文的 Markdown 源码在 GitHub 上公开，欢迎日后的各种挑刺；所有插画都发布在一个 Figma 社区页面上。