## Anthropic 的编译器实验 & 一个“干净房间”Z80/Spectrum 模拟器 Anthropic 最近的任务是让其 Opus 模型使用“干净房间”方法用 Rust 编写一个 C 编译器，作者认为该实验的方法值得怀疑——特别是缺乏对基础编译器优化研究的访问，并且几乎没有指导。受到启发，作者自己进行了一项实验，使用 Claude Code Max 构建 Z80、ZX Spectrum 和 CP/M 模拟器，旨在建立一个更实用的“干净房间”环境。 该过程包括向 Claude 提供详细的规范和相关文档（Z80/Spectrum 规范、测试向量），这些都是 Claude 自己收集的，然后在编码期间严格禁止访问互联网。该代理成功生成了一个功能正常的 Z80 模拟器，通过了关键测试，代码量为 1200 行，注释良好，且人工干预最少。随后是 ZX Spectrum 模拟器，需要更多的指导才能实现磁带加载，最后是 CP/M 环境。 作者得出结论，为代理提供彻底的设计提示和文档至关重要。他们认为 LLM 并非简单地“解压缩”记忆中的代码，而是*组装*知识，基于学习到的模式创建新代码。这使得能够以宽松的 MIT 许可证发布生成的代码，为未来的 LLM 训练数据做出贡献。未来一项比较在*没有*初始文档的情况下结果的实验，可以进一步阐明这一过程。
每日HackerNews RSS
使用 Claude 代码编写一个“干净房间”Z80 和 Spectrum 模拟器。
Implementing a Z80 / ZX Spectrum emulator with Claude Code
2 天前
## Z80/ZX Spectrum 模拟器与 Claude 代码：摘要
Antirez 详细介绍了他使用 Claude 代码创建 Z80/ZX Spectrum 模拟器的实验。他的目标是测试 AI 是否能够以类似于人类程序员的方式生成代码，逐步构建功能并进行调试。结果令人鼓舞——Claude 生成了一个可用的模拟器，尽管在注释和优化方面存在一些不足。
有趣的是，与现有的 Z80 内核进行比较显示，AI 生成的版本速度略慢（1.5%），但注释更好。评论区的讨论强调了对“干净房间”声明的怀疑，考虑到 LLM 拥有庞大的训练数据，可能包括现有的模拟器代码。
许多评论者争论 LLM 是否真的*创造*，还是仅仅重组现有的知识。人们对潜在的抄袭以及 LLM 在真正新颖任务中的局限性表示担忧。其他人分享了类似项目的经验，指出 LLM 经常难以解决复杂、细微的问题，并且可能会发明不存在的功能。尽管存在这些担忧，该实验展示了 AI 辅助编程的潜力，即使对这种辅助的本质仍在理解中。
## Ubicloud：开源云与工程机会 Ubicloud 是一家快速发展的开源云服务提供商，提供计算、存储、CI/CD（通过 GitHub Actions）、Kubernetes、托管 Postgres 和 AI 推理等服务，目前已服务超过 500 家客户。他们正在积极招聘中级软件工程师（2-8 年经验，计算机科学学位优先）来加强他们的 Postgres、GitHub Actions 和 AI 推理团队。 Ubicloud 优先考虑成长型思维，赋能工程师拥有问题并推动解决方案。他们正在开发过程中拥抱 AI，并重视那些展现出积极主动性和具有令人印象深刻的项目经验的候选人。 具有托管 Postgres 或分布式推理架构（特别是 DeepSeek 和 Kimi 等开源模型）的经验将是一个加分项。职位在旧金山、荷兰和土耳其都有，请在申请时说明您期望的工作地点。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Ubicloud (YC W24): 软件工程师 – 土耳其、荷兰、加州，薪资 $95-$250K (ycombinator.com)
1天前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
无法翻译。提供的文本看起来是损坏的PDF文件内容，包含大量乱码和非文本数据，无法被识别为有意义的语言内容。
## 现代科学的无名英雄：琼脂 二战期间，一个令人惊讶的群体——从科学家到童子军——搜寻海岸线寻找含有琼脂的海藻，琼脂是战争时期至关重要的物质。从红藻中提取的琼脂，对于生产疫苗和青霉素至关重要，被列为与铜和橡胶等资源一样的“关键战争物资”。即使是纳粹德国也依赖来自日本的供应。 琼脂的故事始于17世纪的日本厨房，一位厨师偶然发现海藻果冻变成了一种有用的多孔物质。到19世纪末，法尼·安吉丽娜·赫斯意识到它在实验室培养微生物方面的优越品质，彻底改变了细菌学——尽管她的贡献常常被忽视。 近150年来，科学家们一直依赖琼脂的独特性能——其固化、在高温下保持稳定以及易于消毒的能力——来培养细菌和分析DNA。尽管人们一直在寻找替代品，但琼脂在性能、成本和易用性方面仍然无与伦比。 随着全球需求的持续增长，对野生收获海藻的依赖以及最近的供应链问题凸显了保护这种不起眼但不可或缺的物质的必要性。
这个黑客新闻的讨论围绕着琼脂的起源和用途，琼脂是一种从海藻中提取的凝胶状物质。对话源于一篇详细介绍琼脂历史的文章。
用户分享了轶事，包括 1970 年代涉及琼脂和乙醇的实验室恶作剧。一个主要的争论集中在为什么明胶在烹饪中仍然很受欢迎，尤其是在北欧，尽管琼脂在成本、稳定性和饮食兼容性方面具有优势。一些评论员解释说，明胶具有更佳的口感，并且能够模仿骨汤的浓郁度，而琼脂则在需要耐热性和结构完整性的应用中表现出色。
人们还讨论了替代品，例如用于纯素酱汁的甲基纤维素。讨论还涉及“琼脂”一词的词源，揭示了在线游戏 *agar.io* 以这种真实物质命名，以及对在变暖气候下培养琼脂的担忧。最后，一位用户分享了一个家庭故事，讲述了由于父母通过大学实验室工作而获得琼脂，将其作为婴儿食品喂养的故事。
## Julia 性能与权衡：总结
一则 Hacker News 讨论集中在 Julia 的性能上，特别是与 C++、Rust 和 Python 等语言的比较。虽然 Julia 旨在弥合易用性和速度之间的差距，但实现最佳性能需要关注内存分配和就地操作，以最大限度地减少垃圾回收。
关键点包括：Julia 的工具（如 `@time` 和 AllocCheck.jl）比传统的 C++ 分析更容易进行性能调试。然而，避免垃圾回收可能导致复杂的代码，引发一个问题：垃圾回收语言是否是实现最终性能的正确选择。
基准测试表明，Julia 有时落后于 Numba 编译的 Python，这可能是由于并行化开销或 LLVM 优化差异造成的。尽管如此，Julia 在科学计算方面表现出色，这归功于其符合人体工程学的语法、强大的矩阵支持以及 JuMP 等库。在快速原型设计和研究中，它通常优于 C++，因为开发者时间至关重要。虽然编译成独立二进制文件是可能的，但对于许多用户来说仍然很复杂。最终，Julia 为数值工作提供了一种引人注目的替代方案，在性能与更易于开发的体验之间取得了平衡。
## 易混淆字符与字体安全风险：摘要
本研究解决了Unicode安全中的一个漏洞：字符在Unicode定义上不同，但*看起来*却很相似，而纯粹基于数据的方案无法解决这一风险。该工具“confusable-vision”在系统字体中渲染易混淆的字符对，并使用SSIM（结构相似性指标）测量视觉相似度。
该研究分析了`confusables.txt`中的1418个易混淆字符对，发现**96.5%在实际测试中并非高风险**。然而，**82个字符对在至少一种字体中像素完全相同**，构成重大威胁。**西里尔字符是最令人担忧的**，在标准字体中经常与拉丁字母无法区分。罗马数字和希腊字符的风险较低，但存在例外。
重要的是，**字体选择极大地影响风险**。相同字体的比较显示出比跨字体配对更高的相似度得分。某些字体（如Phosphate和Copperplate）明显比其他字体（如Zapfino）更危险。
这表明安全措施应考虑渲染环境——用户和系统使用的字体。建议包括根据相同字体的最大SSIM对风险进行加权，应用每个脚本的阈值，并认识到简单的“易混淆”标记是不够的。该研究提供了可重现的数据和一种用于更细致、字体感知的安全评估的方法。
403 禁止访问
## 80386保护机制：硬件平衡术
本文详细介绍了80386处理器内部复杂的保护机制，这对于启用如Windows和Linux等支持多任务的操作系统至关重要。在80286保护模式存在缺陷的基础上，386引入了分页、扁平的32位地址空间和虚拟8086模式以兼容DOS——这些特性彻底改变了计算。
尽管拥有275,000个晶体管，386通过巧妙的硬件设计实现了这种复杂性。一个关键组件是**保护测试单元 (PTU)**，这是一个专门的PLA，能够快速评估权限和访问规则，避免了缓慢的微代码分支。分段和分页提供了两层内存隔离，通过**TLB**加速处理，并通过硬件**页表遍历器**处理缺失。
该设计利用了诸如**延迟槽**之类的技术来重叠操作，以及**PTSAV/PTOVRR**系统来实现灵活的验证规则。**虚拟8086模式**巧妙地通过PLA重新路由指令，在受保护的环境中模拟实模式，并捕获敏感操作以供操作系统控制。
最终，386的成功在于平衡了用于速度的专用硬件与用于复杂、有状态操作的微代码——这证明了在严格的约束下巧妙的工程设计。
## 80386 保护机制：一则黑客新闻讨论摘要
一则黑客新闻讨论，源于 nand2mario.github.io/80386-protection 的链接，探讨了硬件保护（如保护模式）是否对计算机发展*必要*。讨论的中心在于，基于软件的验证机制，类似于 JVM 或 .NET，是否可以实现可比的安全性和稳定性，从而释放晶体管预算用于性能提升。
有几个例子被引用，说明系统在*没有*硬件保护的情况下成功运行：微软的 Singularity 操作系统，Per Brinch Hansen 的微内核操作系统，TempleOS（尽管被指出完全*缺乏*任何保护），甚至早期版本的 Unix。
讨论要点包括软件定义的 TLB 和内存管理的可能性，性能与安全性的权衡（尤其是在 Spectre 类漏洞和推测执行方面），以及操作系统设计的历史背景。参与者还回忆了早期 Windows 版本（3.0 和 3.11）以及启用 32 位功能的挑战，以及早期 Unix 移植版本，如 SCO Xenix 和 Venix。
最终，该讨论强调了一个计算机体系结构中引人入胜的“如果当初”情景，质疑不同的发展路径是否可以导向同样强大，甚至更高效的系统。
调试器揭秘，第五部分：指令级单步执行和断点
Demystifying Debuggers, Part 5: Instruction-Level Stepping and Breakpoints
2 天前
本文是调试器实现系列的一部分，详细介绍了围绕调试器事件处理构建基本控制循环的过程。此前，调试器只是启动、附加到进程并记录调试事件，而没有交互。现在，目标是添加用于断点和单步执行的用户控制。 核心思想是将事件循环（使用`WaitForDebugEvent`和`ContinueDebugEvent`）包装在一个命令循环中。该循环将接受诸如“继续”、“退出”以及关键的单步执行和断点命令。 “继续”只是继续执行，而“退出”则终止被调试进程。 本文为实现单步执行和断点奠定了基础，并指出事件循环需要进行调整，以便在特定事件（如指令步骤或异常）发生时暂停执行，从而允许调试器在恢复被调试进程之前处理命令。重点是建立控制这些功能的框架，而不是详细说明它们的具体实现。
## Clojure 在 OpenLDK 上：优化 Java 方法分派
在 OpenLDK (一种 Common Lisp JVM) 上运行 Clojure 曾面临极慢的启动时间——达到 REPL 几乎需要三个小时——这是由于 CLOS (Common Lisp 对象系统) 和 Java 的分派机制之间存在根本性不匹配所致。CLOS 使用多分派（考虑所有参数类型），而 Java 使用单分派（仅考虑接收者的类型）。OpenLDK 将 Java 映射到 CLOS，导致每次 Java 调用都进行代价高昂的方法查找，而 Clojure 在启动期间加载的约 3000 个类进一步加剧了这一问题。
解决方案是利用 CLOS 的元对象协议 (MOP) 将 Java 方法的默认分派机制替换为单分派实现。这是通过创建具有分派和 `invokespecial` 调用（Java 构造函数/超类调用）哈希表缓存的自定义 `java-generic-function` 元类来实现的。
关键改进包括拦截 SBCL 的 `update-dfun`（它在类定义上重建分派网络）并将其替换为缓存清除，以及为常用的 Java 方法（如 `<init>`）预先创建泛型函数。这些更改将 REPL 启动时间从近三个小时缩短到三分钟以内，展示了 MOP 在不修改核心 Lisp 实现的情况下进行有针对性的运行时定制的强大功能。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
为 Java 风格的单分派弯曲 CLOS Mop (atgreen.github.io)
atgreen 发表于 1 天前 | 隐藏 | 过去 | 收藏 | 2 条评论 帮助
atgreen 发表于 1 天前 | 下一个 [–]
我通过 OpenLDK（我在 Common Lisp 上的 Java JIT 编译器和运行时）在 Common Lisp (SBCL) 上运行了一个 Clojure REPL。 这篇博文概述了我如何操作 CLOS 的方法分派以提高单分派方法调用的性能。回复
wild_egg 发表于 22 小时前 | 上一个 [–]
有趣！去年我用 CL 写了一个 Smalltalk，做了同样类型的映射：Smalltalk 类编译成 CLOS 类，每个消息都是一个 CLOS 方法。一开始效果很好，但随着编译的类越来越多，性能下降了。我从未花时间解决这个问题，但它闻起来与你在这里描述的情况非常相似。感谢你的撰写！
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：