Arm 公司凭什么就让海思、三星、联发科、高通等等公司只能向它买授权，而不是独立山头自己搞呢？

[Pzdmultiverse]

如题，小弟没理解，为什么 Arm 可以一直收授权费，自己了解了下，Arm 指令集相对来说不复杂，而微架构像海思、三星、高通、联发科也可以自己搞，为什么这些拿 arm 授权的公司不自己搞一个指令集呢？这当中的技术壁垒在哪里呢？求大神科普,万分感谢！

[systemcall]

没生态。你打算自己搞架构，就要自己弄起来生态
之前 MIPS 在嵌入式用的挺多的，后来好多都换 ARM 了
而且你说的那些公司，这几年基本上也是公版架构了，顶多稍微改一下

[secondwtq]

第一，ISA 不是你想的这么简单的事情
你可以去了解下最近的新星 RISC-V，然后思考下，为啥这么多资源投在里面，这东西进展还是这么慢
其实 WebAssembly，以及很多标准化的东西都是类似的道理

[Pzdmultiverse]

@systemcall #1 请教下，这里的生态，具体是指的什么呢？
像 Android 生态，我理解就是开发者、使用者组成，那像这个生态是什么样一个组成呢？

[linksNoFound]

自己搞花钱太多,100 万美元买来立马就能开干,和投入 10 个亿美元赌一个未来

[Leonard]

你说的这几个现在都是 ARM 公版架构上改了，自研架构都翻车了

[czfy]

“相对来说不复杂”
真当从 0 开始，完全不涉及现有知识产权，不复杂？

要真不复杂，为什么三星自己做 SoC 这么多年了，还是半死不活？
要真不复杂，华为海思能有现在的惨状？

RISC-V 也算是明日之星了，但只看到阿里做了个玄铁 910，最近确实有运行 Android 的消息，然而距离量产做手机 SoC 也是十万八千里
还没听说过谁量产基于 RISC-V 的手机 SoC，如果有行业里的人科普一下情况也是好的

[secondwtq]

第二，uArch 也不是你想的这么简单的事情。
高通在十年前是自己的微架构，但是被 64 位的 A7 偷袭了，来不及搞新架构，就公版架构套了一个出来，你猜那代产品叫啥？就是大名鼎鼎的骁龙 810
后来 820 又整出了个新架构，但是表现一般，再往后就接着用公版了
三星的自研架构前段时间刚黄。就算在的时候，貌似也是骁龙版比猎户座版更好，你猜是为啥……
海思也是小改公版
联发科更逗，公版做的都不算太好
你想想为啥手机处理器除了苹果之外没人做 uArch

[secondwtq]

第三，你有本事做 ISA，你有本事做 uArch，你有本事做 Rosetta 么？

[jmc891205]

因为付 ARM 授权费比自己研发便宜

[echo1937]

09 年的时候，Intel 想进军手机 Soc，搞了一个 Android_x86，
这个工作和苹果现在搞的 Mac OS on ARM and x86 工作非常类似。

第一步，Intel 就需要配合谷歌把 Android 移植到 x86 服务器上，从底层驱动到移植 Dalvik 虚拟机，工作量还挺大的，

第二步，x86 和 ARM 的指令集不同，有些应用还是不支持运行在 Android_x86 上，为了快速解决这些问题，英特尔试图通过技术去完善，开发了一种转换技术“Houdini”。“Houdini”相当于一个中间层，可以让原本不兼容的应用跑在 X86 上。但这种强行结合的技术运行起来往往效率不高，容易出问题，且会增加 2%左右的耗电。

第三步，为了彻底解决转换层的问题，英特尔就提供了 X86 的 NDK 。开发者只需在应用中支持这个 NDK，应用在提交时会自动生成 2 个 App，设备在下载时会根据自己的架构下载合适的 App 。这种方法并不难，效果也最好，难的是如何让众多开发商甘愿合作。所以英特尔以及手机厂商会去和应用厂商挨个合作，督促其支持 X86 的 NDK 。

第四步，Soc 有了，系统也支持了，没有手机厂商用怎么办，Intel 到处找硬件厂商推销自己的处理器，又是合作又是补贴，联想出了几款，其他厂商也有少量出货，但总体机型并不多。

你看，x86 这种成熟而完善的处理器，已经有完整工具链支持，要想和 ARM 竞争都如此困难，你从无到有设计一个新的指令集，成功的几率有多大？

[fline]

因为人家的文化自信靠的是有文化，不是有自信。

[fiveelementgid]

@fline 谁让你发这些内容的
你哪个单位的？
你们有什么目的？

[secondwtq]

@echo1937 其实要真是新 ISA，还得折腾 gcc, glibc, kernel 一套全家桶……
然后人家 ARM 能跑 Windows，你不行

[secondwtq]

@fiveelementgid 你取得有关部门许可了吗？你背后是谁，发这些想干什么？你想颠覆什么、破坏什么？

https://i.loli.net/2021/02/04/94hQRUBHKbsXVra.png

[cmostuor]

