yankebupt

看图最小的 size 才 962bytes...
估计可以排除一些标准格式中光 overhead 就上 K 的压缩 /加密...

@FrankHB 好吧，现在关于 386 486 时代的记忆有两个版本。
一个版本告诉我说只要用户态锁定非 NMI 中断就行，OS 或各种调度不会动用 NMI 中断的，调用 NMI 中断的家伙不会碰你的上下文所以不用管......
另一个版本告诉我尽管当时 x86 的多任务就 win3.x 那一点，win95 刚出，用户态或者保护模式(dos 都有 app 用到)已经相当复杂了，屏蔽中断什么的早就不能用了.....

...那么该信哪个版本...

@yksoft1 修个 spectre 就砍了 8%左右性能，这大概是在对用户讲，处理器设计不那么严密是有可能得到 8%性能提升的...
至于当初 486DX 怎么设计的，有没有在安全性上放水，有没有过度追求严密使一些看起来应该很简单的操作实际 cost 极高，有没有因为 虽然不能在安全上过度严密或者放水 /又不能牺牲关键操作的 cost/结果相关的其他某些操作 cost 变高......
这些对于我这个不懂处理器的人...
.
.
.
好像都没有发言权.
期待关于进一步的解释啊......
比如就当时桌面普遍 1 核的情况下，C 语言 inline asm 括号那么粒度级别的锁定中断有没有致命 downside 非要加这么一条指令，对比普通 P1 添加了 mmx 指令集的代价估算当时 486 加了这条指令大概可能付出了多少代价，远小于 mmx，差不多 mmx 还是会远大于 mmx，这条指令有没有相较没设计这条指令的 386/286 系统 cpu 周边各种结构非大改不能容得下的破绽，而且（多谢 wiki 的提示)只解决单指令原子性粒度太小解决不了 ABA 会不会大大限制了该指令可能带来的性能提升导致得不偿失......
.
.
*而且当时的 win 系统和 dos 系统用了什么样的线程调度方式......是基于中断的还是.....而且当时还不像现在一天一个补丁，在保持和 386 兼容的情况下 OS 或 application 是不是真的有效利用了这个指令......
.
.
对于不懂处理器（如果新处理器不懂情有可原的话，特别强调老处理器也不懂）的我来说，满脑子都这些问题。。。

@yksoft1 N 年前曾经读到过关于所谓锁了中断不能切换进程自然就原子性了之类的，当时也差点信以为然，后来看看，一大堆寄存器标志位完全不懂，结果再碰到互相矛盾的相关的技术说明之类完全不知道信哪个了。很可能信错了多线程性能直接砍个 25%什么的.....

@yksoft1 "但也有传言这可能是一条伪指令，是为了掩盖当时代跨线程原子性的简单实现方式后来添加的......"
不过再也没有 486 系统来验证是不是真有这个指令了....
486 时代我记得还分 DX SX 性能不一样什么的还是我记错了...

CMPXCHG....
@yksoft1 google 直奔 mmx 去了，扑了个空，然后发现是 486....486....
CAS 为了最早的多线程下的单指令原子性....但愿没查错...

@mrchi python 小白想问下 async 和 await 这种写法（仅就 python 来说）是更偏向于 feature 还是更偏向于语法糖......
关心这个的原因是这两个关键字因为在 c#中用到过...用过的感觉是对于我这样新手即使会用了都不一定分得清是 feature 还是语法糖，不像某些特别明显的糖...