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

(c) 2025 Kouji Matsui chibiccを CILに移植した結果 (完全版) 2025.01.25 CENTER CLR
#9 MEETUP - KOUJI MATSUI

(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

(c) 2025 Kouji Matsui (c) 2025 Kouji Matsui Agenda chibiccとは
chibicc-cilとは移植の検討移植した結果ラスボス

(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 自体を含むいくつかの実際のプログラムをコンパイルできます。

(c) 2025 Kouji Matsui chibiccとは与えられた整数をコンパイルしてコマンドの戻り値（プロセス終了コード）として返す 42 chibicc gcc
(gas) tmp.s tmp ソースコード（整数）アセンブリコードコンパイル処理アセンブル処理実行コード

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

(c) 2025 Kouji Matsui chibiccとは x86_64アセンブラコードをベタに出力コマンドラインに指定されたた数値を埋め込む「指定された整数を
終了コードとして返す実行ファイルにコンパイルする」

(c) 2025 Kouji Matsui chibiccとはテストコードは単純なシェルスクリプト式を指定してchibiccを実行して出力を(gccを使って)アセンブルする “0”を入力して0に
“42”を入力して42になればOK 出来たバイナリを実行して結果を得る

(c) 2025 Kouji Matsui ネイティブコードとの連携がつらいよね。扱いやすいP/Invokeがあるけど… .NET Coreになって、Linuxや*BSDへの移植が進むにつれて、この部分が不満点として爆発してた (N=1)
.NETって

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

(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とは

(c) 2025 Kouji Matsui 移植の検討しかし、話はそう簡単ではありません。大きくは: ◦ chibiccはx86-64のコードを出力するので、これをCILを出力するようにコードジェネレータを変更する。 ◦
CILアセンブラが必要（ilasmが使える?） ◦ CILで書かれたCランタイムライブラリ（例えばprintf()の実装）が必要。

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

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

(c) 2025 Kouji Matsui 移植の検討 https://github.com/kekyo/chibicc-cil-toolchain chibiccの移植以外にもやるべきことは多い libc.a アセンブラ
リンカランタイムライブラリ chibicc本体

(c) 2025 Kouji Matsui 移植の検討 ◦ P/Invokeでネイティブライブラリをリンクできるようなナチュラルさを実現するには、リンカ側でコード生成能力とか多少必要になるかもしれない… ◦
本格的なCランタイムライブラリを用意したい。newlibとか。

chibicc-cil 移植の検討移植した結果ラスボス

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

(c) 2025 Kouji Matsui 移植した結果そして… chibicc: 305/316 chibicc-cil: 367
増えているのはCILへの対応分です。残り11コミット

(c) 2025 Kouji Matsui 移植した結果 CLIが想定するランタイム（CLR）は、「スタックマシン」と呼ばれる構造になっています。一時的な値は「評価スタック」に保存します（スタック操作に縛られます）。 (空) 10
10 20 30 スタックとしての操作のみ許される

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

(c) 2025 Kouji Matsui 移植した結果 ldc.i4 %d で評価スタックに数値をpushし、retする ilasm向けのCLIコードを出力
public static class Program public static int Main(string[] args) chibiccの最初のコミットの移植

(c) 2025 Kouji Matsui 移植した結果構造体のメンバーアクセスは、ポインター計算で処理する。 ◦ 元のchibicc (x86-64)は、当たり前ですが「型消去」を行います。つまり、コンパイル後のバイナリに型情報は含まれません。
◦ 従って、構造体のメンバーにアクセスするには、コンパイル時にオフセットを計算しておき、オフセットを信じてアクセスします。

(c) 2025 Kouji Matsui 移植した結果 ◦ この手法を大きく変えないようにするために、chibicc-cilでもメンバーアクセスはオフセット計算で行います。コンパイル時にオフセットを計算する
コードジェネレータの構造が、ポインタとオフセットアクセスに強く依存しているので、逸脱すると大幅に変更する必要がある

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

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

(c) 2025 Kouji Matsui 移植の過程 chibiccを.NETに移植する (56): Align struct members
◦ https://youtu.be/Yg5gF-I0khY?si=6Wvygz3orjrqhfQU

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

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

(c) 2025 Kouji Matsui 移植した結果関数ポインターを構造体のメタデータに出力すると、ランタイムの構造体サイズ計算で無視される ◦ 仕方がないので、”void*”と同じように扱うように修正 ◦
CoreCLRのバグっぽいが、Issueは見つからない（未発見？）放置しておくと問題が起きそうだから、そのうち修正されるかも。

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

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

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

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

(c) 2025 Kouji Matsui 移植した結果 chibiccを.NETに移植する (54): Add struct [2]
https://youtu.be/eAvlo8HaF_8?si=i8NGHZrwbpdCSMnE

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

(c) 2025 Kouji Matsui 移植した結果 Sbyte_len5 libc.a Sbyte_len5 Sbyte_len5 Sbyte_len5
大量に生成されてしまう値型配列

(c) 2025 Kouji Matsui 移植した結果 ◦ chibildが、同じ名称の型を集約して、単一の型を参照するようにアセンブリを出力する。 ◦ それでも、異なるアセンブリ間では差異が発生しうるが、実はランタイ
ムはこれを検出しない(CLR/CoreCLR/mono)ので、しれっと放置する。

(c) 2025 Kouji Matsui 移植した結果 ◦ 関数引数や戻り値の値渡しで構造体が渡される場合も、現状では問題が発生しないが、将来のランタイムでは問題が発生するかもしれない（パフォーマンスに影響がありそうなので、そういうチェックはやらないかもとは思う）。
ポインタではなく値渡しすると明確に Fooは異なるが…

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

(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)を使えばいい。

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

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

(c) 2025 Kouji Matsui 移植した結果移動するグローバル変数 ◦ 以下のコード、fooの保持位置がメモリ上で移動する (.NET Core以降)
◦ スタティック変数なので、GCHandle.Alloc()でpinする事も出来ない… ◦ &fooとかやられたらアウト。 ◦ .NETの世界に閉じていれば、気が付かないと思われる（Issueにもない）仮想メモリ空間内で移動する…

(c) 2025 Kouji Matsui 移植した結果 ◦ グローバル変数は常にポインタ型で保持して、chibiccがmalloc()して割り当てたメモリを指すようにし、アクセス時にdereferenceするようにした。 ◦ malloc()関数の中身は、Marshal.AllocCoTaskMem()なので移動しない。
ポインタ malloc() 初期化式

(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

(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を選択すべきだったかどうかはわかりません。

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

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

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

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

chibicc-cil 移植の検討移植した結果ラスボス

(c) 2025 Kouji Matsui ラスボスもし、「P/Invokeでネイティブライブラリを呼び出せるようにする。それもchibildで*.soライブラリ指定するだけで」が実現できれば、もういっそnewlibも捨ててlibc.soを直接呼び出した方が少しはマシかも？
memcpy()とかstrlen()とか、絶対にネイティブコードの方が速い。

(c) 2025 Kouji Matsui ラスボス関数の可変引数への対応 (vararg) ◦ vararg命令を使わず独自の実装で回避。これは動作した。 ◦
しかし、P/Invokeで可変引数関数を呼び出したりコールバックで呼び出し可能にするには、.NETランタイムがvarargを処理できる必要がある…

(c) 2025 Kouji Matsui ラスボス “Initial thoughts on Native Vararg
support on Unix platforms for RyuJit” https://github.com/dotnet/runtime/issues/10478 意訳: 「varargはWindowsにしか対応してないよーん」うそだ！うそだと言ってくれ…！！！

(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

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

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

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

Video

More Decks by Kouji Matsui

Featured

Transcript