不懂就问：软件适配 ARM 是开发者意愿问题还是能力问题？

[hourann]

迁移架构真的有这么难吗？我知道微软做了几次失败的尝试，推出了跑在 ARM 上的电脑用户体验和市场反响都很差，究其原因是很多软件用不了。绝大部分开发者的软件开发过程不会涉及汇编、SIMD 等依赖具体指令集的内容，所以在我理解里大部分情况下适配 ARM 只是换一下编译目标这么简单。微软 surface 的失败可以解释为它只是 Windows 下的一个极为小众的异构电脑，无法吸引开发者适配的兴趣。而苹果拥有对 macOS 设备的绝对管辖权（黑苹果除外），所以我觉得苹果推 ARM 会比微软顺利的多？

[salor]

微软的移动生态压根就没建立起来。。

iPad 应用能够做少量工作就能适配到 Mac，Twitter 就是。我觉得还是应用场景和交互方式的区别问题，复杂一点的适配效果远不如重新设计。

[murmur]

跟微软有什么关系，连投入产出比最高的服务器应用都还是 x86，你想让桌面级先吃螃蟹，欺负人呢

[rockyou12]

很多底层依赖就没有 arm 的包，上层开发（桌面或者 web 服务）当然就没法搞

[nguoidiqua]

当然会简单很多，这种东西说白了就是平台和开发者谁更强势的问题。

人都是懒的，懒得折腾而已，苹果说两年内全部换，那不换也不行了，要么不做了。

这就是苹果跟微软和谷歌的区别，它掌握了它整个生态的硬件基础，你要用新设备就没法不跟着它走。

[walsh]

2B 市场甲方客户就是上帝，享有对软硬件服务的绝对控制权，如何不得罪他们迁移才是难点。前阵子不是说美国政务系统还在招 COBOL 码农吗

[Kilerd]

你的服务依赖底层库吗？ 如果依赖，那么很大可能就是会依赖到汇编或者直接依赖 x86 某个指令的模块。这些上游库支持了 ARM，你才可能把整个应用无痛的编译到 ARM 。

[nicevar]

别说 arm 了，一个 Linux 的开源软件有时候编译一大堆依赖都出问题，你想想一个本来没多大的项目结果你话大量时间去编译了七八个库是什么心情。

[gargar]

时间问题

[whypool]

钱的问题

[leoskey]

还真的比较难，不少生产力软件底层依赖 x86

[meteor957]

钱的问题 面向工资编程

[wasd6267016]

工具问题
XCODE 的统一性 决定了 mac 可以这么做

[delectate]

有两个办法：
1 、系统及兼容层，牺牲 8 成效率去支持 x86 的 app （还不一定能支持 64 位的）；
2 、强力补贴开发者，改那些万年不动的代码，让基础库做修改，支持 arm 的指令集，但是毕竟非主流，估计日后也不可能有任何 bug fix 了。毕竟 arm 在过去和可见的未来，都很难真的作为生产力工具（除非把看剧当作生产力）

[Leonard]

看你开发的软件是啥了，如果只是普通用户用的（比如天气预报之类）就没什么影响，更新 xcode 重新编译一下的事，涉及比较底层的会麻烦一些

[xxzs]

memory model 不一样，所以在 x86 上正常跑的 C 代码在 ARM 上可能工作不正常

[charlie21]

不用适配阿
直接开发 UWP 就可以了阿

If you app is pure WinRT then you can select Architecture Neutral which will create an application package which will on all devices; x86, x64 and ARM. Visual Studio will take care of what needs to be done...
https://stackoverflow.com/questions/12881005/using-windows-store-app-class-library-for-winrt-arm-application

精通 UWP，未来是你的

[wipbssl]

@charlie21 uwp 应该算是被微软放弃了吧，build2020 上推出的 project reunion 要把 win32 和 uwp 统一起来了

[azh7138m]

迁移架构真的有这么难吗？

应该比较费钱，IA64 这种哪怕最后只面向特定的企业服务，也没活下来，intel+合作伙伴在上面投入了不少钱 /20 年的时间

> 在我理解里大部分情况下适配 ARM 只是换一下编译目标这么简单

并不是，比如之前有个小东西要适配一个 MIPS，因为用到了 ptrace，返回的结构和 x86 下不一样，得自己对一下结构体
能做到 "只是换一下编译目标"，是因为之前有无数苦逼开发者做了适配

[May725]

让开发者去适配，也只有苹果才干得出来了，要是微软也这么干，不得喷死。

