chibiccを CILに移植した結果 (完全版)

Slide 1

Slide 1 text

Slide 2

Slide 2 text

(c) 2025 Kouji Matsui Kouji Matsui – kozy, kekyo NAGOYA city, AICHI pref., JP https://github.com/kekyo https://mi.kekyo.net/@kekyo Self employed Center CLR organizer. .NET OSS: IL2C RelaxVersioner Epoxy GitReader FlashCap etc… Bicycle rider

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

(c) 2025 Kouji Matsui chibiccとは Rui Ueyama氏のプロジェクト “A small C compiler” https://github.com/rui314/chibicc chibicc は、C11 のほとんどの機能を実装した、もう 1 つの小さな C コンパイラです。他の小さなコンパイラと同様に、おそらく「おもちゃのコンパイラ」のカテゴリに分類されるかもしれませんが、chibicc は、コンパイルされたプログラムに変更を加えることなく、Git、 SQLite、 libpng、chibicc 自体を含むいくつかの実際のプログラムをコンパイルできます。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

(c) 2025 Kouji Matsui chibiccとは与えられた整数をコンパイルしてコマンドの戻り値（プロセス終了コード）として返す $ chibicc 42 $ ./tmp $ echo $? 42 引数に与えた整数（ソースコード）を戻り値として返す実行ファイルを生成する chibiccが `tmp` 実行ファイルを生成する「ソースコード」は整数限定です。こんなのC言語とは呼べませんが、それは第一歩だからです

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

(c) 2025 Kouji Matsui 有用なOSSライブラリがネイティブコードだと、実行環境に合わせてバイナリを全部パッケージに含めなければならない (x86, x86-64, armel, aarch64, …) これを避けるために、ライブラリを.NETに移植しようとすると、 C言語で書かれたコードをC#に移植する必要がありますが、これが出来る技術者はそうそう居ないので… ◦ FlashCapで非常に苦労しましたもうやりたくないです .NETって

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

(c) 2025 Kouji Matsui .NET/.NET Core/.NET Frameworkで使われる、CIL (Common Intemediate Language)の事です。 CILは.NETにおけるJava Bytecodeのような中間言語仕様で、 ECMA-335で定義されています。 https://ecma-international.org/publications-and- standards/standards/ecma-335/ CILとは

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

