tag 标签: windows

相关博文
  • 热度 8
    2020-5-2 15:39
    4165 次阅读|
    1 个评论
    MacBook要采用Arm处理器,难度有多大?
    实际上,有关 Mac 系列计算机要开始采用 Arm 处理器的传言似乎是从 2010 年就开始的,那会儿苹果也才刚刚开始做 iPhone 的 SoC。这一传言就 10 年过去了,起码今年前不久才更新的 MacBook Air 都还在用 Intel 的处理器。 想起来以苹果的尿性,对自家生态的管控,恨不得从硬件到软件由内到外全部一手包办。这么有洁癖的一家公司,如今有能力自己设计处理器,为何还要受制于 Intel?况且 Mac 设备本身的开发周期,还面临与 Intel 处理器迭代撞期的尴尬,导致 Mac 经常无法用上 Intel 最新的处理器。如果用自家的 A 系列 SoC,岂不是很美的一件事情吗? 这次的传言看起来格外靠谱,彭博社报道称,2021 年采用 Arm 处理器的 Mac 电脑就要问世了。彭博社线人消息称,Mac 要搭载的处理器将比 iPhone 和 iPad 之上的都更快(好像是废话)。“苹果准备在明年,至少推出一款采用自家芯片的 Mac.”“台积电将会负责制造新款的 Mac 芯片,基于 5nm 制造技术。” “首批 Mac 处理器将有 8 个核心,核心代号 Firestorm,其中有 4 个是节能核心——内部代号 Icestorm。苹果针对未来的 Mac 处理器,还计划探索超过 12 个核心的设计。”值得一提的是,传言中的 Mac 处理器也是以 SoC 的形态出现,其上至少包含了 CPU、GPU。 当年的 iBook,采用 PowerPC G3 处理器 这件事情的可行性当然是有的,只是在具体实施上会遇到不少问题。如果说 macOS 转往 Arm 平台真的那么容易,苹果估计早就干这事儿了。而且事实上,微软这两年正在做这件事情,但在具体的方向上有些小差异。在这篇文章里,我们做一些简单的分享,虽然无法得出结论,也可与各位做探讨。 多插一句,一般来说,我首发在面包板的文章筹备周期比较短,而且相对来说内容更加个人化、娱乐化。与电子工程专辑或者其他平台发布的文章相较,会显得没有那么正式和考究。另外,这篇文章主要参照的是维基百科,我不想去翻以前苹果的开发者文档了——基于维基百科的不可靠性,以下内容可能有部分是存在事实错误的;另外,我也不搞软件和系统工程,所以贻笑大方之处还请海涵。 苹果曾有的两次迁徙经历 苹果的 Mac 产品线与 Intel 的合作是从 2005 年开始的。那一年,Intel 的 CEO 还为苹果站了台,与乔布斯一起。次年的 Mac Pro 就开始正式采用 Intel 处理器(Mac OS X 10.4.4 Tiger)。在此之前,Mac 并不是 x86 平台的拥趸,我记得看电子科技相关杂志,包括当年像台灯一样的 iMac,苹果在宣传词中都提到处理器比同时代的 Intel 奔腾快多少倍之类。 在此之前,苹果就有过两次在指令集平台上转舵的经历,看起来已经是个老手了。至于为什么要换用其他平台,这可能和软硬件更具体的技术问题相关,不过从社会上广为流传的资讯来看,都是因为老平台的效率越来越不济(就好像如今主流观点认为 x86 处理器的效率不如 Arm,虽然我不这么看;很多人认定,Mac 转向 Arm 也算是合情合理)。 从这两次转舵,其实可以大致来看一看,这回若从 x86 转往 Arm,可行性几何?或者苹果从前的转舵经验,是否有足够的参考价值。一般来说,从一个硬件平台转往另一个硬件平台,经常意味着抛弃以前的开发者,以及抛弃以前的用户。因为转往新的硬件平台,总是意味着旧有软件将停止更新,且旧的开发生态彻底终结,未来的新软件也无法安装在旧平台上。当然系统制造商总是会采用一些折中的兼容性方案来实现过渡。而“过渡”的平滑与否,真的就要看厂商的水平。 1994-1996 年前后,苹果的 Mac 电脑从更早摩托罗拉的 68k 系列芯片转往 PowerPC 处理器(参与 PowerPC 联合开发的应该有摩托罗拉、苹果和 IBM)。这个转换过程持续了几年,当时苹果的过渡方案是所谓的 Mac OS Classic(Mac OS Classic 也就是经典 Mac OS,指代了 Mac OS X 之前的 Mac 操作系统),可以同时跑在 68k 和 PowerPC 平台下。有个词叫 fat binary,形容某一种应用,占用更多的存储空间(所以才 fat 吧...),但混合了多种指令集的原生代码支持——也就能够在多种类型的处理器上跑。苹果当时搞的这种 fat binary,就是令开发者将 68k 编译版本和 PowerPC 编译版本打包到同一个执行程序中。 另一方面,当时苹果引入了一种较低层级的模拟方案。系统中有一个 Mac OS nanokernal 内核,这个内核建立在 Macintosh ROM 里面(Macintosh ROM 是最早 Macintosh 电脑中的一个固化在主板上的芯片,用于电脑启动时的初始化)。而这个 ROM 内部有个叫做 Macintosh Toolbox 的东西,类似于 BIOS 这种角色。而 Mac OS nanokernal 为 Toolbox 提供 68k 处理器的模拟环境。 Mac OS nanokernal 在电脑启动时加载,内存里开辟一个 PowerPC 内核空间加载模拟器。随后模拟器继续加载 Toolbox 对系统硬件初始化,随后的操作和 68k 时代基本上一样。这时期 PowerPC 设备的内核,实际上就是运行在 68k 模拟器里的 Toolbox。 nanokernal 的主要工作就是让现有 68k 版本的操作系统跑在新的 PowerPC 硬件下,如此系统普通状态就能跑 68k 代码。在必要的情况下可以转回到 PowerPC 模式下,基于中断处理程序(interrupt handler)实现,并将虚拟内存系统映射到 PowerPC 硬件上。不过维基百科说,这个过程,也可能只是由跑在用户态的模拟器去处理的。 iMac G4,采用 PowerPC G4 处理器 无论如何,这都是个看起来十分简单,而且还非常低效的方案(原生的 PowerPC 性能似乎很难发挥) ;不过好像也很有效,Mac OS nanokernal 的 68k 模拟器也就为旧软件提供了这种低层级的兼容性。当时的模拟器提供的运行环境,和 Macintosh Centris 610(处理器具体型号为摩托罗拉 68LC040)最为接近。 早期版本的 68k 模拟器会解码每一条指令,并立即执行一系列对应的 PowerPC 指令,实现这种模拟。后续的 PCI PowerMac(PCI 总线的 PowerPC)中的动态重编译模拟器(dynamic recompilation)则对性能做了提升:将代码常见的部分,“重编译”为更快的、PowerPC 原生序列——且在本地做了缓存(locally cached)。也就是说这种模拟器能够识别一些 680x0 代码序列,并且直接跑已经缓存过的 PowerPC 代码,也就避免了重新转译。对于一般的开发者来说,这种转换也就显得比较无痛,因为模拟器是自动开始和结束的。 最初的 Mac OS nanokernal 是相当简单的,这就是个单任务系统,把大部分工作交给操作系统 68k 版本的模拟器去跑。有兴趣的同学,可以去了解一下当年的 Mac OS Classic,它似乎还称不上一个现代化的操作系统,连内存保护都没有;上层的应用程序直接跑在 Toolbox 上,除了获取系统提供的功能和资源,还能直接操作硬件和内存。这个版本的 nanokernal 似乎是到 Mac OS 8.5 终结的。 第二版 Mac OS nanokernal 也算是越来越像样了,开始支持多任务多处理器、消息传递,可以算是微内核了;内核存在于受保护的内存空间中,并在用户态下执行设备驱动。这是题外话了。 Mac OS Classic 时代的操作系统和个人电脑还是相当的粗放和不讲究,而且层级结构也比今天要简单得多。而另一方面,其实也不难发现,即便是当年苹果电脑用户基数不多的时代,生态搬迁都需要付出这般代价;每一次平台搬迁,实际上都需要付出代价,由上至下。 还有一点值得一提,后来 Mac OS X(PowerPC 版)内部有个名为 Classic 的环境,这是一个抽象层——绝大部分 Mac OS 9 应用都依托于 Classic 环境跑在 Mac OS X 上。从 10.5 美洲豹系统开始,就已经去掉了 Classic 环境(即更晚的 x86 平台也就不再对 Classic 做出支持)。具体来说,Classic 环境包含了一个 Mac OS 9 系统文件夹,以及一个 New World ROM 文件(前文提到的早期 Macintosh ROM 算是 Old World ROM;而 New World ROM 时期,早期 Macintosh ROM 不复存在,原本的 Toolbox 成为一个文件存在硬盘上)。这里的 Classic 可以认为是 Mac OS X 之下的一个模拟子系统。 从 PowerPC 转往 Intel x86 2005 年,乔布斯表示苹果对于 IBM 的 PowerPC 开发进度非常失望(这集我看过!去年的 Intel 基带事件似乎也是这么演的) ,而 Intel 显然可以满足苹果的需求。当年乔布斯大谈每瓦性能,实际上也就是能效比,这似乎也是如今在舆论上,x86 处理器陷入不利的原因。乔布斯在 WWDC 大会上宣称,Mac OS X 的每个版本都“秘密地”针对 Intel 处理器做了开发和编译。所以现在的 macOS 有没有“秘密地”针对 Arm 做开发和编译? 当年 Intel 为苹果站台的名场面 这次的兼容性解决方案,是一种名为 Rosetta 的指令解释器,这是一个动态二进制转译器(dynamic binary translator)。苹果在宣传中,把 Rosetta 称作是“the most amazing software you'll never see”。苹果说对于旧版 PowerPC 应用来说,那些重交互、但算力需求比较低的应用,非常适用于 Rosetta(比如文字处理);而算力要求比较高的(比如 AutoCAD、Photoshop)可能就会悲剧(很像 Windows on Arm???);一些“专业级”的媒体应用,比如 Final Cut Pro、Logic Pro,则完全不支持。 Rosetta 所处的层级比 68k 模拟器要高,是个“用户级”的程序,只能监听和模拟用户级代码。这可能和苹果担心安全问题有关,而且毕竟 Rosetta 推出的时间,操作系统也比 68k 模拟器年代要成熟很多了。所以 Rosetta 不支持的环境和状况有很多,也包括了不支持转译 PowerPC G5 指令。 苹果后来发布的 Xcode,有针对 Intel 与 PowerPC 的 Universal Binary,就跟前文提到的 fat binary 类似——这样一来,当时面对平台迁徙的开发者,在面对 Mac 应用开发时,针对基数也算多的 PowerPC 用户,不会不知该选 PowerPC 还是 x86,因为两个都可以要(微软 WinRT 借鉴对象?)。 不过 Resotta 的确在过渡平滑性上要差一些。针对 Mac OS 平台下不同类型的应用,开发者使用 Rosetta 还是需要做一些基本工作的,比如 Cocoa 应用需要重新编译、检查字节顺序问题;Carbon 应用则要求做小幅调整;而使用 Metrowerks Codewarrior 套装开发的应用则需要做较大程度的修改(Codewarrior 是一个 IDE,这个 IDE 的早期版本就针对 68k 和 PowerPC Macintosh,当年苹果转往 PowerPC 时,CodeWarrior 成为 Mac 实际上的标准开发系统,快速取代了苹果自己的 Macintosh Programmer's Workshop)。 就最终的成果来看,Mac 的这第二次转舵还是很成功的。实际上即便到 2009 年,Mac OS X 10.6 雪豹时期,苹果已经完全不再支持 PowerPC,依然有不少开发者通过 Universal Binary 对这一平台做出后续数年的支持——这还是能够从侧标反映苹果在兼容性方案上的不错表现。 但我觉得,这次的成功主要并不来源于苹果在兼容性工作上的成功,而在于 Mac 转向 x86 本身就是一次从冷门到热门,以及低效向高效的转变,因为 x86 平台原本就相当成功。Intel 这些年起码在桌面 CPU 的效率提升上是独占鳌头的。另外要知道 PC 市场的绝对大头:Windows 就一直在用 x86。 而 Mac 转往 x86,则很大程度上意味着 Mac 设备从此以后就可以名正言顺地安装 Windows 系统了。苹果自 2006 年起引入的 Boot Camp 还对 Windows 的安装做出了原生支持。 也是从这个时候开始,大批量的人在星巴克用 MacBook 装逼(以及运行的却是 Windows 系统)才变得可行。或者说至少买一台 Mac,就不用放弃 Windows——而且同一时间还有大量效率较高的虚拟程序可以跑 Windows 及对应的应用。我觉得无论如何,这都是 x86 平台的 Mac 得以大获成功的原因。 PowerPC 的转变相比,这次的转变有着天然的生态优势。当然,在 x86 成为 Mac 的选择以后,Mac 设备自身的设计变迁,为行业树立标杆也是重要原因,如 2008 年推出的 MacBook Air;另外,现在基于 web 的应用越来越多,很多人对浏览器的依赖已经大过操作系统本身,这让平台选择进一步脱耦。 所以, 我觉得 Mac 在转向 x86 平台时的成功,更多的是时势造就,甚至别家生态使然;亦是苹果在电子科技发展史上的一次识时务之举;且以当年 Mac 的体量,更不存在尾大不掉的问题。 从 x86 转向 Arm?Arm 效率真的高于 x86 吗? 我们近两年听到最多有关 Mac 要从 x86 转向 Arm 的原因,好像并不是苹果要加大生态掌控力(这是我觉得苹果可能决策转向的最主要原因),而是 x86 处理器的效率比 Arm 差很多——这方面的报道也还不少。就相对直观的消费用户体验来看,这一点似乎还是有足够的论据的。这些年智能手机、平板产品的性能提升速度如此之快,感觉跟 PC 是不是已经差不多了? 苹果前些年发布 iPad Pro,并将其定位于生产力工具的时候,就不忘在发布会上黑现在的 PC,声称 iPad Pro 所用的 Ax 处理器比市面上 90% 的 PC 还要快。虽然也不知道这种对比是如何产生此等量化数据的。加上还有 GeekBench 这种苹果专用跑分工具(误)助阵,像 A13 这种芯片的跑分成绩比 AMD Ryzen 3850X 还要高;单核平均功耗才 7、8W 的 A12X,单核跑分和 TDP 95W 的 Intel Core i7-8700K 差不多,多核成绩则比 8600K 还要高。 这么说来,Arm 和苹果掌握的黑科技,已经达成体积小如此之多、功耗少如此之多的情况下,性能达成与 x86 平台几乎齐头并进的水准啦? 我前俩月就听有人在社区大谈 RISC 相比 CISC 有多大优势,并以此得出 iPad 性能为何比如今 PC 强那么多的结论,言下之意是你们根本就不懂指令、现代半导体技术的神速发展。Intel 估计应该被钉在历史的耻辱柱上。 有关 GeekBench 娱乐工具跑分相近的问题,其实 我们必须承认一个大前提 :当代处理器微架构优化,能用上的技术基本上都用上了,前十几年的发展,什么流水线、分支预测、乱序执行、多级缓存、超线程、时间空间并发之类乱七八糟的,及这些技术本身的反复优化,外加制程工艺进化,CPU 性能总能有“质”的飞跃。但如今, CPU 单核性能提升已经十分缓慢,不仅是制程工艺步进缓慢甚而停滞,还在于能用的优化技术都已经用上了。 当然我们不能排除未来还有什么黑科技出现,但至少就这两年的情况来看,新货已经鲜见了,不似当年某种新技术一出立刻造成轰动。 所以虽然 Zen 2 如此神奇,而且还被我们吹得神乎其神,但实际上其单核性能也就那么回事,拼死了也就比同代 Intel 10nm 的十代酷睿强一丢丢——当然其 CCX 架构让 Zen 2 堆核更容易了,台积电的 7nm 也的确给力。 扯远了,上面这两段是为了表明,Arm 即便作为低功耗领域的主力架构,这些年的发展致其单核心性能可与 x86 比肩也并不稀罕。不过那么大的功耗差距,却可达成相似 GeekBench 跑分又是怎么回事呢?这个问题,我在之前探讨 Surface Pro 时就提到过:不考虑散热系统的跑分成绩都是在耍流氓,尤其是 GeekBench 这种短时跑分测试。 我们知道苹果 Ax 系列 SoC 瞬时突发性能还是比较强的,包括 GPU,但一旦考察持续性能,则会有一个较大幅度的折扣,因为毕竟手机这么小的体积,而且就靠那点被动散热面积,很难做到长时间的性能发挥。有关这个问题可参考我之前写的两篇文章 。我们常戏谑说 GeekBench 是 AppleBench,一方面原因在于其中的某些测试项,在 Ax 系列 CPU 中有专门硬件单元做计算,而 x86 很多时候只能依靠通用计算单元来解决,解题效率会略低(这部分内容各位可以去自行研究,早年比较典型的是 AES 加密单元——A 系列处理器就有专用单元,所以这类项目的跑分成绩可以很高,现在可能有差别);另一方面就在 GeekBench 整个测试周期很短,那么系统真正的综合性能其实是难以体现的。 知乎上有高人给出了 Arm 是否真的比 x86 更省电的理论分析,有兴趣的可以去看一看 。很多人对 x86 留下高功耗印象的原因,其实是平台(以及使用场景)差异造成的,PC 的处理器 TDP 在设定上就很高,而这种相比移动设备高得多的参考功耗,很大程度上就源于前面我说到的 PC 要求在一个较长时间内持续高性能,而不只是简单的瞬时突发性能。另一方面还在于,Arm 指令集的处理器普遍采用大小核设计,小核心是专用于低功耗场景的(而且这种小核心现在看来似乎也越来越有必要)——而直到前一阵,Intel 才表示准备要搞这种大小核设计。 当然这也是因为 PC 的具体使用场景,以往并没有多少需要像手机那样超低功耗状态的应用,或者这种必要性并不大(虽然现在也逐渐开始有这种需求);而 Arm 平台的移动设备多用电池做电源,本身也需要对功耗做限制。 所以 x86 能效比低于 Arm 的这种印象,大抵上是两者使用场景的常年差别造成的 。能效比怎么样,要对比的应该是同性能下的功耗情况。恰好 AMD 开始使用台积电的 7nm 工艺,这也给这种对比有了一个基于类似制造工艺下,同性能(而不单纯是同频)下的功耗情况对比的依据。不过这种对比需要考虑的问题还有很多,比如 x86 平台的很多 CPU 还有“睿频”的概念,而 Arm 手机和移动平台 CPU 则没有;两者的流水线长度不同等等;而且前面提到,两者使用场景目前还是有差别,这也是芯片内部专用单元有差异的关键。 苹果 A12 的频率功耗曲线,来源:AnandTech 从相对直观的角度来说,随性能的提升,功耗也在提升,但这两者的关系并不呈线性;意即 如今 Arm 低功耗与性能的关系看起来还挺美好,但如果进一步提升性能,所需付出的功耗代价在达到一个拐点以后,就会出现指数级蹿升的状况 ——在高性能领域,Arm 现有的移动处理器也未必会有什么出色的表现:这其中,苹果并未掌握什么黑科技,Intel 也并不存在多大的过错。(服务器领域和 PC 领域在应用场景上又是不一样的,这里不讨论。) 上面这张图来自 AnandTech ,好像被人援引了无数次。这是苹果 A12 的频率功耗相关曲线。AnandTech 认为苹果做得还是比较出色的,而且在后续几百 MHz 区间内也相对保守。如果说苹果期望再把频率抬高,则按照 A12 的现状来看,很快就可以在 3GHz 附近让功耗彻底达到标压笔记本的水平。 这次的转舵可能有所不同,看看微软 上面这个大段落好像说了不少废话,与本文的主旨关系并不算太大。不过我想表达的是,其实 x86 并不像人们想的那样不堪,Arm 也不像人们想的那么美好。在不考虑散热、功耗的情况下,这两者的性能水平可能正在趋同——这也是 AnandTech 之前评价 A12 接近桌面处理器水平的原因。但就系统和具体应用场景的角度,即便 A12 有这种能力,也不可能发挥到桌面处理器的水准,因为它被功耗与散热限制了。 就性能来看,苹果应该是有能力造出 Intel 同等性能的 PC 处理器的,而且 Intel 如今在半导体制程工艺上有落伍的迹象(Intel 前不久才承认到 2021 年之前,工艺技术都将落后于竞争对手 )。但在 macOS 的软件生态和兼容性层面,就又要多花一番心思了。这个过程可能仍然需要数年,而且这次的转舵还不同于以往。只不过在过去苹果积累的经验,这会儿似乎还是可以派上用场。 彭博社的报道提到,可能会有部分 Mac 产品将采用 Arm 处理器。 就前期来看,合理的推测是,低性能、低功耗产品线的 MacBook(比如说早前 12 寸的 MacBook)可能会率先采用苹果自己的 Arm 处理器。但如果真的是这样,那么也就意味着,Mac 产品系列将有两种架构、两种平台并存,这对开发者来说应该是个灾难。 苹果大概需要重启过去两次转平台时 fat binary 和 Universal Binary 方案——一人开发,俩平台共享... 实际上在早年 fat binary 时期,把两种编译版本封装到一起,造成的文件尺寸大,在当时是比较敏感的——因为那会儿 PC 的硬盘容量真的很可怜,所以那一时期还涌现出了为了节省硬盘空间,可剥离不需要编译版本的工具。现在这已经不算什么大事儿了。 而就当代来看,苹果实际上有一个更好的参照对象,就是微软。不过微软在计划上看,并不是“转舵”,而是“扩展”,这里我们可以稍微提一提:即 Windows 不仅要在 x86 平台上发展,而且要在 Arm 平台上发展。这个计划从 Windows RT 操作系统时期就出现了,那时微软就搞了一个 Windows Runtime,这个运行时之上搭的应用可以同时支持 x86 和 Arm。当时的 Windows Phone 8.1 其实也用上了 Windows Runtime,所以那会儿微软应用商店的很多 app 都同时支持手机、PC、平板,虽然商店里的应用数量也是少的可怜。 这算是实现微软“伟大”生态 Universal Windows Platform(UWP)的重要组成部分。UWP 本质上就是为所有 Windows 设备,包括 PC、IoT、平板设备之类,或者说所有 Arm、x86 平台的 Windows 设备,提供一个通用的 API。UWP 就是一种建立在 Windows Runtime 之上的应用模型。 Windows Runtime 提供的 API 以类库的形式,为开发者提供 Windows 8 的功能。跑在 Windows Runtime 上的应用实际上是跑在一个沙盒里,需要用户批准才能访问一些关键系统特性及下层的硬件。这个东西当时就可以打通 Windows RT、Windows 8,绝大部分应用部署在微软的应用商店里。早期 Windows Runtime 之上跑的应用被称作 Metro app(好像是因为当时微软还热衷于推 Metro UI,后来叫 modern-style app,应该还会改)。 只不过这东西到现在为止都还不能算是成功,微软的营销话术也堪称灾难,没人知道 Windows RT、on Arm、10S、10X 之类究竟是什么鬼。一般人真的很难搞懂微软这两年究竟在做什么——可见当年乔布斯在给 Mac 转平台,在告诉用户和开发者现在正在发生什么的时候,是多么科学(所以比尔盖茨说乔布斯是超级销售员)。不过在实际的决策上,我觉得微软的摇摆不定、瞻前顾后,才真正令 Windows RT 以及后来的 Windows 10S 都很失败。 微软接下来的一个“伟(zuo)大(si)”计划是 Windows 10X。从外显上来看,Windows 10X 是为双屏设备准备的一个操作系统(比如 Surface Neo 之类还没发布的设备),预计今年下半年才会看到实物。不过我觉得 Windows 10X 的意义远不止此, Windows 10X 支持 Windows Runtime API(这个是肯定的),并且“通过一个原生 container 跑 Win32 应用” 。我没怎么研究过如今 Windows 系统架构状况,但就对旧有 Windows 生态来看,Windows 10X 如果是微软接下来意欲统一 PC 市场的操作系统,则这个决心下的还是比较大的;而且貌似双屏 Windows 设备都是基于 Arm 平台。 谁不想要 Surface Pro X 这么性感的笔记本呢? 听起来 Windows 10X 在这一点上,和 Windows on Arm 很像(Surface Pro X 用的就是 Windows on Arm),所以我在想 Surface Pro X 将来是不是可以升级到 Windows 10X——反正微软改名部门创下那么多的“丰功伟绩”。 在针对开发者的兼容性问题上,Windows on Arm 平台下的 x86 应用是跑在模拟器上的,一个叫 WOW64 的 x86 模拟器。和前文提到苹果的 Rosetta 有点像,模拟过程就是把 x86 指令块编译成 ARM64 指令,加一些优化。会有服务对转译代码块做缓存,减少指令转译开销。貌似到目前为止,x86-64 应用(也就是传统的 Windows 64 位应用)还无法在 Arm 版 Windows 上面跑,而且某些大型应用的模拟运行比较灾难级,比如 Photoshop。WOW64 也跑在用户态 。 其实突然又有点搞不懂微软将来计划怎么发展,从如今微软的动作来看,好像十分偏向 Arm(和高通),只不过大业未成,生态也暂未见起色,x86 也不想抛弃。不知 Intel 看此情此景是什么心情。毕竟 Windows 作为历史用户基数庞大的操作系统,兼容性的历史包袱远大于苹果的 Mac OS:我没法从技术细节上来探讨谁做得更好,但微软一定比苹果更有难度;何况苹果还有 iOS 这颗大棋子。 如果说苹果要在同一时间针对 Mac 系列产品,既保有 x86 平台(典型如 Mac Pro 这种更新没多久的高性能工作站),又开发 Arm 平台(很可能就是 MacBook),那么对两个平台的同时支持,以及对开发者的友好度,不知能否做到比微软如今的方案更好——因为这次似乎并不是彻底抛弃上一个平台这么简单(毕竟彭博社是说部分 Mac 产品采用 Arm 处理器),也就不能以斩断过往、说抛弃就抛弃这种苹果式的任性方法来做决策(但好似当年 PowerPC 与 x86 在 Mac OS 系统上也共存了起码 5 年)。 Mac 转舵可能会遭遇的问题 一气写下来,感觉篇幅有点过长了,本来还想聊聊苹果自己在 Mac 设备里面搞的 T2 芯片,以及可将 iPad app 轻松移植给 macOS 的 Catalyst 项目——毕竟这俩看起来都很像本次转舵的重要缓冲或预备手段。但再写的话,这文章字数就要破万了,实在是太废纸了。在转换平台的问题上,即便有那么多的困难,自主掌握芯片迭代节奏,以及牢固生态发展,采用自研芯片还是有好处。 其实上面这些算是一个资料汇总,也算是我近期的学习过程吧,以简短的形式汇报给各位。这里最后谈一谈 Mac 如果真的要从 x86 转往 Arm(而不是两者并行发展,毕竟苹果很少做这么二的事情),除了兼容性和技术层面,如上述文字中提到的难度,在实际实施中还会有一些非常现实的问题。 第一就是,可能面临抛弃 Windows 用户的问题,Mac 如果彻底抛弃 x86,则未来的 Mac 设备很可能就不能再安装 Windows 系统了:这个问题我觉得十分严重,或许很多 Mac 用户对于在 Mac 设备上使用 Windows 是非常嗤之以鼻的,但这个选择对很多人来说仍然十分重要。毕竟 Windows 的生产力生态仍然十分完备,某些很偏的应用都只支持 Windows。(现在 Windows 也支持 Arm 了,只是两者的平台还是有差异) 第二是,如果低端 MacBook 产品线开始用 Arm 处理器,那么目前的 iPad Pro 产品定位会显得很尴尬。因为后者就是定位于轻度生产力工具,如果要说生产力,iOS 和 macOS 似乎并非同台竞争的对象。 第三,有个比较实际的问题:Intel 毕竟是个造芯片的公司,可以搞出一大堆不同定位的 SKU,比如什么酷睿 i3、i5、i7;超低压、低压、标压、桌面等等,并且应用到不同售价的 Mac 设备上。苹果即便有能力造芯片,是否能在短时间内,按照体质划分不同 SKU,并且应用到将来更多的 Mac 设备上?如果不能的话,难道真的要 x86 和 Arm 并行发展吗? x86 那样,是转向一个在桌面市场十分受欢迎和健全的平台;而且如今苹果公司的体量远非 2005 年可比,所以这次转舵的困难程度大约不小。另外,前面花了那么多篇幅谈兼容性问题,针对某些十分细节的点,比如小到 Final Cut Pro X 中的一个插件,即便容易想见 Final Cut Pro X 会第一批支持 Arm 版 macOS,但插件未更新就可以彻底埋葬一部分用户。 具体是什么状况,等到今年的 WWDC 或可一见分晓。最后的最后,Intel 哭泣的时间应该会更长:为什么全世界都针对我? 参考来源: Apple Aims to Sell Macs With Its Own Chips Starting in 2021 - Bloomberg https://www.bloomberg.com/news/articles/2020-04-23/apple-aims-to-sell-macs-with-its-own-chips-starting-in-2021 小议Mac OS Classic的底层架构与Mac的固件沿革 - 老Mac与MacOS收藏 https://zhuanlan.zhihu.com/p/44934452 Mac OS nanokernel - Wikipedia https://en.wikipedia.org/wiki/Mac_OS_nanokernel Mac 68k emulator - Wikipedia https://en.wikipedia.org/wiki/Mac_68k_emulator Fat binary - Wikipedia https://en.wikipedia.org/wiki/Fat_binary List of macOS components - Wikipedia https://en.wikipedia.org/wiki/List_of_macOS_components#Classic Rosetta (software) - Wikipedia https://en.wikipedia.org/wiki/Rosetta_(software) CodeWarrior - Wikipedia https://en.wikipedia.org/wiki/CodeWarrior 聊聊无风扇的Surface Pro:性能比一般笔记本差多少? - 面包板 https://mbb.eet-china.com/blog/3893689-413612.html 一场硬仗:华为和高通的GPU差距还有多大? - EE Times China https://www.eet-china.com/news/202001061219.html 为啥 Arm 架构比 x86 x64 省电? - 木头龙的回答 https://www.zhihu.com/question/387240856/answer/1186307900 The Apple iPhone 11, 11 Pro & 11 Pro Max Review: Performance, Battery, & Camera Elevated - AnandTech https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4 Intel Says Process Tech to Lag Competitors Until Late 2021, Will Regain Lead with 5nm - Intel https://www.tomshardware.com/news/intel-process-tech-lag-competitors-late-2021-leadership-5nm Windows Runtime - Wikipedia https://en.wikipedia.org/wiki/Windows_Runtime How the Universal Windows Platform relates to Windows Runtime APIs - Microsoft https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide#how-the-universal-windows-platform-relates-to-windows-runtime-apis Windows 10X Developer FAQ - Microsoft https://docs.microsoft.com/en-us/windows/apps/10x/faq WOW64 Implementation Details - Microsoft https://docs.microsoft.com/zh-cn/windows/win32/winprog64/wow64-implementation-details
  • 热度 2
    2016-3-8 19:41
    211 次阅读|
    1 个评论
    Hello World!!
  • 热度 1
    2015-12-31 11:00
    258 次阅读|
    0 个评论
    Toradex日前宣布已经加入Microsoft Azure Certified for Internet of Things (IoT), 以便为客户快速开发和部署IoT解决方案提供一套验证了的软硬件平台。Microsoft Azure Certified for IoT 授权允许Toradex和客户建立联系,并提供一个设备和平台的生态系统,最终快速实现产品量产。 Toradex公司致力于基于计算机模块和载板架构的可靠且紧凑的嵌入式计算平台解决方案,广泛应用于各种工业领域如工业自动化,医疗,汽车,机器人等。Toradex所提供的模块化产品使客户可以快速可靠的部署一个从前期方案验证到最后产品量产都适用的平台解决方案而无需重新设计计算平台,这样既减少了开发风险同时又加快了量产进度。 “Microsoft Azure Certified of IoT 证实了我们有能力给客户IoT项目提供一个验证了的包含硬件和操作系统的平台方案,无需大量兼容性相关定制工作使Toradex可以快速帮助客户实现IoT项目”来自Toradex CEO,Stephan Dubach。 “Microsoft Azure Certified of IoT,借助于这些全球领先的合作伙伴可信赖的技术方案,可以帮助我们更快实现IoT规模化部署的承诺” 来自Microsoft GM of Data Platform and IoT,Barb Edson。 IoT项目的复杂度使得客户需要花较长时间去寻找并连接合适的设备或传感器到云端,而如果选择一个合适的经过Azure IoT认证的合作伙伴平台方案则可以大大缩短项目开发周期并有效降低开发风险,因为这个方案已经被验证过可以非常好的配合Azure IoT Suit工作。   经Azure IoT授权的Toradex产品列表如下:   Azure IoT相关上手指南和SDK介绍请见 这里 ,另外Toradex近期也会举办一次网络研讨会“Getting Started with Azure IoT on Devices”,请从 这里 注册参加。   关于 Toradex : Toradex 是一家领先的 ARM 系统模块厂商,其模块可以广范用于嵌入式产品应用领域。通过采用 Freescale® i.MX 6 Vybrid™, NVIDIA® Tegra 以及其他先进的处理器,系统模块产品系列在价格、性能、功耗和接口方面提供丰富的选择。 凭借超过 10 年的长产品生命周期、终生免费的产品维护、可扩展性能的引脚兼容产品系列、直接高级技术支持和价格透明的在线销售,Toradex 在嵌入式计算市场脱颖而出。成立于 2003 年,总部位于瑞士霍尔夫,Toradex 公司网络已经遍布全球,在美国、越南、中国、印度、日本和巴西均设有办事处。更多的信息,请访问: https://www.toradex.cn。
  • 热度 2
    2012-12-6 11:47
    590 次阅读|
    0 个评论
    作者:磐石之心 Windows 8发布了,不能说引起行业轰动,也差不多。因为这是自XP发布以来,微软最具创新的OS了。但是对于Windows8有很多误区,接下来笔者就一一评判: 第一,希望Windows8颠覆iPad是愚蠢的 不知是苹果太惹眼,还是什么原因,认为windows8是用来颠覆iPad的人很多很多,甚至微软自己也似乎抱有这种幻想。事实上,windows8最具特色的是一台可触摸的PC,而iPad就是一台不能打电话的“大屏手机”。iPad的海量App让其更适合娱乐,而windows8并不具备,电脑颠覆平板的理论本身就有问题。 第二,  windows8颠覆的是传统笔记本电脑 专门为Windows8设计的笔记本电脑,相比传统笔记本更轻薄、续航时间更长、支持触控操作和键盘操作。拆分的物理键盘或者是360度旋转,让windows8笔记本可以像平板一样使用,但是其根本仍是一台PC,偶尔可以当平板使用。在摩尔定律失效的前提下,PC产业已经失去了前进的动力,而windows8笔记本可以说是唤醒了PC产业,前提是要颠覆现在的笔记本电脑。 第三,  Windows8一定要定位成用户的首台PC 上网本的教训仍然让人记忆深刻,被定位成用户第三台PC的上网本没2年就销声匿迹,这也被看做是PC产业自救失败的经典案例,而失败的根本性原因一方面是非全功能的上网本本身就是蹩脚的垃圾货,而又被强行定位成台式机、笔记本之外的第三台电脑。 Windows8要成功就必须要完全替代市面上的所有笔记本电脑,从而实现规模效应,用性价比卓越的全功能windows8笔记本替代传统笔记本,让用户集体扔掉旧电脑换新电脑,带动整体产业升级,PC产业链的企业自然都有钱赚。然而可悲的是windows8新型笔记本的尺寸被微软定位在了10.6英寸,并称这是未来的主流尺寸。 第四,  windows8不成功便成仁! 由于摩尔定律的失效,wintel联盟的解散,CPU等硬件的瓶颈,软件和互联网无法带动用户需求增加,导致PC产业基本停滞发展,用户更换PC的频率越来越低,一个将死的产业迎来了windows8,这是久旱逢甘霖,如果这场雨下不透地面,PC产业将失去发展的机会。 Windows8不成功便成仁!  
  • 热度 8
    2011-10-28 14:27
    1769 次阅读|
    6 个评论
      说这句话的时候,心里感觉很凉,似乎有一种杀气袭来。此时想起毕淑敏老师在写《我很重要》的不安,仿佛有刀架在我的脖子上,不敢动弹。前天下午4点诺基亚如约而至世界大会,发布了与微软合作后的首批Windows Phone手机 Lumia 800 和 Lumia 710。此时,业内认为,新产品将决定诺基亚的命运走向,是其孤注一掷后希望借此走出阴霾的最后机会。各大媒体报道时采用“风烛残年”“能否扳回一局”“能否起死回生”“凤凰涅磐”“力挽狂澜”“背水一战”“救命稻草”类似的标题,显然透露出对诺基亚前景的不安和隐藏对新产品的期待。帝梦难续?还是王者凯旋归来?拭目以待?   想起月初苹果发布iPhone 4S之时,网上也是骂声一片,创意不足,仅小幅度升级。最后这款不被大家看好的iPhone 4S百万的预定数再次刷新了苹果iPhone的记录。开始的苹果iPhone 4S预定的第一天24小时内,iPhone 4S的预定数超过了一百万。而在去年苹果iPhone 4预定之时,首日的预定数为60万台。用户和市场终究会冷静下来,而之前的骂声也是由期望过高而造成的巨大的失落感。   发布会开始至今, 各大媒体对产品,评论褒贬不一。从笔者看来,更多的是不看好。单核,没有前置摄像头,创新加速度慢,硬件配置保守,不切合实际的价格……似乎这些硬伤,确实让很多诺粉表示很受伤。我个人认为,不一定如大家所想像的那样悲观。再说,诺基亚强大的工业设计,也为其增色不少。   诺基亚作为前任龙头老大,纵然目前大家认为其千般不好,不妨再等等,看看市场的反应。不要把话说得太早了!   以上仅代表我个人的观点。相信诺基亚给我们带来的不只是遗憾,更多的是惊喜!等待市场数据对诺基亚的平反,一如苹果的iPhone 4S。在下面来自爱范儿网:Nokia World 各方媒体评价汇总。   在 Nokia World 上诺基亚(Nokia)的 Windows Phone 机型,首次公开亮相。正如 Stephen Elop 就任诺基亚 CEO 之后发的公开信所说的一样,当时的诺基亚正处于一个“燃烧的平台”,为了拯救自己,诺基亚不得不携手往日冤家微软,推出 Windows Phone 手机。 这一年诺基亚必定进行了痛苦的转型。想必在台上大吼“AWESOME”的诺基亚项目于产品管理高级副总裁 Kevin Shields,一定深有体会。这次大会,对处于关键性十字路口的诺基亚,具备非凡的意义,而到底媒体如何看待这次大会? Wired 的  Charlie Sorrel : Lumia 800 有极大的潜力,它好比过去的 Nokia 3210 和 3310,必定比 Android 掌上设备受广大市场欢迎,因为 Android 前后矛盾不一致,丑陋的用户界面、糟糕的电池以及缓慢的触摸反应。祝好运,诺基亚! 纽约时报的  Kevin J. O’brien : 新的智能手机,让微软和诺基亚寄予厚望。 ZDNET 的  James Kendrick : 如果诺基亚的 Windows Phone 产品进入美国,我们将持续紧密关注。他们看起来真的非常棒,诺基亚设计了优秀的硬件。 TechCrunch 的  CHRIS VELAZCO : 如果诺基亚未来的计划依然毫无迹象,那么 710 和 800 将会是冰山一角。有趣的是,昨天四处流传高端机型 900 的谣言,大会上并没有出现。他们的第一台 Windows Phone 手机,极大地帮助了诺基亚摆脱不良的名声。 Engadget 的  Sharif Sakr : Lumia 800 现在是唯一一部完全内置导航功能的 Windows Phone 手机。诺基亚公布 Drive 导航服务,从外观和感觉上都与之前 Ovi Maps 套装相似,能让用户感到舒适。 所有人被告知,公司(诺基亚)承诺提供(独一无二的诺基亚式”体验——猜测他们光滑的硬件不会是唯一突破 WP7 包装的地方。 ReadWriteWeb 的  Dan Rowinski : Elop 称 Lumia 800 是“第一台真正的 Windows Phone 设备”。他也许没弄错。
相关资源
  • 所需E币: 0
    时间: 2020-9-26 00:25
    大小: 10.14KB
    上传者: LGWU1995
    使用Python开发Windows桌面程序
  • 所需E币: 0
    时间: 2020-9-26 00:39
    大小: 10.14KB
    上传者: LGWU1995
    使用Python开发windows桌面程序
  • 所需E币: 0
    时间: 2020-9-23 01:17
    大小: 12.43KB
    上传者: bwj312
    使用Python开发windows桌面程序
  • 所需E币: 0
    时间: 2020-9-10 01:42
    大小: 1.11KB
    上传者: Goodluck2020
    microsoftwindows脚本技术教程
  • 所需E币: 1
    时间: 2020-9-3 12:51
    大小: 251.71KB
    上传者: symic
    WindowsCE开发初步
  • 所需E币: 1
    时间: 2020-9-4 15:12
    大小: 80.5KB
    上传者: zendy_731593397
    windows蓝屏错误对照表
  • 所需E币: 5
    时间: 2020-8-25 09:16
    大小: 120.9KB
    上传者: zendy_731593397
    PCI总线接口芯片CH365Windows2000终端卡方案
  • 所需E币: 0
    时间: 2020-6-17 16:34
    大小: 232.29KB
    上传者: zendy_731593397
    Windows下快速安装Cygwin
  • 所需E币: 4
    时间: 2019-12-26 10:51
    大小: 320.03KB
    上传者: rdg1993
    本文就此介绍了WindowsCE的一些基本特性,并指出过渡到基于无线装置的软件开发所应具备的知识。……
  • 所需E币: 3
    时间: 2019-12-26 10:47
    大小: 4.32MB
    上传者: 978461154_qq
    WindowsCE设备驱动程序开发指南……
  • 所需E币: 5
    时间: 2019-12-26 10:47
    大小: 13.96KB
    上传者: wsu_w_hotmail.com
    WindowsCE开发入门教程……
  • 所需E币: 4
    时间: 2019-12-26 10:36
    大小: 929.38KB
    上传者: wsu_w_hotmail.com
    WindowsCEBSP1.2……
  • 所需E币: 4
    时间: 2019-12-26 10:36
    大小: 248.49KB
    上传者: rdg1993
    WindowsCE开发初步……
  • 所需E币: 5
    时间: 2019-12-26 10:36
    大小: 5.49MB
    上传者: 238112554_qq
    WindowsNT下最负盛名的专用调试工具……
  • 所需E币: 4
    时间: 2019-12-26 10:36
    大小: 5.47MB
    上传者: 微风DS
    Windows下的最负盛名的专用调试工具……
  • 所需E币: 3
    时间: 2019-12-26 10:36
    大小: 326.97KB
    上传者: 二不过三
    Windows下一款出色的软件调试工具……
  • 所需E币: 5
    时间: 2020-4-3 15:48
    大小: 3.12KB
    上传者: wsu_w_hotmail.com
    如何编写WINDOWSCE随着usb设备的普及,摆在开发人员面前的驱动开发任务也是越来越繁重了,特别是对于一些嵌入式开发厂商来讲,由于设备所采用的操作系统不同,相应的硬件接口也是不一样的,开发相关的usb驱动程序更是难上加难。windowsce.net是微软推出的功能强大的嵌入式操作系统,国内采用此操作系统的厂商已经很多了,本文就以windowsce.net为例,简单介绍一下如何开发windowsce.net下的usb驱动程序。首先要熟悉一些usb的基本概念,当然最好把usb1.1的协议看一遍,(当然现在2。0的协议都已经有了)http://www.usb.org上可以下载,我记得好像有个中文版的,翻译的还可以,http://www.driverdevolep.com上有的,具体位置记不太清楚了,中文版的协议可以快速翻一边,了解一些基本的概念,但是设计到一些关键性的东西最好还是看英文版的心里比较清楚些。这里我就不介绍usb的基本协议了,假设用户已经熟悉了usb设备的一些基本的概念,并且对winowsce.net的开发有一定的了解。下面简略介绍一下windowsce.net中usb设备驱动开发的一些基础知识。windowsce.net的usb系统软件分为两层:usbclient设备驱动程序和底层的windowsce实现的函数层。usb设备驱动程序主要负责利用系统提供的底层接口配置设备,和设备进行通讯。底层的函数提本身又由两部分组成,通用串行总线驱动程序(usbd)模块和较低的主控制器驱动程序(hcd)模块。hcd负责最最底层的处理,usbd模块实现较高的usbd函数接口。usb设备驱动主要利用usbd接口函数和他们的外围设备打交道。usb设备驱动程序主要和usbd打交道,所以我们必须详细的了解usbd提供的函数。主要的传输函数有:……
  • 所需E币: 5
    时间: 2020-4-3 15:49
    大小: 3.12KB
    上传者: givh79_163.com
    上午发的有问题,再次重发。不好意思,回家过来没有看到you5...,windowsMobile5Document……
  • 所需E币: 3
    时间: 2020-4-7 15:41
    大小: 2.85MB
    上传者: 微风DS
    WINDOWS核心编程,WINDOWS核心编程……
  • 所需E币: 4
    时间: 2020-4-7 15:41
    大小: 2.85MB
    上传者: givh79_163.com
    WindowsWDM驱动开发www.icwin.netWindowsWDM驱动开发icwin@icwin.net,sales@icwin.netWindowsWDM驱动开发我们的技术是您的!Wyouken&O4icwin2005年11月Rev.0.1WWW.ICWIN.NETE-mail:sales@icwin.net,icwin@icwin.net我们的技术是您的!1WritebyWyouken&O4icwinwww.icwin.netWindowsWDM驱动开发icwin@icwin.net,sales@icwin.net版权(c)2005-2006,ICWIN保留所有权利RevisionHistoryRevisionV0.1Comments第一部分发布IssueDate11/10/2005AuthorWyouken&O4icwinWWW.ICWIN.NETE-mail:sales@icwin.net,icwin@icwin.net我们的技术是您的!2WritebyWyouken&O4icwinwww.icwin.netWindowsWDM驱动开发icwin@icwin.net,sales@icwin.net目录第一章概述...........................................................................................................................61.1本教程的规划:...........................................................……
广告