在龙芯群看到说小米 14 上装了一个名为 Tango[1] 的二进制翻译器，可以把 AArch32 的代码翻译成 AArch64，用来跑 32 位的程序。
于是好奇就去看了看 Tango 前身的论文[2]，发现在同时支持 AArch32 和 AArch64 的机器上使用 Tango vs. native 做 benchmark，测得的性能损失很小（~7.5%），某些 OoO CPU 上甚至有一定的性能提升。
他们的设计和 DynamoRIO 有很多相似之处：
1. 基于 basic block 和 linked fragment 的 thread-shared code cache；
2. indirect branch linking 用的是一个段内的开放寻址哈希表做映射；
3. 用了 NET 算法做 trace building；
4. 精确的 signal handling。
也有一些和 DynamoRIO 不同的地方：
> 不同之处主要来自于 DynamoRIO 是同架构模拟，Tango 则是异架构模拟。
1. 地址空间映射，直接把 AArch32 的程序映射到低 4G 的区间，host 跑在高位区间；
2. 需要做 Linux syscall 的转译，因为 32 位的 syscall 和 64 位并不相同；但是据说 AArch64 内核中有一个兼容层，所以这个东西是内核帮忙做的；
3. 因为是同架构模拟，DynamoRIO 只需要转译少数指令即可，大部分指令都是原样放到 code cache；但 Tango 是异架构模拟，需要做二进制翻译；
4. 因为 AArch32 只有 16 个 GPR，所以 GPR 可以直接做一一映射，且还剩下一堆 scratch 寄存器可以用，这方面比 DynamoRIO 更简单；但是 AArch32 最多可以有 48 个浮点寄存器，AArch64 只有 32 个，所以需要做寄存器分配来减少 spill 的次数提高性能。
[1] https://www.amanieusystems.com/technology
[2] https://pure.manchester.ac.uk/ws/portalfiles/portal/56078084/pldi_16.pdf
于是好奇就去看了看 Tango 前身的论文[2]，发现在同时支持 AArch32 和 AArch64 的机器上使用 Tango vs. native 做 benchmark，测得的性能损失很小（~7.5%），某些 OoO CPU 上甚至有一定的性能提升。
他们的设计和 DynamoRIO 有很多相似之处：
1. 基于 basic block 和 linked fragment 的 thread-shared code cache；
2. indirect branch linking 用的是一个段内的开放寻址哈希表做映射；
3. 用了 NET 算法做 trace building；
4. 精确的 signal handling。
也有一些和 DynamoRIO 不同的地方：
> 不同之处主要来自于 DynamoRIO 是同架构模拟，Tango 则是异架构模拟。
1. 地址空间映射，直接把 AArch32 的程序映射到低 4G 的区间，host 跑在高位区间；
2. 需要做 Linux syscall 的转译，因为 32 位的 syscall 和 64 位并不相同；但是据说 AArch64 内核中有一个兼容层，所以这个东西是内核帮忙做的；
3. 因为是同架构模拟，DynamoRIO 只需要转译少数指令即可，大部分指令都是原样放到 code cache；但 Tango 是异架构模拟，需要做二进制翻译；
4. 因为 AArch32 只有 16 个 GPR，所以 GPR 可以直接做一一映射，且还剩下一堆 scratch 寄存器可以用，这方面比 DynamoRIO 更简单；但是 AArch32 最多可以有 48 个浮点寄存器，AArch64 只有 32 个，所以需要做寄存器分配来减少 spill 的次数提高性能。
[1] https://www.amanieusystems.com/technology
[2] https://pure.manchester.ac.uk/ws/portalfiles/portal/56078084/pldi_16.pdf
https://sourceware.org/pipermail/binutils/2023-October/130237.html
第一次给 binutils-gdb 交 patch，也不知道能不能合。🙏
第一次给 binutils-gdb 交 patch，也不知道能不能合。🙏
ksco 的工作日志
突然发现 Codemasters 出新作了，WRC licensed、虚幻引擎，只要 200 块！
玩了两个小时，这游戏优化好差，6600XT 只能开中画质。但好在手感是无可挑剔的，算是尘埃拉力赛 2.0 的精神续作。游戏性上也有了长足的进步，终于像个游戏而不是模拟器了。
今天学习了一下 rseq（restartable sequence），想到这个东西在 gdb 中的实现应该和 ll/sc 很像。但搜了一下 gdb 源码，各大架构好像都没有实现？大家对这个东西完全没有调试需求吗？
DR 等 DBT 对信号的处理都相当复杂，其本质原因是 Linux 的信号可以在任意时刻发生，而 DBT 不得不注册一个全局的 signal handler 对所有的信号统一处理再分发来模拟内核行为。
这就要求：
1. DBT 要么时刻保持精确的 guest 状态（和性能不可兼得），要么可以在任意时刻恢复出精确的 guest 状态；
2. trace building、basic block linking 等让执行流尽可能保留在 code cache 的优化手段进一步增加了复杂性 -- 异步信号 interruption point 所在的 basic block 必须 unlink 来保证可控的执行时间；
3. syscall 可能会等待一个信号，所以所有的 pending 信号必须在 syscall 之前被处理；
4. rseq 如果被信号打断，则需要重启；
5. ......
这就要求：
1. DBT 要么时刻保持精确的 guest 状态（和性能不可兼得），要么可以在任意时刻恢复出精确的 guest 状态；
2. trace building、basic block linking 等让执行流尽可能保留在 code cache 的优化手段进一步增加了复杂性 -- 异步信号 interruption point 所在的 basic block 必须 unlink 来保证可控的执行时间；
3. syscall 可能会等待一个信号，所以所有的 pending 信号必须在 syscall 之前被处理；
4. rseq 如果被信号打断，则需要重启；
5. ......
ksco 的工作日志
https://sourceware.org/pipermail/binutils/2023-October/130237.html 第一次给 binutils-gdb 交 patch，也不知道能不能合。🙏
Approved-By: Andrew Burgess
🥰3