ISA 只是做一个 CPU 里的一小部分, 能做出一套新的 ISA 不等同于就能做出一块可以商业化的 CPU 不然 RISC-V 为啥开源, 做 CPU 都如此的难更何况做 SOC 那就更复杂了.

[cmostuor]

来给你个非商业但完整的 uArch 项目 https://github.com/mads3009/uarch_project

[Pzdmultiverse]

@echo1937 #10 学习到很多，感谢！

还有两个问题，不知道可否再帮忙解答一下：

1. 关于第一步：把 Android 移植到 X86 上，这一步移植主要是做什么工作，可以具象的说一下吗？

2. 关于第二步：如果已经 Android 移植到了 X86 上，那在 Android 上的 APP 为什么会有一些特殊的还不支持呢，对 APP 的支持我理解是操作系统层级之上，而指令集在操作系统之下，操作系统应该就屏蔽了指令集对 APP 的区别，所以对这里有的 APP 还需要再去单独适配 X86 指令集，不是很理解，能举一个具象的例子吗？

行业外的人，这些基础不是很理解，如果提的问题很弱智，请大佬见谅，感谢大佬帮忙解答！

[echo1937]

@Pzdmultiverse #17

第一步，写底层驱动，移植 Android OS，移植 Dalvik 虚拟机，主体就是这三大块。如果你是纯自研 CPU，甚至还要自己写编译器，自己搞工具链，把 Android 底层的 Linux 先移植过去。

第二步，我引用一段内容。

“大部分 Android 应用都使用基于 Dalvik Java 代码开发。理论上，由于 Dalvik 代码在系统的虚拟机中执行，在 x86 的 ATOM 平台上不会有性能损失。但由于虚拟机执行效率的有限，对于一些高性能追求的应用，谷歌允许开发者使用原生的 C 语言代码。而原生代码是针对硬件平台编译，x86，ARM 或是 MIPS 都有其相应的二进制文件。通常来说，针对 ARM 平台编译的二进制代码，x86 的处理器是无法直接运行的。而主流的安卓产品均采用 ARM 处理器，尽管很早之前，Google 的 Android NDK 就引入了 x86 编译的选项，但至今还是有相当一部分应用只针对 ARM 平台进行了编译，这就造成了 x86 安卓平台兼容性问题。” --- https://www.igao7.com/news/201406/x86.html

也只有苹果这种自己开发芯片，自己开发 S，自己做硬件产品的厂家，Mac OS 才能说迁移到 ARM 就迁移到 ARM，甚至即便如此，Apple 也是买了 ARM 的指令集，而没有自己开发一套指令集。

[fiveelementgid]

