Мир сегодня с "Юрий Подоляка"
Мир сегодня с "Юрий Подоляка"
Труха⚡️Україна
Труха⚡️Україна
Николаевский Ванёк
Николаевский Ванёк
Мир сегодня с "Юрий Подоляка"
Мир сегодня с "Юрий Подоляка"
Труха⚡️Україна
Труха⚡️Україна
Николаевский Ванёк
Николаевский Ванёк
ksco 的工作日志 avatar
ksco 的工作日志
ksco 的工作日志 avatar
ksco 的工作日志
08.05.202515:18
书接上回,给 Box64 加了个迷你 PE parser 来解析并用上了 volatileMetadata,可惜好像没啥游戏有这个元数据(M$ 的号召力太差了
07.05.202506:55
2019 年微软在编译器层面针对 Prism TSO 模拟性能引入了一项优化 volatileMetadata ,我觉得非常有创造性:https://learn.microsoft.com/en-us/cpp/build/reference/volatile?view=msvc-170

简单说就是,编译器在编译时,是清楚程序中哪些部分需要 TSO 保证的,开启 /volatileMetadata 选项后,这些需要保证 TSO 语义的地址段会被记录到 PE 文件中,然后 Prism 就可以读取这个信息,针对性的做 TSO 模拟,从而避免不必要的性能损耗。
26.03.202506:44
04.05.202505:29
May the 4th be with you.
今天给 box64 RISC-V 后端增加了 eflags 指令融合的优化,填补了 eflags 模拟的最后一片空白。在 4 个线程的 p7zip benchmark 中,执行效率达到了原生的 70%!

举例来说,对于如下的指令序列:


// set SF/OF/ZF
cmp rax, rbx
// use SF/OF/ZF
jle .label
// flush cmp, set ...
test rcx, rcx
...
.label:


注释中是 box64 的 eflags 依赖计算根据当前指令序列推断出来的信息,即 jle 需要 SF/OF/ZF 来完成 less than or equal 的计算,同时 test 会刷新所有的 flags,所以 cmp 只需要对 jle 负责,完成以上三个 flags 的计算即可。

但这真的足够好吗?只计算 SF/OF/ZF 也非常昂贵,RISC-V 没有龙架构 LBT 这样的专用硬件,这些 flags 的计算全靠手动写汇编来模拟,保守估计也要十几条指令来完成。

但如果从语义的角度出发, cmp+jle 其实就是在做 jump if rax<=rbx 。所以我们要做的其实就是把这两条指令当成一条指令来看待,直接翻译成一条 BGE rbx, rax

具体到实现中,虽然涉及到很多实现细节,但其实就是检测连续的两条指令是否符合这个模式,然后将符合的替换为原生的 RISC-V 指令即可,有了已有的依赖计算的帮助,检测工作实际上非常容易。

图中第一个是带有指令融合的跑分,第二个是原生的跑分,第三个是不带指令融合的跑分。
15.04.202512:14
炒点冷饭

Mesa 的 x86 libd3dadapter9.so 遵从的是 Windows calling convention,这很合理,因为这个库能且仅能被 wine 调用,直接用 Windows CC 可以省很多事。

但抽象的是这个库也有 RISCs build,而这些架构下并不存在 Windows CC,所以遵从的其实是 SysV CC。初看觉得毫无意义,但 Mesa 的一位开发者给 Box86/Box64 提交了这个库的 wrapping 代码,在这一层把 x86 Windows CC 调用转换成 RISCs SysV CC 调用,因此 Box64 可以正常使用该库。
Көрсетілген 1 - 7 арасынан 7
Көбірек мүмкіндіктерді ашу үшін кіріңіз.