可以把 EAX\EBX\ECX\EDX 作为深度为四的栈使用，
PUSH=MOV EBX,EAX; MOV ECX,EBX; MOV EDX,ECX; MOV #ADDR,EDX;
POP=MOV EDX,#ADDR; MOV ECX,EDX; MOV EBX,ECX; MOV EAX,EBX;
大概是这样，脑袋中的汇编大概是 18 年前学的了。

JVM 是基于栈的。我的硕士论文做的基于某个体系的 JVM，那个体系是基于栈的硬件结构，只是用 C 做了一个模拟器，没有实际进行电路设计。

单纯的数据有意义也没有意义。有意义在于它确实能够描述客观状态，但是没有意义在于它只能描述某一时刻的状态，而随着时间的推移，这些数据就变得无用——数据有自己的生命周期。
加上业务的数据，就变得丰满，可以随着时间的推移，产生随动的变化——生命周期得以延长。

当然后边还有数据管理治理等等各种维度的东西。但是根本上讲，无论电子化与否，人类社会的存续既是数据的存续。

@elfive DGX Station A100 一台大概 1.44M 元，买吧，没几个钱

好像我是那一批工程机的用户，目前还留着当时的后壳，因为后来好像有个活动，能用工程机换正式机

首先，你只是万千手机用户中的一个，厂商要面对的是万千人，不是你一个人；
其次，甭管升降、开孔还是啥，都是经过强度测试的，特别是机械结构，如果强度不足，那考验的就是客服、维修、公关等各环节后期能力；
最后，厂商的广告么，理念灌输么，随他去吧，找自己想要的，平衡产品能力和自己的投入，理性消费。
完活

反倒觉得坚决扔内存，搁硬盘那才是大炮打蚊子

有云不用，吃饱了撑的，即便说公网的问题，可以设置防火墙和路由限定访问啊

反代、rewrite，无非是这些

1 、消息免打扰
2 、随时小删除（对话）
3 、不定期大删除（对话）

@chutsetien 6# 虽然个体观点不同，但是 WX 目前是社交第一工具，窃以为，你这样抛弃这个社交工具，结果就是被社交抛弃。当然还是那句话，个体不同，观点不同，对待社交的看法不同，维持社交的方式不同。

抛开问题，纯说方案，最好的还就是 NAS，

第一，来源：NAS 自己上 BT 或者其他什么下载。相比台式机，始终开机，功耗低等等。
第二，播放：TV 或者相关设备，可以搞 KODI，或者支持 Samba 的软件，然后直接播放文件，相对灵活，但是 iOS 之类的设备，需要 NAS 弄个 Plex 之类的，走网路串流。
第三，链路：NAS 本身传输上经过调教问题不大，路由（交换机）、AP 以及终端网卡等保证链接，提供相关网络保障。

@cnibolee 4# windows 解什么码，TV 直接怼源文件，解码都在 TV 上
@fhw12372 5# DLNA 连完美 FHD 都困难，4K 就绕开 DLNA 吧
@greenskinmonster 6# 如果 LZ 能专业到搞这个，那这个帖子就不用发了，有线+大文件对拷最简单

LZ 确定是 NFS ？ windows 搞 NFS，可是得折腾一小下的，安装一些软件的。LZ 应该说的是 windows 的文件共享。所以，再找一台机器，网线连路由，直接对拷文件，看一下速度。然后两台机器绕开路由，网线直接连接，再对拷看一下速度。最后看一下 TV 的无线链路，你的电视我大概率猜是 2.4G 的 WIFI，最高握手速率 300Mbps，最大传输速率 15-20MB/s 。
做完这些，再说怎么处置。

一、要对拷文件而不要通过播放器：播放器会根据码率做缓存加载，于是文件传输是时高时低的；对拷文件能够打满能力传输速度；
二、视频码率：1080p 的码流普遍 2Mbps-10Mbps，所以 windows 上 10Mbps(min)轻松满足，而 4k 普遍 10Mbps 以上，甚至有的 50Mbps-100Mbps，对网络的传输能力要求很高；
三、盲猜路由、无线链路是个坎，大数据量，ac 、ap 搞不动了。

补全相关信息再说吧。

以数据来讲，除非 key-value 不管用，否则 json 无可替代的优势。
但是以数据来讲，为啥要加注释？

那加了注释，就不是数据维度了。而是 coding 编码的事情了，那不要说 json 不行，而是框架不行。

深圳说贵，北京嘿嘿、呵呵、哈哈、2333

@hanguokai 2#，内嵌字幕流，那你就费劲了，需要播放器能够分离字幕流，目前我感觉普遍网页的播放器（其实就是浏览器的播放器）很少有这能力。
至于外置 srt 或者 ass，那倒是好办，js 解析，然后 div 层覆盖。

相对路径、绝对路径
看到问题，猜了大概，看到 6#确定了猜测。
但是解决这个问题，很大情况下源头不太好修改——因为如果他容易修改的话，他就不会用绝对路径这个 SB 的策略了——于是解决办法很有可能需要挨个 URL 做反代。

然后不知道 proxy_reverse

另外，location 最好用 2#的匹配，当然写你那样也没啥问题。然后结尾斜杠的问题，保持统一，要有都有，要没有都没有，/xxx 和 /xxx/是两个 URL 。

首先平台肯定二次编码，因为他要给观看用户不同的编码水平，这个你也控制不住。
其次你上传给平台的原始文件，也就是 PR 输出的，应当尽量清晰（也就是码率应当尽量高），4K 的应该 10M+，FHD 最低 2M+。
当然了，既然本地编辑，可以照着 20M+的输出，至于平台怎么二次处理，那就不你所能控制得了。

所以现在你没有说清楚，你本地输出的，到底多少码率。

最后，码率决定了体积，体积决定了上传时长。于是要引入编码器的概念，刚才说平台二次编码，他所用的编码器你控制不到；你也只能控制本地输出的编码，好在大部分编码平台都能识别； 4K 级别，一般用 x265/hevc 多一些。然后还有声音编码问题，要求不高就不说了。
最后再说一件事情，HDR/10bit，色彩空间的问题。这个话题就大了。如果能的话，LZ 先补习一下相关基础知识了。