从 Revy 那里用将近半价的价格收了一台 Matebook E Go (Windows on ARM)，用了四天了，这设备真的是一堆破问题。
本身就不太喜欢 Windows，再加上 ARM 原生的应用不多（尤其是华为自带的软件竟然全都是 x86_64 的，简直不可原谅），Windows x86 Emulation 转译的效率又极其低下，体验真是一言难尽（微软你看看隔壁罗塞塔 2！）。
所以我把能卸载 x86 的应用全都卸载了，好在我日常用的软件都是有 ARM 原生的，最可惜的就是失去了华为生态的所有功能（比如笔和键盘的电量显示）。
但我还是很喜欢这个设备，硬件素质很好，生产力/娱乐性都可以吊打 iPad，还有 WSL/WSA，多核性能直逼 M1 的 80%，只要 3000 块，还要什么自行车。
本身就不太喜欢 Windows，再加上 ARM 原生的应用不多（尤其是华为自带的软件竟然全都是 x86_64 的，简直不可原谅），Windows x86 Emulation 转译的效率又极其低下，体验真是一言难尽（微软你看看隔壁罗塞塔 2！）。
所以我把能卸载 x86 的应用全都卸载了，好在我日常用的软件都是有 ARM 原生的，最可惜的就是失去了华为生态的所有功能（比如笔和键盘的电量显示）。
但我还是很喜欢这个设备，硬件素质很好，生产力/娱乐性都可以吊打 iPad，还有 WSL/WSA，多核性能直逼 M1 的 80%，只要 3000 块，还要什么自行车。
#DynamoRIO
emit fragment 分为两个阶段：1）求大小；2）emit 代码
fragment prefix 大小固定为 8，两个阶段一致；exit stub size 固定为 64，两个阶段一致；所以问题应该出在 bb 本身的代码上。
大小差了 2，猜测大概率是 compressed 指令导致的？
emit fragment 分为两个阶段：1）求大小；2）emit 代码
fragment prefix 大小固定为 8，两个阶段一致；exit stub size 固定为 64，两个阶段一致；所以问题应该出在 bb 本身的代码上。
大小差了 2，猜测大概率是 compressed 指令导致的？
第一阶段算出来的 offset 是 122，检查过了，这个数字是对的，所以问题应该出在第二阶段的
set_linkstub_fields 函数里，step 进去看一下。我怎么会在 encode 里面写死 pc + 4 啊，头疼。因为 bb 里的正常指令都有 raw bits，所以走的 fast pass，只有最后面的一条 cti 因为被 mangle 过了 rawbits 被取消了，才走到 pc + 4。
今天家里的橘猫突然莫名打嗝，干呕。晚上复盘的时候才发现因为今天我们起床时间差距较大，导致上午她喂完之后我又喂了一顿。橘爷爷又是给多少吃多少的主儿，所以吃撑了。
https://github.com/nakst/gf/pull/101/commits/007c08fede8c79f778a07c7b71f035a5c1b14456
发现一个很好玩的 commit，你们 C++ 真是太 fancy 了
发现一个很好玩的 commit，你们 C++ 真是太 fancy 了