系统与基础设施yosefk.com
“高层 CPU”挑战（2008）
The “high-level CPU” challenge (2008)
2015 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者向 CPU 设计者发起挑战：能否造出直接高效支持高级语言语义的“高级 CPU”，而不是让编译器费力把高级结构翻译成底层指令？文章论证许多高级语言特性（如垃圾回收、闭包）在硬件层面有无法靠逻辑消除的真实成本。多年后作者在评论中反思，认为当时语气过激且论断有所夸大，正确的方向是像 C+Unix/RISC+MMU 那样精心划分软硬件职责，而非用硬件直接解释高级语言。
为什么经久不衰：它触及“硬件该为高级语言做什么”这一根本问题，随着安全性和内存问题推动 CPU 架构演进（如 CHERI、硬件内存标签），至今仍是活跃话题。
HN 评论精选
作者自我修正：硬件直接解释高级语言是死路，正确方向是软硬件职责的合理划分
作者：现在回头看，我觉得除了语气有点冲，论断也有些过头了。虽然很多“高级”结构确实有硬件逻辑无法完全消除的成本，但针对特定高级语言编程模型，硬件确实能做很多事让软件更轻松，而我并非这方面的专家。我真正的兴趣在加速器开发，从 GPU 往下走，编程模型比 C 更底层更棘手。不过我仍认为 Reduceron 那种在硬件里最直接地做函数式编程是资源的巨大浪费，整体效率上肯定输给面向冯·诺依曼机器的好编译器。正路不是做硬件解释器——那不比给处理器加一条 for 循环指令来更好支持 C 强多少——诀窍在于像 C+Unix/RISC+MMU 收敛到的那样，仔细划分软硬件职责。
yosefk查看英文原文
Author here. I think today that apart from making my case in a bit of an obnoxious tone, I also somewhat overstated it: while it's true that many "high-level" constructs do have a cost that will not magically go away due to any logic built into hardware, at least not fully, it is also ought to be true that a lot can be done in hardware to make software's life easier given a particular HLL programming model, and I'm hardly an expert on this. My true interests are in accelerator development so starting at the GPU and further away from the CPU and so lower level and gnarlier than C in terms of programming model. I will however say that the Reduceron and in general the idea of doing FP in hardware in the most direct way are a terrible waste of resources and I'm pretty sure it loses to a good compiler targeting a von Neumann machine on overall efficiency. The way to go is not make a hardware interpeter, that is no better than a processor with a for loop instruction added to better support C. The trick is to carefully partition sw and hw responsibilities as in the model to which C+Unix/RISC+MMU converged to.
历史证明“高级指令”屡屡失败，但零成本溢出检查等安全特性值得探索
“更高级指令”的历史并不光彩。DEC VAX 的汇编语言本想让汇编程序员日子好过些，却拖慢了机器；Intel IAPX 432 花哨功能一堆，但慢得离谱；大量寄存器的 RISC 机器后来发现没那么有用，寄存器保存恢复开销太大。RISC 在单周期单指令时是赢的，到超标量就输了。跑 Forth 或 Java 字节码这类栈式机也造过，但难以超标量化。近期有用的特性应该是整数溢出的零成本硬件异常——这在 Java 和 Rust 里都是错误，却因有性能代价常在编译期被关掉。问题是人们需要能展开栈并恢复，这意味着精确异常和大量编译器支持。零成本的下标越界检查也是一大步，但那需要额外的边界信息，通常意味着延迟。
Animats查看英文原文
The history of "higher level" instructions isn't good. The DEC VAX had an assembly language intended to make life easier for assembly programmers, but it slowed the machine down. The Intel IAPX 432 had lots of bells and whistles, but was really slow. The RISC machines with lots of registers turned out not to be all that useful, and too much register saving and restoring was required. RISC is a win until you want to go superscalar and have more than one instruction per clock. Then it's a lose. Stack machines that run some RPN form like Forth or Java code have been built, but don't go superscalar well. A useful near-term feature would be zero-cost hardware exceptions on integer overflow. This is an error in both Java and Rust, and tends to be turned off at compile time because it has a performance penalty. The problem is that people will want to be able to unwind and recover, which means exact exceptions and a lot of compiler support for them. If you could figure out how to do zero-cost subscript checking, that would be a step forward. That check needs additional info about bounds, which usually means a delay. I used to be a fan of schemes for safely calling from one address space to another. i386 almost has this, with call gates, which don't quite do enough to be useful. A few machines have had hardware context switching, but that hasn't been a big performance improvement. All that has to be tightly integrated with the OS or it's a lose. It's an enhancement to Plan 9, not anything anybody uses. The same is true of fancy schemes for inter-CPU communication, but that probably needs more attention. Like it or not, we have to figure out what to do with large numbers of non-shared-memory CPUs. Some way to set up memory-safe message passing between non-shared-memory CPUs without involving the OS after setup would be useful. An IOMMU that allows drivers in user space with minimal performance degradation is a good thing. Those exist.
提出若干具体的高级 CPU 设计思路：显式依赖图、只读标注、细粒度并行等
一些零散想法：把数据依赖图直接暴露给处理器，而不是让它从指令中推断；标注只读数据以减少核间通信；提供更廉价（但更受限）的并行机制，让单核并行处理多个相关的小任务；增加图遍历指令，CPU 可根据图在内存中的实际布局优化遍历顺序以提升缓存局部性；类似 map & reduce 的指令，对数据列表应用小的纯函数，并可并行执行。
piinbinary查看英文原文
Some assorted ideas: * Expose the data dependency graph directly to the processor, rather than forcing the processor to infer it from the instructions. * Annotate when data is read-only, to reduce communication between cores (for the sake of avoiding latency, not for bandwidth savings). * Add a mechanism for much cheaper (if more limited) parallelism where a single core would work on multiple, related thunks in parallel, even if those units of work would be far too small to be worth coordinating with another thread to offload. This would likely be largely implicit, taking advantage of the first feature. * Instructions for graph traversal. The CPU could (for some uses) order the traversal in a way that improves cache locality, based on how the graph is actually laid out in memory (and prefetch uncached nodes while working on cached ones). * Something like map & reduce, where you can apply a small (pure) function to a list of data. Again, this would likely be done in parallel.
反其道而行：与其硬件支持高级语言，不如削减硬件功能、把更多逻辑交给软件
1. 去掉缓存一致性协议（换成缓存操作/核间通信指令）；2. 去掉虚拟内存（什么都不换）。我不是 CPU 设计师，但据我理解，去掉功能能让 CPU 更密更快。高级语言不需要这两个功能，因为高级语言不向程序员暴露“内存”。不过我完全同意作者的核心观点：我们不该在硬件里实现高级特性，恰恰相反，硬件应尽量少做，把尽可能多的东西移到软件里。如果 Intel 允许第三方生成微码，我们还能走得更远。
catern查看英文原文
1. Eliminate cache coherency protocols (replacing it with cache manipulation/inter-CPU communication instructions) 2. Eliminate virtual memory (replacing it with nothing) I'm not a CPU designer, but my understanding is that removing features allows for a denser/faster CPU. Well, these are two features that a suitably high-level language has no need for, because a high-level language doesn't expose "memory" to the programmer. Edit: Though, I 100% agree with what I believe is the core point of the author. We should not implement high-level features in hardware. In fact we should implement as little as possible in hardware, moving as much as possible into software. If Intel would let third parties generate microcode for their CPUs, we could move a lot further in that direction...
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选