[May725]

积累起来的程序，可能源码都找不到了，编译更别提了

[lxml]

成也苹果，败也苹果，有时候能不能成还是取决于腿粗不粗的问题。

CUDA on mac 黄了，两条都是大腿聊不来，用户群达不到割肉的水平，那就互相伤害啊。

Adobe on mac 苹果就还是知会下，大家老老实实配合开发有 bug 苹果也配合第一时间修，毕竟是互相成就的关系。

微软的号召力嘛…… 从丢了移动端以后真的就别提这个词了，Vscode 就是极限了

[shutongxinq]

然而底层只支持汇编写的的 x86 的软件已经上不了 Catalina 了。

Yosemite 支持的软件，Catalina 有多少能运行，大家心里都有数。

[huangzhe8263]

反正已经准备从 Catalina 降级回 Yosemite 了。

[singerll]

我们原来有个软件移植到 arm 平台有问题，最后是研发改了几天代码才搞定的，当然我们是个非常小的软件

[xingheng]

@shutongxinq Catalina 只是放弃了 i386 吧，x86 还是主要的架构。

至于迁移问题，想想 Windows 为什么一直有那么多老旧软件大都是基于 xp 开发的，常年没有更新，微软直接放弃了 x86 必然会挨骂。

关于苹果只支持在 ARM 版 mac 上运行 iOS app，我觉得一定程度上是苹果偷了个懒，现在的 iOS 设备都是 arm 系列架构，因为 iOS 的成功所以才敢这么大胆的放弃 x86 。至于放弃了 x86，大概率是兼容目前现有的 ARM app 到 x86 的难度和工作量太大了，所以放弃了。

[msg7086]

底层有太多太多涉及到汇编和 SIMD 的代码了。
换平台也不是软件重新编译一遍就解决的。。
像上面提到的，底层库怎么办？任何一个稍微大一点的项目都会涉及到很多 CPU 密集型的类库。视频，音频，UI，计算，等等，哪一个是不需要跑汇编的。那么重编译的时候你完全放弃掉汇编优化吗？不可能的，性能差多少倍啊。

别说 x86 到 ARM 的适配，就是 32 位 x86 到 64 位的 x86_64 适配有时候都要花很长很长的时间。你碰过那种代码里有 MMX 和 3D Now 指令集汇编的情况吗？试试看重写成 SSE 和 AVX 要花多久的时间吧……

[shutongxinq]

@xingheng 你知道 x86 里面那个 x 是什么意思吗？😂😂😂

[shutongxinq]

@msg7086 能举一个具体的例子，给一个汇编优化的来源吗？我想去亲眼看看你说的汇编优化。

[msg7086]

@shutongxinq
https://github.com/msg7086-forks/AviSynthPlus/commit/15ed33dc6e5d886d238e30de3dea79022306c0db

这两天正好在看的代码。

[msg7086]

这个项目之前一直在 Windows 下跑，纯 32 位环境。前几年终于移植到了 64 位，最近开始往 Linux 和 ARM 移植，Linux 已经能跑起来了，ARM 好像还在挣扎。
SIMD intrinsics 出现之前，里面大量的 __asm 裸代码，MMX 和 3Dnow 是主流，SSE/SSE2 都是后来才加进去的。MMX 因为和 64 位指令集共用寄存器，所以在 64 位下编译就得把 MMX 全关了。像上面的例子就是相关函数只有 MMX 版，关了就只剩纯 C 了。
还有像裸 __asm 只有 MSVC 才认，所以 Linux 下把这些用宏关掉以后也只剩纯 C 了。
要往 ARM 移植的话，同一套函数得写三套代码，一套 C，一套 Intel SIMD，一套 Neon，可谓是蛋碎。

像这个例子还算好的，有纯 C 代码，重写的时候只是重新翻译一下而已。最蛋碎的是遇上只有汇编代码的，你得先把汇编翻译回 C，然后从 C 再翻译去 Intrinsics 。这搞一个项目，有时候一不小心就一个月陪进去了。

[xingheng]

@shutongxinq 还真不知道是什么含义，只知道一直都这么描述，包括 x86_64 。请教？

[shutongxinq]

@xingheng x86 的 x 就是以前 286，386，486 里面 2，3，4 的统称。
@msg7086 你这个例子很好。掷地有声。

[msg7086]

@xingheng @shutongxinq
顺便一提，x86 最开始源自 8086，是 80x86 系列的架构名，80186 和 80286 等已经是后续产品了。