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

可以考虑找专业公司做。当然如果价格相差太远的话也可以自己做，不过专业的事情可能交给专业的人更好。

你是计算机专业的，又不是 Java 专业的……

> 一家能做的另一家也应该有对应的替代指令
没错，大家都是 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 优化，运行速度会直接下降一个数量级。所以就算能用，也不一定用得舒服。

@systemcall 比平板更大的屏幕不是问题。键盘的话，可以做成变形本，也可以做成苏菲。
主要是 ARM 这东西是个平台，ARM 的局限非常影响受众。

还有，我说的生产力，指的是拿电脑进行一些复杂的生产活动，例如视频剪辑，软件开发，PS 等等。
Office 虽说也是生产力，但是国内用 Office 能用到「生产力」级别的少之又少。
大多数人是拿来替代记事本用的，连样式排版什么的都基本不会的人多了去了。

ARM 平台现在可能还停留在比较基本的功能上。
比如说 WinARM，你拿来看片上网冲浪偶尔写写 Word 是没问题的。
但是让你在上面剪个 vlog 或者给人修个写真就问题很大了。

@yzql2018 那你就继续这么觉得吧。

首先，大学生这个群体我觉得不应该单独拉出来讲。
就像你说的，很多人在学校里也就是玩，不需要什么生产力。那这些人和一般讨论的「普通人」有什么很大区别吗？直接说以后 ARM 笔记本会不会是普通人的新选择就是了。

然后就是笔记本，又或者说是个人电脑的问题。电脑这个东西本来的目的也就是办公，工作，是一个多用途的设备。如果你只是想看节目，弄个机顶盒或者智能电视就行了。如果你想玩游戏，买个游戏机就行了。电脑本身就不是设计成专门用来做哪件事的。以前人们买电脑，买笔记本，可能是因为并没有可以替代的设备。比如十五年前，没有高度智能的手机，没有强大的游戏主机，没有 3G 无线网络，离开了电脑很多事情都做不了。现在，有多少事情手机干不了呢。

但是如果要生产的话，电脑还是无可替代的。很多场景下连笔记本都不堪用，还得台式机。
ARM 笔记本其实算是个很鸡肋的产品，软件支持度一般，优化较差（很多底层汇编代码要重写），还不如做成托管系统，但是这样就做成安卓平板了。

是抄袭。但是抄袭本身并不见得是一件坏事。开源软件克隆专有软件是很常见的一件事情。

1. Git 服务器是存放代码用的，Git 客户端才是和代码直接打交道的。
2. 作为 Git 客户端时不需要切换用户，默认的 www 就可以用。

但是如果贵司连个懂 Git 的人都没，连安装都要沦落到上论坛问的话，我觉得还是不要折腾了。

可以倒是可以，但是你手里的 fc 卡多大带宽呢？大的话倒是还行。
但是硬盘柜自带 fc 的不太好弄吧…没玩过。

键帽撞键盘，要解决声音问题可以在下面加一个静音垫圈。

--dir-cache-time duration Time to cache directory entries for. (default 5m0s)

就是以前熟悉的元素又要重新满屏幕找了。
前面找个 Commit 记录，找了半天才发现链接在哪。

这个项目之前一直在 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 。这搞一个项目，有时候一不小心就一个月陪进去了。

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

这两天正好在看的代码。

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

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

多年价不就是已经把倒闭的风险考虑进去了么。

@XGHeaven 老莱他们厂做剪辑，内网万兆互联传素材。
你要在云端做这个东西，第一用户的网络行不行，第二服务器的网络行不行，第三服务器的托管费用行不行，第四服务器的处理速度行不行，第五这么高的成本用户愿不愿意买账。