@secondwtq 还是你背的比较熟(🐶

[yafoo]

记得这些公司好像都有 arm 的股份

[wy315700]

@Pzdmultiverse
屏蔽了指令集对 APP 的区别的不是操作系统，而是编程语言。比如 java 、python 、php 之类。

[systemcall]

@Pzdmultiverse #17
安卓当年本来就有对应很多 CPU 架构的版本。涉及到很多底层的东西，不是换个驱动重新编译就可以解决的。你要是有兴趣的话，可以试着编译一下 OpenWRT，之后在 MIPS, X86, ARM 架构的设备上面跑一下，东西也都很便宜。买有官方支持的设备就行了，最好是不用改造的那种
把 Android 移植到 X86 上，得到的是可以运行 Android X86 版本软件的 Android X86 版本系统。比如 Linux 就可以移植到很多不同的 CPU 上，移植过后软件通常是要重新编译才可以用的，当然如果涉及到了内联汇编或者是对寄存器操作的那种，重新编译也没用，得重新写
但是当时 Android 下的软件大部分都是跑在 Dalvik VM 上的，本身被编译成了与 CPU 无关的字节码，所以移植了 Dalvik VM 就可以了。不过，很多软件都通过 Android NDK 调用了一些.so 的二进制文件，这个是和架构有关的，是原生代码而不是需要虚拟机进行翻译的字节码。特别是游戏引擎由于效率的原因一般是用 Android NDK 来调用原生代码
安卓的软件基本上都是跑在用户态的，用户态提供二进制翻译是有很多办法的，Intel 在那个时候做了 Houdini，可以解决大部分时候的问题。不过 Android X86 版本的 SDK 和 NDK 早就有了吧，感觉要比 Houdini 早出一些
异构虚拟化的性能损失非常大，以前没有普及 llvm 甚至 jit 都不普及的时候是非常慢的，这点和通过处理器自己的硬件虚拟化特性来运行同构的虚拟机是不一样的
至于指令集不一样无法运行，我以前遇到过不少。在很多年以前 ARM 架构还不像这么普及，还有不少 MIPS 架构的产品。哪怕 ARM 本身，也存在着互不兼容的 ARM9 ARM11 ARMv6 ARMv7，还存在着是否有硬件 FPU 的区别。在安装 APK 的时候，如果软件使用了 NDK，会检查是否有对应架构的二进制文件，没有的话会拒绝安装。哪怕是现在，也有 ARMv7 和 ARMv8 这 2 种，不过 ARMv8 一般是 64 位的（也有 32 位的 Cortex A32 架构以及许多采用了 Cortex A53 甚至更好的架构的产品中使用了 32 位 Android 所以无法支持 64 位 ARMv8 软件的情况）。大部分的 ARMv8 CPU 是支持 ARMv7 的，安卓系统也是支持的，所以软件只用做 ARMv7 的就可以跑了，但是如果是 ARMv8 的软件，装在 ARMv7 的设备上是不能跑的，一般连安装都不行

[xumng123]

生态好，不吃独食。

[Osk]

看到上面 ARMv6 我想起了我第一个安卓机就是 ARMv6 的， 大概是 PXA??? SoC 。我的青春啊。。。

话说 Intel 当年把 ARM 架构的 pxa 系列 SoC 给卖了，不过 Intel 搞 ARM 确实有点尴尬

[Jooooooooo]

"并不复杂" "可以自己搞"

所以楼主还不快去应聘这些公司, 这得给公司省多少钱啊

对公司来讲, 能在原来必须花钱的地方省钱是求之不得的事情

[leavic]

python 用起来也不难，为什么我不自己写一套 python 来用呢？因为我不傻。

[agagega]

小道消息：Apple 内部有团队在自研指令集。不过这也就是内部研究，可能永远不会启用。Google 啥的肯定也有人马干这件事

[Tink]

@Pzdmultiverse 生态就是别人是否会针对你的架构开发操作系统

[DoctorCat]

The remarkable story of ARM
ref: https://medium.com/swlh/the-remarkable-story-of-arm-85760399c38d

里面提到了几段：ARM 作为 RISC 芯片的优点、ARM 母公司拆分、与 Apple 早期合作。

This was a critical part of their success — licensing the processor design to anyone who wanted to make their own versions of the chip.

The happy accident that ARM processors had the best MIPS/Watt (highest performance for the lowest power) is the key thing that propelled their processor to success in the exploding world of smart phones.
Of course now ARM are focused almost entirely on that MIPS/Watt figure because that’s what customers are demanding — longer battery lives for their laptops, phones and watches.

总结起来，个人理解是：ARM 标准的优势是有 Apple 、三星等大厂合作的案例，而且符合当今商业时代的要求。

[DoctorCat]

抛开生态，谈你提出的这个问题： “为什么这些拿 arm 授权的公司不自己搞一个指令集呢？”
- 要抄袭么？这有知识产权问题。

[KHfqLAYYS6BKJT3R]

中国为什么不做一个真正自己的系统？

[wunonglin]

@cjzlol #31 气抖冷

[Pzdmultiverse]

@wy315700 #21 那这样不更说明应用不依赖指令集了吗~

[wy315700]

@Pzdmultiverse
按照 Google 最初的设想，Android 程序用 java 开发，的确是指令集无关的，应用可以很方便的在各个平台上运行。
问题是 Android 应用不全是用 java 开发的。部分性能依赖的程序用了 C++，甚至还有用汇编的。。

[Pzdmultiverse]

@wy315700 #34 C/C++是依赖指令集的吗？ 汇编我理解就是指令集的一种助记符，所以是和指令集强相关的。
那 Android 系统在研发的时候，因为可能要用到汇编，所以有可能是先选择 CPU 架构，再开始开发的吗？

[Pzdmultiverse]

@Pzdmultiverse #35 不好意思，第二个问题，我看错了，请忽略

[wy315700]

@Pzdmultiverse
C/C++会编译成二进制代码而不是中间代码，所以是目标程序指令集依赖的，移植到另一个平台需要进行重新编译。。
让大家对程序进行重新编译，，需要强大的号召力，当然也要看市场份额。微软这么多年依旧没有抛弃 32 位系统就是因为大量的程序是用 32 位开发编译的，源代码没有人维护甚至已经丢失。而苹果就可以果断抛弃 32 位。



当然如果直接能编译，那还是好事，更多的情况是写程序的过程中有依赖于本平台的设计导致需要重新编码。

举个最简单的例子。gcc 编译器下，X86 平台的 long 和 int 一样都是 32 位的整数，而 X64 平台中 long 是 64 位的整数，int 依旧是 32 位。如果代码里混用了 int 和 long，，，那就等着推倒重写吧。。。。

[weksomnus]

对于 SoC 来说，Arm 提供的不仅是 CPU 核 /ISA 授权，同时提供了配套的 SoC 外围 IP （ Bus 、NoC 、Cache 、DebugInterface 等）、软件工具链。如果用自己的 ISA 或者 RV ISA 的 IP 核，与之匹配的 IP 资源匮乏。
对于 Android 来说，存量 App 中的 Native Lib 过多，对于消费者产品需要推动开发者依据不同的后端（ ISA 后端）进行重新编译、打包、发布。
顺便 Arm AArch64 系列的 ISA 已经很优雅了。

[Pzdmultiverse]

@wy315700 #37 感谢大佬解答，学习很多~

[Pzdmultiverse]

@systemcall #22 感谢大佬解答，学些到很多~