エミュレーション拡張であぶり出されるx86の絶妙なところ
情報が無い..!
"x86をエミュレーションするためだけに拡張されたCPUから、x86の特殊性を見てみる" 的なタッチの記事を考えていたんだけど、そもそも情報が無い。
ロシア製VLIWプロセッサ Elbrus はそもそも細かいところがNDA下らしい。コンパイラが専用で 以前挙げた EDG ベースだったり非常に興味深いんだけど。。
-
http://0x1.tv/Free_software_porting_on_the_Elbrus_architecture_(Андрей_Савченко,_LVEE-2019)
- FOSSの移植について説明したプレゼンと資料
メモリオーダ
C/C++11 mappings to processors でx86だけ異常にシンプルな表が示されているように、x86のメモリオーダリングは可能な限り 何となく動く ように作られている(TSO: Total Store Ordering)。
から、
-
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
- C/C++11 mappings to processors
-
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
- Doug Leaの The JSR-133 Cookbook for Compiler Writers
↑ のページからもリンクされている、x86の謎めいたメモリオーダリングルールの定式化としてx86-TSOがある:
- https://www.cl.cam.ac.uk/~pes20/weakmemory/index3.html
-
https://www.cl.cam.ac.uk/~pes20/weakmemory/index.html
- ↑ の親ページ
RISC信仰がどっかに消えたように、弱いメモリオーダ信仰もどっかに消えたのかもしれない。
フラグレジスタ
-
https://engine.scichina.com/publisher/scp/journal/SSI/45/4/10.1360/N112014-00300?slug=fulltext
- ↑ の記事のソースにあたる解説論文
MIPSプロセサの龍芯(Loongson)はCAMの追加などエミュレーションに必要なハードウェアに加えて、ターゲットISAのフラグを生成するためのロジックを持っていたとされる。龍芯はARM32もターゲットにしているため、条件moveのような処理も専用命令で対処している。
Crusoe/Efficeonは元のアーキテクチャがALU flagを持っていて、パイプラインにも1段割いている。
CM: コンプリーション(ALU Condition flag completion)
エミュレーションを行う上でフラグレジスタは毎回演算毎に更新する必要があり負荷が高い。このためターゲットアーキテクチャに合わせたフラグレジスタを備えてしまうのは有効に見える。
幸い(?)、ARM64はNegative Zero Carry oVerflow の4フラグはALU生成されるため通常のケースで追加の配慮は不要だが、RISC-Vなど専用の比較命令を要求するアーキテクチャも割と多い。
When it can be proved that the condition codes are not needed by the next instructions, no condition codes are computed at all.
そうでない場合は真面目な最適化が必要になる。例えば、qemuはフラグが消費されない場合はフラグ生成コードを実行しないようにして最適化している。
80bit 浮動小数点
x86のレガシなFPU(8087)は80bit表現を持っている。これはIEEE 754標準と微妙に異なるというか8087がIEEE 754標準を形作ったというか。。これはAMD64でも禁止されなかったため、依然サポートする必要はあるとみられる(本当?)。
Crusoeや龍芯は80bit浮動小数点演算ハードウェアを持っていた。
昔のPowerPC向けPCエミュレータ(SoftWindowsやRealPC)は、80bit浮動小数点を64bit浮動小数点でエミュレートしていたため、FPUを無効化する方法を提供していたり、Excelで値に再現性が無いことを注意喚起していた。