> 一家能做的另一家也应该有对应的替代指令
没错，大家都是 CPU，运算当然都能做。

> 如果有一个基础库将两种架构都整合得很好
编译器本身就能把 C 或者高级语言代码编译到目标平台，一般不需要基础库。

> 但如果软件需要深度地直接操作 CPU 的指令
是的，问题就在这里。
比如说很多软件是想当然地「默认」自己会运行在 x86 平台上，所以很多假设都是基于 x86 的。
（甚至有很多软件都是默认自己运行在 Windows 或 Linux 上，导致移植到另一个平台时需要大改代码。）

比如说我现在用的一个软件，2002 年写的，源代码里到处充斥着 MSVC 格式的内联 MMX 汇编。
这意味着什么呢？
首先 MSVC 格式的内联汇编只被 VC 支持，而且只能运行在 32 位上。
所以 Linux 就不能用了，GCC 也没法编译。
其次内联汇编和 MMX 只能运行在 32 位上，所以没办法编译到 64 位。
而且很显然，x86 汇编不能运行在 ARM 上。

那么怎么办呢？

很简单 —— 重 写。

之所以会出现这个问题，就是因为代码编写的时候，一来没有这个技术，二来没有想到以后要移植，所以用了当时的技术和方法去写的代码。将近 20 年过去了，C++也从 1989 版变成了 2017 版，CPU 指令集也从奔腾 3 时代的 ISSE 变成了现在的主流 AVX2，Linux 服务器也开始进入普通人的生活，很多以前都没想过的技术，现在都已经变成了理所当然。但是源代码不会自己进化，还是需要时间精力的投入。这就是为什么小众平台软件支持更差的原因。

另外，就算是能在 ARM 上编译运行，也会因为缺少 SIMD 优化而变得非常缓慢。现代处理器重度依赖 SIMD 并行运算指令，而 ARM 上用的则是 Neon，不仅机器指令不同，上层的 Intrinsics 设计得也完全不一样。没有了 SIMD 优化，运行速度会直接下降一个数量级。所以就算能用，也不一定用得舒服。