苹果的 Rosetta 2 否定了龙芯的翻译指令技术的未来。

苹果的翻译就是纯软的
说软硬结合的思维太狭隘了


苹果能做到这样，你们也不看看操作系统macOS是谁的，开发环境、组件、语言和引擎OC、Swift、Xcode和Metal等是谁的


难道上一次苹果搞Rosetta1的来PPC转X86的时候，Intel专门给苹果增加解码指令集？这不瞎扯淡么


这个操作模式，也就苹果能做得比较好。微软谷歌要做受限也会很多。

……我对二进制翻译无关心，这里的一个都不认识，但是扯出 AOT 比 JIT 先进的实在看不下去。
连扯体系结构的风口里都有这类 zz 论点，看来是有必要+FAQ了。

这 LZ 的问题，根本不只是“对自己不熟悉的领域最好不要妄加评论各种预言”的问题，是缺乏传统 CS 历史和常识。

（按合格的 CS 教育背景）众所周知，历史上 SMC(self-modifying code) 在 pre-ISA / ISA 早期阶段普遍存在。这也是所谓的 von Neumann architecture 统一指令和数据存储的典型应用。随着高级语言的发展，这个功能逐渐被弱化。这主要是流行的语言中，都不支持需要 SMC 才能高效实现的功能（例如，ISO C 和 ISO C++ 都不要求支持运行时生成的程序和源代码经过翻译阶段处理后的代码具有同等的地位），因此体系结构设计弱化到去除 data as code 而纯软件实现也可以接受。
但是，现实是除了极端低成本的机器使用了 Harvard architecture 的设计，主流 ISA 在实现内部都保留了早期的 SMC/CMC(cross-modifiying code) 机能，而在上层才不强调这一点——因为 Lisp machine 式微之后的用户普遍不会使用 code as data 的思路元编程，高级语言中在这方面大多是残废。这表示微架构实现上必须做到这种跨风格的翻译——把底层的 von-Neumann style 翻译成上层显式区分 VM protection 并分别优化的设计。这种现代设计主要集中在缓存子系统（IA-32 方面记得专利实现是 victim cache），但原则上因为 ISA 上需要保留支持，core 内也需要对应调整。
因为接受动态输入的 data as code ，不论是在哪个层次上，SMC/CMC 原则上不可能用 AOT 风格的完全静态代码翻译解决，否则会有不可预料的正确性错误。

这方面的一个重要常识：在可预见的未来，主流 ISA 是不可能彻底抛弃这种兼容性的。断言在 ISA 这个层次上纯 AOT 能用，这是迷惑行为其一。

虽然这里的人都担不起，另一个更大的相关迷惑行为让消费者付出 IC 设计和制造的成本却阻碍他们取得功能。这方面的唯一“成功”典型是苹果：在商店审核规则中直接禁止 JIT ，放着符合 POSIX 标准能够合理利用硬件加速的实现不用，迫使开发者选择更低效的软件模拟的解释实现。就是这样的厂商，一边还有脸鼓吹降低碳排放，何等讽刺。另外，允许 Safiri 州官放火不许应用自己点灯这方面，明眼人自己看着办。

而背后更本质的共通迷惑行为是对 AOT 或者砍掉了 data as code 能力的残废编程风格的迷信（不管是使用低级语言还是高级语言）。
因为这类风格中，纯 AOT 才可能满足语言 spec 正确性要求，所以对 AOT 的盲目追捧还影响到了上层语言的功能限制。
这种迷信的来源是复杂的。至少有：
1. 使用个别缺乏 data as code 的语言的习惯性偷懒成自然，具体来讲现在主要是 C 和 C++ 。
不少人因为只会用这类语言，所以认为这类语言就应该具有统治地位，而不管缺乏合理功能时破坏可移植性带来的后果。
结果剩下意识到有必要打破这种限制的各显神通群魔乱舞，还有被州官当借口镇压的。
讽刺的是，打破这种限制的用户需求是普遍的，如 WG21 P1609 。
2. 因为教育背景不健全等原因导致的实现实用计算的普遍范式理解和独立思考能力上的残缺。
例子如 exception path 的假设（p/7102475556）和更普遍的调用机制的理解之类（p/6213333021 18L）。
3. 支持上述语言和范式为主的业界翻译实现的普遍无能——更习惯依赖 SSA-based intraprocedural style 的局部优化设施（而非 CPS/ANF 这类对 intra/interprocedural 更中立的）来提升目标代码质量。
这种决策下，翻译的实现不追求一般 control operator 优化的可实现性，而放松了 AOT 的门槛，反过来加大了可移植 JIT 的困难。
题外话，这种方式倒的确适合分离 backend 搞水平扩展——多 996 tuning 性能看来就就有机会更好。至于极限在哪呢？不知道，还有待继续 work hard 。而一般意义上 polyvariant online partial evaluation 之类的更普遍手段就别想了。
不过，不少搞 translation 的从业人员大概连 translation lemma 都没听过就赶鸭子上架了，这也是理固宜然。

至于所谓的未来，其实也可以无关心。
不过 LZ 的格局也就是笑料。
具体来讲，大部分业内几乎人人都有关的重大事项都还早得很，不过应该还是有些寿命区别的。
因为业界的胡搞，C/C++ 差不多无可救药了（等 BS 和 HS 这些人搞不动了看看谁还敢鸟什么 teachability ）。考虑到缺乏靠谱 CS 教育的惯性（体现在吹个 builtin xxroutine 的“新”语言出来就能糊弄不少没能力实现干净对应功能的这些语言的用户），能流行个四五十年就不错了。
SSA-based compiler suite 呢，大概也就是这个命，不过也许会发展过于简单粗暴，快速遇到瓶颈（who-knows）而更加短命一点。
ABI bug-to-bug comat 嘛，这代人退休了以后一不高兴可能就不管背后洪水滔天了吧……
虽然这些都是比商业 ISA 更长命的**历史遗留问题，不管怎么说这些还是有生之年可能看得到变化的。看看 AGI 这种 200 年内都未必八字能有一撇的东西都有人赌，这也算不了啥。

在此之上，区区 M1 算个啥口水？

为什么要翻译？苹果多数代码是bc形式，部署还是原生机器码。除非某些贴别的库

苹果啥时候能出个吊打3950x的U再说

龙鑫的所谓兼容也无非是一段时间的过度的权宜之计，不必太当真，他真正要做的是老胡要自己要用自己指令集了。