苹果还活得挺滋润的
【 在 kknd1399 (kknd1399) 的大作中提到: 】
: 做这个的都死了
--
FROM 111.161.241.*

专利是个问题。
的确现在主要任务还是把cpu搞的更快。并非兼容。
【 在 lukeff 的大作中提到: 】
:  
: 我再来谈谈二进制翻译相关的问题，水平有限，如有错误欢迎斧正。  
:  
: 我真的很惊讶居然，都0202年了还有这么多人热衷二进制翻译，在我看来之前的二进制翻译技术是存在不可避免的重大缺陷的。  
: 二进制翻译最大的问题是可以兼容原体系的二进制文件但做不到100% “0 bug”的兼容原体系二进制文件——兼容不绝对就是绝对不兼容，十几万几十万条机器码只要有一条无法正确翻译，那其余的都正常翻译没有任何意义。其中原因我认为有三点  
:  
: 1）原体系结构过于复杂  
: x86经过快50年的发展，已经是个庞然大物了。你们自己去intel官网上看看intel x86/x64的手册都是五六千页的，要是再把各种扩展指令集/应用手册加上两三万页都只有低估。你能在看看作为精简指令集的Arm，现在哪还有“精简”的影子，光ARM V7的指令手册就2736页，arm v8差不多这个两倍。  
: 你怎么保证对这么复杂的体系结构软件模拟做完备测试？有这精力为什么不去优化自身的流水线/物理设计？简直舍本逐末！  
:  
: 2）原体系处理器微架构设计黑盒  
: 二进制翻译就原理来看，就是分析原体系结构特征针对性的设计一些特征行为指令/物理查表指令/缓存结构以尽可能加速翻译过程，简单来说就是实现通过软件实现x86 cpu前端取指/pre-译码过程，龙芯的机器码就相当于x86流水线里的uop。  
: 这就涉及一个致命问题，任何商业处理器厂商都不会公布自己微架构设计细节，导致指令的手册只是指令的行为描述，对其他人来说处理器实际上是个黑盒。这一点对于一般的算数/逻辑/甚至SIMD指令来说无关紧要，但对于特权指令/catch/TLB/原子操作/中断这些直接操作流水线的指令简直就是灾难。  
: 为什么二进制翻译的bug总是会发生在底层驱动和深度优化的代码中？就是因为底层驱动会频繁使用中断和特权指令，而运算密集性代码的深度优化的几乎一定是在catch 预取上做手脚，而多核/多线程应用的加速会大量使用原子操作。在没有流水线操作具体细节情况下，你根本不能遍历流水线在这些操作下转换状态。偏偏这些指令又是影响性能的关键指令，这就是如今二进制翻译技术的技术瓶颈。  
:  
: 3）专利风险  
: 一个东西，远看像鸭子，近看像鸭子，叫声像鸭子，烤熟了味道也像鸭子，哪它就一定是只鸭子。  
: ISA本身没有专利，专利是对ISA代表的行为及行为实现。就算你龙芯本事逆天，完美还原intel 处理器流水线状态机，那你极大可能已经落到intel的专利陷阱。别忘了当年intel和全美达的官司可是压垮全美达最后一根稻草。  
:  
: 综上除非龙芯能彻底颠覆之前的二进制翻译机理，我非常不看好这条技术路径。  
: --

发自「今日水木 on HUAWEI G750-T01」
--
FROM 42.234.95.*

新指令集就是重建生态链，要是美国拥有专利的指令集不让用了，可以另起炉灶自己玩。

【 在 return0 的大作中提到: 】
: 这三篇都没有提到这个新指令要解决的痛点，就是x86和中国脱钩了，包括兆威不能用了，中国怎么办。不是中国不想用，而是不许用。怎么办？
--
FROM 171.221.29.*

性能倍增
【 在 amiworld 的大作中提到: 】
: 这个qemu，gem5等模拟器不是可以做到吗？有什么区别呢？
--
FROM 117.136.0.*

区别是性能。实时binary translation性能可以做到和原生性能的八成。
【 在 amiworld 的大作中提到: 】
: 这个qemu，gem5等模拟器不是可以做到吗？有什么区别呢？
: 【 在 nokia9500 的大作中提到: 】
: : intel当年搞的hudini类似，可以让编译过的二进制可执行文件直接在另一个指令集的系统上跑。
: ....................

- 来自「最水木 for iPhone 8 Plus」
--
FROM 73.158.184.*