(c) 2025 Kouji Matsui 移植の検討 C言語関数との整合性を持たせることを考える必要がある: ◦ ポインタの扱いはCILにポインタ型があるので、1:1で対応できる。 ◦ CILには構造体(ValueType)が存在するので、C言語構造体はだいたい 1:1に対応出来る。共用体に対応するものは無いので、ValueTypeで代用する。 ◦ CILにはP/Invokeという、ネイティブライブラリ(*.so)を呼び出せる機能があるので、これを使えばシームレスにネイティブライブラリと結合できるかも？ (少なくともC#よりは簡単に)

Slide 24

Slide 24 text

(c) 2025 Kouji Matsui 移植の検討 ◦ CILアセンブラは.NET標準のilasmがあるけど、これが色々扱いにくい。 CILアセンブラ作るのはそれほど難易度が高いわけではないので、 chibiccのバックエンドとして扱いやすいchibiasを作るか… ◦ POSIX環境処理系として違和感を与えたくないので、普通に想定される chibildやchibiarも必要だよね。これらがないと、そもそもOSSのコードとかビルドできそうにない（Cの世界において、MSBuild周りのツールチェインは全く必要とされない）。

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

(c) 2025 Kouji Matsui 移植した結果最初の山場（セルフホスト試行・総コミット316個の約半分ぐらい） Stage1(gccでビルドしたchibicc-cil) Stage2(Stage1 chibicc-cilを使ってビルドしたchibicc-cil) Stage3(Stage2 chibicc-cilを使ってビルドしたchibicc-cil) でテスト結果が一致する事を確認！！

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

(c) 2025 Kouji Matsui 移植した結果 CLRにはポインタ型があり、これは仮想メモリ空間のアドレスを指し示すことが出来る。マジックではない。なので、ガベージコレクタが対象を移動するような状況では使えない（C#で言う所のunsafeと同じ）。 chibicc-cilでは、最近はやりの「ref」ではなく、全面的にポインタ型を使う。理由はポインタ型の透明性（裏でCLRが勝手に何かする事がない）と、C言語セマンティクスとの一致。

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

(c) 2025 Kouji Matsui 移植した結果構造体のメンバーアクセスは（特にポインター型を含む場合）、コンパイル時ではなく実行時に解決する必要がある。 ◦ “void*”や”intptr_t”は、普通のC言語処理系では「コンパイル時にターゲット環境に合わせて32/64bit(4/8バイト)」と仮定出来るが、.NETの場合は実行時までわからない。 ◦ オフセット計算をコンパイラ内部で行うのではなく、オフセット計算式をコードとして出力し、実行時にこのコードを計算することによってオフセットを確定させる。

Slide 43

Slide 43 text

Slide 44

Slide 44 text

(c) 2025 Kouji Matsui 移植した結果関連する問題として、アライメントの指定と計算: ◦ CLRがどのようにメンバーをメモリ上に配置するのかは不透明なので、必ずchibiccが出力するオフセット計算と一致するようにしなければならない。 ◦ 構造体メンバーのオフセット計算は行う。グローバル変数とかのアライメント計算は無視する（常にオフセット0から始まると仮定する）。 ◦ 多分、SSEやAVX intrinsicで、グローバル変数__int128を128バイト境界に配置したいというような要求。.NETでintrinsicを想定するのは意味不明だと思うので、出来なくても問題なさそう。

Slide 45

Slide 45 text

Slide 46

Slide 46 text

(c) 2025 Kouji Matsui 移植した結果パフォーマンスが悪すぎる: ◦ オフセット計算式をそのまま出力しても動作するが、非常にパフォーマンスが悪い。 ◦ タイプイニシャライザで一度だけ計算して、結果をスタティックフィールドに保持するようなコードを出力することでキャッシュし、構造体メンバーにアクセスするときはその値を使用するようなコードを出力する。後続フィールドの計算は式が増えていくのでコストが高い

Slide 47

Slide 47 text

(c) 2025 Kouji Matsui 移植した結果 ◦ オフセット計算式自体も、コンパイラ内部で計算可能な部分は計算しておく。このために簡約器（一種のインタプリタ）を実装した。 ◦ 直値の検出と、直値同士の計算をコンパイラ内で行う。 ◦ 直値が条件となる分岐式（例えば “1 != 0 ? o1 : o2”）は、判定もコンパイラ内で行う。 ◦ おそらくこれを発展させれば、オプティマイザ機能に昇華出来ると思われる（未実施）。 ◦ これでかなりパフォーマンスが向上した（恐らく5倍から20倍程度）。但し、現在の実装はそこまで万能でもない…

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

(c) 2025 Kouji Matsui 移植した結果 CLRはスタックマシンなので、関数の戻り値を捨てる場合にこれを考慮に入れる必要があるが、元のchibiccはそうではない。 ◦ chibiccは、戻り値が常にレジスタraxに入っていると仮定していて、戻り値が不要な場合はraxの値を無視しているだけ。 ◦ スタックマシンではそうはいかない。戻り値が不要な場合は、スタックから値を削除する必要があり、誤っているとクラッシュする。

Slide 51

Slide 51 text

Slide 52

Slide 52 text

(c) 2025 Kouji Matsui 移植した結果 ◦ コードジェネレータの基本構造に手を入れて、関数の戻り値が存在するかどうかを追跡するように変更。 ◦ 関数のシグネチャを無理やり偽ると、x86-64と同様に未定義動作: ◦ x86-64: voidを返す関数でintを返すように偽ると、でたらめな値が返される（raxの偶然の値が読める）。 ◦ CLI: voidを返す関数でintを返すように偽ると、クラッシュする。無理やりキャストして呼び出す

Slide 53

Slide 53 text

(c) 2025 Kouji Matsui 移植した結果 C言語の配列は、値型配列に相当するが、対応するCILの型が無い。 ◦ .NETで配列と言えば、System.Array型の「参照型 (ObjRef)」であり、値型(ValueType)ではない。 ◦ C言語の配列は、.NETにおける値型と同じ。配列を指すポインターを計算することで、初めて参照型と同じような立ち位置になる（C言語のキモい構文規則のためにわかりにくい）。 ◦ .NETのSystem.Arrayをそのまま利用させると、ポインター計算との整合性を取ることが困難。やはり値型として振る舞う必要がある。

Slide 54

Slide 54 text

Slide 55

Slide 55 text

(c) 2025 Kouji Matsui 移植した結果 ◦ 同じような構造体型が多数生成されてしまうので、型名に規則性を持たせて、同じ型名なら再利用可能にする（後述）。 ◦ メンバーアクセス時は「オフセット計算式の出力をコンパイラが行う」ので、メンバーがprivateでも問題ない。ストレージスペースだけ担保できれば良い。注意: メタデータ上のメンバーレイアウトが、オフセット計算式と厳密に一致する必要がある

Slide 56

Slide 56 text

Slide 57

Slide 57 text

(c) 2025 Kouji Matsui 移植した結果異なる生成イメージ内の全く同じ名称の型が、CILメタデータ上では区別されてしまう。 ◦ 前述の値型配列でも（特に大量に）発生。 ◦ .NETでは、異なるアセンブリに定義された同じ名称の型が区別される。 ◦ C言語では、処理系が出力したタイミングが異なるだけで、同じヘッダファイルを使用していれば、定義された型が同じと見なす必要がある（わざと定義を変えない限り）。

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

(c) 2025 Kouji Matsui 移植した結果 ◦ 万が一問題が起きる場合は… 構造体をポインター渡しに変更して、受信側で内容を（サイズ基準で）コピーするとかですかね… ◦ NOTE: chibicc-cilは全てがプリミティブ型か値型であり、参照型 (ObjRef)を扱わないので、値渡しの型が違っていても問題ないと推測（ObjRefの物理レイアウトはCLRの仕様から見て不透明で、値型のコピーよりも何か問題が起きそうではある）。

Slide 63

Slide 63 text

(c) 2025 Kouji Matsui 移植した結果 VLA (可変長配列・Variable length array)への対応。 ◦ alloca()に相当。実行時にサイズを決定できて、ストレージはスタックに配置される。 ◦ C#で言う所のstack_alloc。なので、alloca()の単純なマッピングは実現可能。CILのlocalloc命令 (https://learn.microsoft.com/en- us/dotnet/api/system.reflection.emit.opcodes.localloc)を使えばいい。

Slide 64

Slide 64 text

(c) 2025 Kouji Matsui 移植した結果 ◦ CLRはスタックマシンであるため、locallocで確保される領域も評価スタックに積むことになり、評価スタックをスクラッチバッファとして使うchibiccは、スタックバランスが崩れてクラッシュしやすい（なので、 alloca()使用時もスタックが底にある事をチェックしている）。 ◦ 問題となる条件はalloca()と同じだが、VLAだと言語構文なので、どこにでも書けるように感じるため、この問題に気が付きにくいと感じた…

Slide 65

Slide 65 text

(c) 2025 Kouji Matsui 移植した結果 ◦ スクラッチバッファとして使う箇所を全部テンポラリローカル変数に格納するようにすれば対応は可能だが... ◦ C#はそうしていた。OpCodeだけ見ると、スクラッチバッファをわざわざローカル変数として割り当てていて無駄なコードだなとは思っていたけど、どうやらこれが背景にありそう。 ◦ そういうわけで諦めた。多分VLA使う人いない… ローカル変数に保存(stloc)して直ぐにまたローカル変数から値を取り出す(ldloc)操作は、一見無意味のように思える

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

(c) 2025 Kouji Matsui 移植した結果 MMX, SSE, AVXなどのintrinsic ◦ .NET環境でこれに対応させる意味が良く分からん感あるのでスルーまともなデバッグ情報を出したい ◦ ilasmを使っている限り、その制約で無理ゲーなので、chibiasを作ることに。 ◦ 流れでchibiarも作ることになり、結局chibicc-cil-toolchainとした。 ◦ emitされるコードは、Mono.Cecil (https://github.com/jbevain/cecil) を使用しています。 ◦ ドキュメントはかなり書いたので、これらの使い方はリポジトリを参照してください。 https://github.com/kekyo/chibicc-cil-toolchain

Slide 69

Slide 69 text

(c) 2025 Kouji Matsui 移植した結果ランタイムライブラリの用意 ◦ chibicc自身のビルドは、chibicc内で使用している標準関数や定義だけが用意出来れば良いので、「libc-bootstrap.dll」としてC#で実装。 ◦ これにより、Stage1, 2, 3コンパイル（つまりセルフビルド）を実現。 ◦ Stage4（完全なCランタイムライブラリを使用するchibiccのビルド）を実現するために、newlibを移植する。 ◦ newlib (https://sourceware.org/newlib/) は、主に組み込み環境向けのlibc互換実装。しんどかった… 結局完成してません。一応ビルドには成功し、libc.aとlibc.mは生成できました。 ◦ 他にもuclibcやmuslといった選択肢があります。newlibを選択すべきだったかどうかはわかりません。

Slide 70

Slide 70 text

(c) 2025 Kouji Matsui 移植した結果 ◦ newlibは内部で「複素数型 _Complex の計算関数」も公開していて、これを実現するためにはコンパイラが複素数型を扱える必要があります。 ◦ しかし、chibiccは複素数型を実装しておらず… ◦ つまり、一から複素数型をサポートするコードを実装しました（” .NET related: Added complex type basis.”）。 ◦ といっても、複素数型に対する実数と虚数パートそれぞれへのアクセスと、四則演算に対応する関数が呼び出せるようにするだけなので、chibiccをここまで移植していれば誰でも実装できるはずです。その他の複素数計算はnewlibに任せる…

Slide 71

Slide 71 text

(c) 2025 Kouji Matsui 移植した結果 ◦ 子プロセス起動のハンドリング ◦ fork(), exec()が無いので、posix_spawn()を実装してお茶を濁した。 ◦ 標準入出力ハンドルをマルチプラットフォーム安全に転送出来ないので、イベントハンドラでデータをバイパスするワーカースレッドが必要だった。あまり効率が良くないと思う。 ◦ POSIXシグナル・スレッドの扱い ◦ pthreadの移植をがんばる(一部のみ実装)。内部はもちろん.NETのSystem.Threadingを使う。 ◦ POSIXシグナルは目下の所無視…

Slide 72

Slide 72 text

(c) 2025 Kouji Matsui 移植した結果関数の可変引数への対応(vararg) ◦ C#の可変引数（param array）とは違います。相互運用機能。 ◦ CILのvarargメタデータ・arglist命令・System.ArgIteratorを使う varargメタデータ arglist ArgIterator 一対一に対応していてネイティブコード連携のために存在する事がうかがえる

Slide 73

Slide 73 text

(c) 2025 Kouji Matsui 移植した結果 ◦ CILのvarargメタデータを使うようにする。これの生成はchibildで行う必要がある。 ◦ 最初、varargを使うもうまく動かない事があった。これはnetstandard TFMでのみ発生し、.NETランタイムのissueにも上がっていない問題で、どうしようもないことから、CIL vararg関連の機能を使わず独自の実装で回避。 ◦ 独自実装なので、chibiccの世界では問題なく動作する。しかし、ネイティブコードとの連携は出来ない。

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

(c) 2025 Kouji Matsui クロージングもしかしたら、将来ランタイムでvararg対応されるかもしれません。しかし、その頃には色々忘れてしまって、もう続けられなさそうです… JVMでもがんばれば出来そうですが、多分sun.misc.Unsafeが〇されてしまったので、難しいと思います… と思ってたら、jdk.unsupportedに移動されたとの事なので、ワンチャンあるかも知れません（私はJava詳しくないのでJVM側のアドバイスは出来ないと思います。 CILでどうやったのかについては質問どうぞ） Unsafeクラス：どんなスピードでも危険: https://blogs.oracle.com/otnjp/post/the-unsafe-class- unsafe-at-any-speed-ja

Slide 82

Slide 82 text

(c) 2025 Kouji Matsui 質疑応答成果物を公開します: ◦ chibicc-cil-build: https://github.com/kekyo/chibicc-cil-build この登壇のために最後の整理を行いましたが、基本的にもう触る事もないので、PRの対応とか期待しないでください… 類似プロジェクト: Cesium(ForNeVerさん/JBの中の人) 同じ問題がIssueで上がっています（もちろん未解決） https://github.com/ForNeVeR/Cesium

Slide 83

Slide 83 text