{"id":18009937,"url":"https://github.com/kekyo/chibicc-cil-toolchain","last_synced_at":"2026-02-20T22:03:25.250Z","repository":{"id":65427135,"uuid":"586109155","full_name":"kekyo/chibicc-cil-toolchain","owner":"kekyo","description":"The specialized backend toolchain for chibicc-cil","archived":false,"fork":false,"pushed_at":"2025-01-06T13:34:56.000Z","size":4657,"stargazers_count":7,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-12-21T16:54:23.828Z","etag":null,"topics":["chibicc","chibicc-cil","cil","dotnet","ilasm"],"latest_commit_sha":null,"homepage":"https://github.com/kekyo/chibicc-cil-build","language":"C#","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kekyo.png","metadata":{"files":{"readme":"README.ja.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-01-07T01:08:00.000Z","updated_at":"2025-01-06T13:35:00.000Z","dependencies_parsed_at":"2024-01-20T09:22:12.861Z","dependency_job_id":"b173b2d4-7614-4366-9df0-8122d244c2ca","html_url":"https://github.com/kekyo/chibicc-cil-toolchain","commit_stats":{"total_commits":131,"total_committers":1,"mean_commits":131.0,"dds":0.0,"last_synced_commit":"7b72ffc7b03ed801b19ec89c07f8f88678741cf4"},"previous_names":["kekyo/chibicc-cil-toolchain","kekyo/chibias-cil"],"tags_count":56,"template":false,"template_full_name":null,"purl":"pkg:github/kekyo/chibicc-cil-toolchain","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kekyo%2Fchibicc-cil-toolchain","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kekyo%2Fchibicc-cil-toolchain/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kekyo%2Fchibicc-cil-toolchain/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kekyo%2Fchibicc-cil-toolchain/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kekyo","download_url":"https://codeload.github.com/kekyo/chibicc-cil-toolchain/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kekyo%2Fchibicc-cil-toolchain/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29666462,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-20T19:49:36.704Z","status":"ssl_error","status_checked_at":"2026-02-20T19:44:05.372Z","response_time":59,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["chibicc","chibicc-cil","cil","dotnet","ilasm"],"created_at":"2024-10-30T02:11:35.908Z","updated_at":"2026-02-20T22:03:25.231Z","avatar_url":"https://github.com/kekyo.png","language":"C#","funding_links":[],"categories":[],"sub_categories":[],"readme":"# The specialized backend toolchain for chibicc-cil\n\n[![Project Status: WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public.](https://www.repostatus.org/badges/latest/wip.svg)](https://www.repostatus.org/#wip)\n\n## NuGet\n\n### .NET CLI interface\n\n| Package     | NuGet                                                                                                                            |\n|:------------|:---------------------------------------------------------------------------------------------------------------------------------|\n| chibiar-cli | [![NuGet chibiar-cli](https://img.shields.io/nuget/v/chibiar-cli.svg?style=flat)](https://www.nuget.org/packages/chibiar-cli)    |\n| chibias-cli | [![NuGet chibias-cli](https://img.shields.io/nuget/v/chibias-cli.svg?style=flat)](https://www.nuget.org/packages/chibias-cli)    |\n| chibild-cli | [![NuGet chibild-cli](https://img.shields.io/nuget/v/chibild-cli.svg?style=flat)](https://www.nuget.org/packages/chibild-cli)    |\n\n### Core libraries\n\n| Package                  | NuGet                                                                                                                            |\n|:-------------------------|:---------------------------------------------------------------------------------------------------------------------------------|\n| chibiar.core             | [![NuGet chibiar.core](https://img.shields.io/nuget/v/chibiar.core.svg?style=flat)](https://www.nuget.org/packages/chibiar.core) |\n| chibias.core             | [![NuGet chibias.core](https://img.shields.io/nuget/v/chibias.core.svg?style=flat)](https://www.nuget.org/packages/chibias.core) |\n| chibild.core             | [![NuGet chibild.core](https://img.shields.io/nuget/v/chibild.core.svg?style=flat)](https://www.nuget.org/packages/chibild.core) |\n| chibicc.toolchain.common | [![NuGet chibicc.toolchain.common](https://img.shields.io/nuget/v/chibicc.toolchain.common.svg?style=flat)](https://www.nuget.org/packages/chibicc.toolchain.common) |\n\n[English language is here](https://github.com/kekyo/chibicc-cil-toolchain)\n\n## これは何?\n\n初めての方は [meta-build script repository](https://github.com/kekyo/chibicc-cil-build) も参照してください。\n\nchibicc-toolchainは、.NET CIL/CLR 上に [chibicc](https://github.com/rui314/chibicc) を移植するためのバックエンドとなる、CIL/MSILアセンブラ・リンカなどのツールチェインです。\nこのツールチェインで使用するCILアセンブラは、簡素な構文規則でCILアセンブリ言語を記述可能で、アセンブルを行い、.NETアセンブリファイルを出力することが出来ます。\n以下はコード例です:\n\n```\n.function public void() main\n    ldstr \"Hello world\"\n    call void(string) System.Console.WriteLine\n    ret\n```\n\nこのツールチェインは、表面的には単なるCILアセンブラのバリエーションの一つとみなすことが出来ますが、\n.NET標準のILAsmがCILアセンブラとして網羅的かつプリミティブなツールチェインである一方で、\nchibicc-toolchainはC言語との相互運用性を向上させるための、いくつかの重要なフィーチャーを盛り込んでいる点が異なります。\n\nまだ作業中ですが、[YouTube](https://bit.ly/3XbqPSQ) にて、Gitコミット毎に移植する解説シリーズを放送しています。\n\n[chibicc-cil](https://github.com/kekyo/chibicc-cil) は、ある程度移植が進んだ段階で公開する予定です。しばらくお待ちください。\n\n----\n\n## chibildの全体像\n\nchibicc-toolchainは、以下のツールチェインプログラムで構成されています:\n\n* chibias: CILアセンブラ\n* chibild: CILオブジェクトリンカ\n* chibiar: CILオブジェクトアーカイバ\n\n![chibicc-toolchain overview](Images/toolchain.png)\n\nchibiasは、CILソースコード群('*.s')をほぼそのままオブジェクトファイル('*.o')として出力し、\nCILソースコードの実質的なアセンブル処理は、chibildが行います。\n\n* chibiasは、パーサーによる構文チェックを行いますが、シンボルの妥当性など細かい検査を行いません。\n* chibiasが出力するオブジェクトファイルは、実際には入力となるCILソースファイルをgzipで圧縮しただけです。\n  このことは、実際にオブジェクトファイルを `gzip -d` することで確かめることができます。\n\nこのような、chibias, chibild, chibiarの奇妙な挙動は実装の制約によるものですが、\nツールチェイン使用者にとって見れば、POSIXで想定されるas,ld,arなどのツールチェインと対比させて使用方法を理解できるという強みがあります。\n\n以降の説明では、CILアセンブリソースコードをchibildで直接使用して解説します。\n\n### CILアセンブル処理\n\nchibildは、複数のCILオブジェクトファイル（またはCILソースファイル）を入力として、アセンブルを行い、\n結果を.NETアセンブリとして出力します。\nこの時、参照アセンブリ群を指定して、オブジェクトファイルから参照出来るようにします。\n\nchibildはchibiccのバックエンドアセンブラとして開発しましたが、単独でも使用可能です。\nソースコードは、ILAsmと比べて簡素化された構文規則を採用するため、機械出力を行いやすく、\nかつ人間にとっても書きやすくなっています。\n\n\n----\n\n## 使用方法\n\nCLIバージョンのツールチェインを、nugetからインストール出来ます\n\n* chibias: [chibias-cli](https://www.nuget.org/packages/chibias-cli)\n* chibild: [chibild-cli](https://www.nuget.org/packages/chibild-cli).\n* chibiar: [chibiar-cli](https://www.nuget.org/packages/chibiar-cli).\n\n(紛らわしいのですが、 'chibias-cil' ではありません :)\n\n```bash\n$ dotnet tool install -g chibias-cli\n$ dotnet tool install -g chibild-cli\n$ dotnet tool install -g chibiar-cli\n```\n\n使用可能になったかどうかは、以下のように確認できます:\n\n```bash\n$ cil-ecma-chibild\n\ncil-ecma-chibild [0.63.0,net6.0] [...]\nThis is the CIL object linker, part of chibicc-cil project.\nhttps://github.com/kekyo/chibicc-cil-toolchain\nCopyright (c) Kouji Matsui\nLicense under MIT\n\nusage: cil-ecma-chibild [options] \u003cinput path\u003e [\u003cinput path\u003e ...]\n  -o \u003cpath\u003e         Output assembly path\n  -shared, -mdll    Produce dll assembly\n           -mexe    Produce executable assembly (defaulted)\n           -mwinexe Produce Windows executable assembly\n  -L \u003cpath\u003e         Reference assembly base path\n  -l \u003cname\u003e         Reference assembly name\n  -i \u003cpath\u003e         Will inject into an assembly file\n  -g, -g2           Produce embedded debug symbol (defaulted)\n      -g1           Produce portable debug symbol file\n      -gm           Produce mono debug symbol file\n      -gw           Produce windows proprietary debug symbol file\n  -s, -g0           Omit debug symbol file\n  -O, -O1           Apply optimization\n      -O0           Disable optimization (defaulted)\n  -x                Will not copy required assemblies\n  -d \u003cpath\u003e         CABI startup object directory path\n  -e \u003csymbol\u003e       Entry point symbol (defaulted: _start)\n  -v \u003cversion\u003e      Apply assembly version (defaulted: 1.0.0.0)\n  -m \u003ctfm\u003e          Target framework moniker (defaulted: net6.0)\n  -m \u003carch\u003e         Target Windows architecture [AnyCPU|Preferred32Bit|X86|X64|IA64|ARM|ARMv7|ARM64] (defaulted: AnyCPU)\n  -m \u003crollforward\u003e  CoreCLR rollforward configuration [Major|Minor|Feature|Patch|LatestMajor|LatestMinor|LatestFeature|LatestPatch|Disable|Default|Omit] (defaulted: Major)\n  -a \u003cpath\u003e         CoreCLR AppHost template path\n      --log \u003clevel\u003e Log level [debug|trace|information|warning|error|silent] (defaulted: warning)\n      --dryrun      Need to dryrun\n  -h, --help        Show this help\n```\n\n* chibildの実際のコマンド名は、`cil-ecma-chibild` です。chibiarやchibiasも同様です。\n  この命名規則は、GNU binutilsになぞらえたものです。\n* chibildは、コマンドラインで指示された複数の入力ファイル（オブジェクト '*.o'、CILソース '*.s'）\n  をアセンブルして、1つの.NETアセンブリにまとめます。\n* 参照ライブラリ名 `-l` は、アーカイブファイルパス ('*.a') を含めて、先頭から順に評価されます。\n  この機能は、重複するシンボル(関数/グローバル変数)にも適用されます。\n  また、ライブラリファイル名は、ネイティブツールチェインと同様に `lib` というプレフィックスが適用されている事を想定し、\n  かつ、フォールバックとして指定されたままのファイル名も想定します。\n* ターゲットフレームワークのデフォルト(上記の例では`net6.0`)は、chibildの動作環境に依存します。\n* ターゲットフレームワークの指定は、コアライブラリのバリエーションを仮定するだけで、\n  `mscorlib.dll`や`System.Private.CoreLib.dll`アセンブリを自動的に検出するわけではありません（別章参照）。\n* ターゲットWindowsアーキテクチャは、デフォルトで`AnyCPU`です。大文字小文字は無視されます。\n  この値は、アセンブリにマークを設定するだけです。異なる値を指定したとしても、生成されるオプコードには影響ありません。\n  WindowsのCLR環境以外では、常に`AnyCPU`として動作する可能性があります。\n* ログレベルは、デフォルトで`warning`です。大文字小文字は無視されます。\n* 注入モード `-i` を使用する場合は、 `-a`, `-v`, `-m` の指定が無視されます。\n* chibildには、システムアセンブリ（`mscorlib.dll`や`System.Private.CoreLib.dll`など）を除く、\n  参照されたアセンブリを自動的にコピーする機能がありますが、`-x`を指定すると、自動的にコピーしません。\n  この機能は簡易的なものであり、必要な全てのファイルをコピーしない場合があるため、注意が必要です。\n  複雑なデプロイを前提とする場合は、MSBuildによるビルドが必要になると思われます。\n\n\n----\n\n## Hello world\n\nchibildを使って \"Hello world\" を実行してみましょう。\n新しいソースコード・ファイル `hello.s` を作り、以下のようにコードを書きます。この4行だけでOKです:\n\n```\n.function public void() _start\n    ldstr \"Hello world with chibild!\"\n    call void(string) System.Console.WriteLine\n    ret\n```\n\n出来たら、chibildを呼び出します:\n\n```bash\n$ cil-ecma-chibild -mnet45 -L/mnt/c/Windows/Microsoft.NET/Framework64/v4.0.30319 -lmscorlib -o hello.exe hello.s\n```\n\n実行します:\n\n```bash\n$ ./hello.exe\nHello world with chibild!\n```\n\nこのサンプルは、 `mscorlib.dll` アセンブリに定義されている `System.Console.WriteLine()` を参照します。\nそして、このファイルは Windows のシステムディレクトリに存在するものを、WSL環境から指定しているため、\n少々わかりにくいかもしれません。\nしかし、chibildがどうやって参照するアセンブリを特定するのか、についてはこの例で十分でしょう。\n\nLinuxや他のOSでも、必要な参照を追加することで同じように使うことができます。\nまた、ビルトイン型（後述）だけを使用するコードをアセンブルした場合は、他のアセンブリへの参照は必要ありません:\n\n```\n.function public int32() _start\n    ldc.i4.1\n    ldc.i4.2\n    add\n    ret\n```\n\n```bash\n$ cil-ecma-chibild -mnet45 -o adder.exe adder.s\n$ ./adder.exe\n$ echo $?\n3\n```\n\n* 注意: この例では、アセンブル時に属性に関する警告が発生しますが、無視して構いません。\n* `main` 関数の `argc` や `argv` に相当する引数を使用する場合は、\n  スタートアップコード(`crt0.o`)の指定と、FCLである `mscorlib.dll` アセンブリへの参照が必要です。\n\n### .NET Coreなどで動かすには\n\nターゲットフレームワークを指定して、かつ参照アセンブリに`System.Private.CoreLib.dll`が含まれるようにします:\n\n```bash\n$ cil-ecma-chibild -mnet6.0 -L$HOME/.dotnet/shared/Microsoft.NETCore.App/6.0.13 -lSystem.Private.CoreLib \\\n  -o hello.exe hello.s\n```\n\nターゲットフレームワークと、対応するコアライブラリのバージョンは一致する必要があります。\n`net6.0`と指定して、.NET Core 2.2のコアライブラリを使用すると、警告が表示されます。\n\n注意: 現在のところ、マイナーなターゲットフレームワークには対応していません。\n例えば、`uap10.0`、`tizen1`や`portable+net45+wp5+sl5`などです。\n標準となる、ターゲットフレームワークのパーサーが、BCLに含まれていない事が理由です。\n\n### 参考: どうやってコアアセンブリファイルを入手するか?\n\n`mscorlib.dll` ファイルを合法的に入手したい場合は、\nnugetで公開されている、[ReferenceAssemblies (net45)](https://www.nuget.org/packages/microsoft.netframework.referenceassemblies.net45) パッケージを利用することができます。\n\nこのパッケージはMSがMITライセンスで提供しているものなので、自由に使うことができます。\nnupkgファイルはzip形式なので、`unzip` を使って中身を取り出すことができます。\n\n注意点として、本パッケージに含まれる全てのアセンブリは、コード本体を持ちません。\nchibildで参照することは可能ですが、実行することはできません。\nLinux環境などで実行する場合は、mono/.NET Coreなどのランタイムが必要になります:\n\n```bash\n$ mono ./hello.exe\nHello world with chibild!\n```\n\nいずれにしても、完全な `mscorlib.dll`や`System.Private.CoreLib.dll`ファイルを参照したい場合は、\n単にmonoや.NET SDKをインストールして、そのディレクトリ内のファイルを参照するほうが良いかもしれません。\n\n今のところ、chibildは、システムにインストールされたこれらのアセンブリファイルを自動的に検出しません。\nGNUアセンブラのように、単体で独立したアセンブラとして、意図的に設計した結果です。\n将来的には、MSBuildスクリプトを経由して、自動的にアセンブリファイルを解決出来るようになるかもしれません。\n\n(この目的のために、`chibicc.build` パッケージを用意しています。このパッケージはまだ不完全で使用できません。)\n\n\n----\n\n## chibildアセンブリ構文\n\nTODO: 作業中、まだ仕様が確定していません。\n\nこの章は随時更新していますが、現在の構文を確認するには、[テストコード](https://github.com/kekyo/chibicc-cil-toolchain/blob/main/chibild.core.Tests/AssemblerTests.cs) を参照して下さい。\n\nchibildの構文には、以下の特徴があります:\n\n* オプコードの本体は、殆どILAsmと同様に記述が可能\n* 不必要に冗長な記述を、可能な限り排除\n* OOPに関係するコードは、記述できないか制限がある\n\n基本的には、chibiccのように「C言語」を実現するために設計されていますが、\nILAsmと比較しても、はるかに簡単に書けるはずです。\n\n### 最小でエントリーポイントのみ含む例\n\n```\n.function public int32() _start\n    ldc.i4 123    ; これはコメントです\n    ret\n```\n\n* ソースコードは、常にUTF-8で解釈されます。\n* 行頭や行末の空白は無視されます。\n  * つまり、インデントはすべて無視されます。\n* セミコロン (';') はコメントの開始を意味します。行末までがすべてコメントとみなされます。\n* ピリオド ('.') で始まる単語は、「アセンブラディレクティブ」とみなされます。\n  * `.function` ディレクティブは、関数の開始を意味しています。以下の順にオペランドが続きます:\n    * スコープ記述子\n    * 関数のシグネチャ\n    * 関数名\n  * 次の関数ディレクティブが現れるまで、関数の本体が続きます。\n\nスコープ記述子は、他の宣言でも共通です。\n\n|スコープ記述子|内容|\n|:----|:----|\n|`public`|どのスコープからも参照可能。外部アセンブリからでも参照可能。|\n|`internal`|同じアセンブリ内でのみ参照可能。|\n|`file`|現在のソースコードファイルからのみ参照可能。|\n\n* コマンドラインのオプションに `-mexe` を指定するなどして、実行可能形式を生成する場合、\n  関数名が `_start` であれば、自動的にエントリポイントとみなされます。\n* `-efoo` と指定すると、エントリポイントのシンボルを `foo` に変更することが出来ます。\n\nエントリポイントのシグネチャは、CLRの要求に従います。つまり、以下の組み合わせが可能です:\n\n|関数シグネチャ|対応するC#でのシグネチャ例|\n|:----|:----|\n|`void()`|`static void _start()`|\n|`int32()`|`static int32 _start()`|\n|`void(string[])`|`static void _start(string[] args)`|\n|`int32(string[])`|`static int32 _start(string[] args)`|\n\n* 関数シグネチャについては、後述の解説を参照してください。\n\n#### 補足: スタートアップコード\n\nchibiccを使う場合、エントリポイントはあくまでC言語の `main` 関数として定義する事を想定しています。\n例えば、 `int main(int argc, char **argv)` です。\n\nこのシグネチャの違いは、スタートアップコードを含む `crt0.o` のようなオブジェクトファイルをchibiccが供給し、\nその中でC言語で必要な引数を生成することによって実現しています。\n（この目的のために、特殊な `-d` オプションが存在します）\n\nこのドキュメントでは、スタートアップコードを省いて解説しています。\n従って、スタートアップコードの規則は、常に上記の表に従います。\n\n### リテラル\n\n```\n.function public int32() _start\n    ldc.i4 123\n    ldc.r8 1.234\n    ldstr \"abc\\\"def\\\"ghi\"\n    pop\n    pop\n    ret\n```\n\n* 数値リテラル形式は、.NET format providerと互換性があります。\n  * 整数リテラル: `System.Int32.Parse()` などに `InvariantCulture` を適用した場合と同様です。\n  * 浮動小数点数リテラル: `System.Double.Parse()` などに `InvariantCulture` を適用した場合と同様です。\n* 文字列リテラルは二重引用符（'\"'）で囲みます。\n  * エスケープ文字は ('\\\\') で、トライグラフシーケンス以外はC言語仕様と同じです。\n  * 16進数 ('\\\\xnn')、UTF-16('\\\\unnnn') が使用可能です。\n\n### ラベル\n\n```\n.function public int32() _start\n    ldc.i4 123\n    br NAME\n    nop\nNAME:\n    ret\n```\n\nラベル名は (':') で終わります。\nラベル名は関数スコープ内で一意であることが必要です。\n\n### 型名\n\n型名は、ビルトイン型と.NETの型名の両方を指定出来ます。\n.NETの型名は、常に名前空間を含む完全限定名で指定します。\n例えば、`System.String`のような形式です。\n\nビルトイン型は以下の通りです:\n\n|ビルトイン型|実際の型|エイリアス名|\n|:----|:----|:----|\n|`void`|`System.Void`| |\n|`uint8`|`System.Byte`|`byte`|\n|`int8`|`System.SByte`|`sbyte`|\n|`int16`|`System.Int16`|`short`|\n|`uint16`|`System.UInt16`|`ushort`|\n|`int32`|`System.Int32`|`int`|\n|`uint32`|`System.UInt32`|`uint`|\n|`int64`|`System.Int64`|`long`|\n|`uint64`|`System.UInt64`|`ulong`|\n|`float32`|`System.Single`|`float`, `single`|\n|`float64`|`System.Double`|`double`|\n|`nint`|`System.IntPtr`|`intptr`|\n|`nuint`|`System.UIntPtr`|`uintptr`|\n|`bool`|`System.Boolean`| |\n|`char`|`System.Char`|`char16`|\n|`object`|`System.Object`| |\n|`string`|`System.String`| |\n|`typedref`|`System.TypedReference`| |\n\nビルトイン型のうち、`System.Boolean`型と`System.Char`型は特殊で、chibildがこれらの型を使用する場合、\n常に1バイト又は2バイトマーシャリングを適用します。\n.NETのデフォルトでは、これらの型のフットプリントサイズは、状況によって変化しますが、\nchibildを使って生成されるアセンブリは、常に上記のサイズとなる事を意味します。\n\n関数ポインタ型は、以下のように指定します:\n(空白で区切られたものは不可）\n\n```\nstring(int8,int32)*\n```\n\n疑似的にC#で記述すると:\n\n```csharp\n// スタティックメソッドの例\nstatic string foo(sbyte a, int b)\n\n// 関数デリゲートの場合\nunsafe delegate*\u003csbyte, int, string\u003e\n```\n\nまた、可変引数を持つ関数のポインタ型も、`...` を使用して表現できます:\n\n```\nstring(int8,int32,...)*\n```\n\n配列・ポインタ・参照（マネージポインタ）の組み合わせが可能です。\n\n* `int32[]`\n* `int32[][]`\n* `int32[4]`\n* `int32[4][3]`\n* `int32*`\n* `int32**`\n* `int32\u0026`\n* `string(int32\u0026,int8)*[42]`\n* `int(sbyte*)*(string,int8)*`\n\n配列の要素数を指定した型は、「値型配列」と呼ばれます。\n\n関数ポインタ型、可変引数、値型配列のそれぞれは、C#においてのデリゲート型、\n`params`による可変引数、`System.Array`を基底とした配列とは扱いが異なります。\n詳細は、別項を参照してください。\n\n### ローカル変数\n\n```\n.function public int32() _start\n    .local int32\n    .local int32 abc\n    ldc.i4 1\n    stloc 0\n    ldc.i4 2\n    stloc 1\n    ret\n```\n\n関数本体の中で、`.local` ディレクティブを使って、ローカル変数を宣言することができます。\nこのディレクティブはオプションで変数名を指定することができます。\n\nまた、オプコードのオペランドで、変数名を使用して参照することができます:\n\n```\n.function public void() foo\n    .local int32 abc\n    ldc.i4 1\n    stloc abc\n    ret\n```\n\nローカル変数の型が、参照（マネージポインタ）である場合は、自動的に `pinned` とマークされます。\nこれにより、値型へのポインタを扱う際の、スクラッチバッファとして使用できます:\n\n```\n.function public int32() foo\n    .local int32\u0026 buf    ; \u003c-- pinned\n    .local int32* p\n    ldsflda gv\n    stloc.0\n    ldloc.0\n    conv.u\n    stloc.1\n    ldloc.1\n    ldind.i4\n    ret\n.global int32 gv\n```\n\n### 別の関数を呼び出す\n\n```\n.function public int32() _start\n    ldc.i4 1\n    ldc.i4 2\n    call add2\n    ret\n.function public int32(x:int32,y:int32) add2 \n    ldarg 0\n    ldarg y   ; パラメータ名で参照することができる\n    add\n    ret\n```\n\n関数シグネチャのパラメータの定義は任意です。フォーマットは:\n\n* `int32`: 型名だけを指定する。\n* `x:int32`: パラメータ名と型名を指定する。\n\n関数名は、前方参照、後方参照のいずれも可能です。\n\n重要: chibildで定義された関数を呼び出す場合は、`call` オペランドに引数型リストを指定する必要はありません。\n.NETのオーバーロードされたメソッドを呼び出す場合は、引数型リストが必要です。\n\n関数の引数で、追加の可変引数を受け取ることが出来ます:\n\n```\n.function public int32(count:int32,...) add_n\n    .local System.ArgIterator\n    ldloca.s 0\n    arglist\n    call void(System.RuntimeArgumentHandle) System.ArgIterator..ctor\n    ; (ArgIteratorを使って列挙する)\n    ret\n```\n\n関数シグネチャの引数リストの終端に `...` を指定する事で、可変引数を受け取るようにマークされます。\n\n但し、この可変引数は、C#における可変引数とは扱いが異なることに注意してください。\nC#では、可変引数を.NET配列で受け取りますが、chibildではCILの`arglist`と呼ばれる機能を使います。\n\nこの可変引数は、上記例のように、`System.ArgIterator`型を用いて列挙を行います。\n詳しくは、C#の`__arglist`キーワードや`ArgIterator`で調べて下さい。\n\n可変引数を持つ関数の呼び出しは、引数の型リストを明示する必要があります。\n例えば、上記の`add_n`を呼び出す場合は:\n\n```\n.function public int32() _start\n    ldc.i4.s 123\n    ldc.r8 123.456    ; \u003c-- 追加引数\n    ldstr \"ABC\"       ; \u003c-- 追加引数\n    call int32(int32,float64,string) add_n\n    ret\n```\n\n追加引数に相当する型を含めた、関数呼び出しで渡すべきパラメータのすべての型を、シグネチャとして明示します。\nchibildはオプコードのフロー解析を行わないため、この指定が誤っていると、可変引数を持つ関数の呼び出しが実行時に失敗します。\n\n### 外部アセンブリの関数の呼び出し\n\n事前に `test.dll` を作っておきます。内容は以下の通りです:\n\n```\n.function public int32(a:int32,b:int32) add2\n    ldarg 0\n    ldarg 1\n    add\n    ret\n```\n\n```bash\n$ chibild -c test.s\n```\n\nその後、以下のように、上記アセンブリの関数を呼び出します:\n\n```\n.function public int32() _start\n    ldc.i4 1\n    ldc.i4 2\n    call add2\n    ret\n```\n\n```bash\n$ chibild -ltest main.s\n```\n\n関数（.NET CILメソッド）は、`C.text`という名前のクラス内に配置されます。\nそのマッピングは:\n\n* `int32() _start` --\u003e `public static int32 C.text::main()`\n* `int32(a:int32,b:int32) add2` --\u003e `public static int32 C.text::add2(int32 a, int32 b)`\n\n疑似的にC#で記述すると (test.dll):\n\n```csharp\nnamespace C;\n\npublic static class text\n{\n    public static int add2(int a, int b) =\u003e a + b;\n}\n```\n\n疑似的にC#で記述すると (main.exe):\n\n```csharp\nextern alias test;\nusing test_text = test::C.text;\n\nnamespace C;\n\npublic static class text\n{\n    public static int main() =\u003e test_text::add2(1, 2);\n}\n```\n\nこのような関数のメタデータ配置規則を、\"CABI (chibicc application binary interface) 仕様\" と呼びます。\n\nCABIが適用されるのは、外部アセンブリから参照可能な場合のみです。\n関数のスコープが `public` ではない場合は、外部のアセンブリから参照出来ず、CABI準拠ではなくなります。\n\n### 外部アセンブリの.NETメソッドの呼び出し\n\n.NETのメソッドを呼び出す場合は、メソッドのシグネチャと完全なメソッド名を指定します:\n\n```\n.function public void() main\n    ldstr \"Hello world\"\n    call void(string) System.Console.WriteLine\n    ret\n```\n\n指定する.NETのメソッドは `public` でなければならず、ジェネリックパラメータを持つメソッドを指定することはできません。\nインスタンスメソッドも指定できますが、メソッドシグネチャの引数に、 `this` の型は記述しません。\n当然ながら `this` の参照が評価スタックにプッシュされる必要があります。\n\nメソッドのシグネチャは、メソッドのオーバーロードを特定するために使用されます。\nシグネチャを指定せず、オーバーロードメソッドが複数存在する場合は、誤ったメソッドを選択する可能性があります。\n\n.NETメソッドを参照するために、コマンドラインオプション `-l` で、メソッド定義を含むアセンブリを指定する必要があります。\nこれは、最も標準的な `mscorlib.dll` や `System.Runtime.dll` にも当てはまります。\n\n補足: プロパティやインデクサを呼び出す必要がある場合は、それらを実装するメソッドのシグネチャを特定しておく必要があります。例えば:\n\n```\n    ldstr \"ABCDE\"\n    call System.String.get_Length   ; \"ABCDE\".Length\n```\n\n殆どのプロパティは慣例で、決まった命名規則を使います。上記のように、`System.String.Length`の場合は、\ngetterに`get_Length()`、setterに`set_Length()`というメソッド名に対応します。\nまた、インデクサの場合は、`get_Item()`や`set_Item()`というメソッド名に対応します。\n\n但し、これらの命名規則は強制ではないため、異なる名前を適用している可能性があります。\nうまくいかない場合は、ILDAsmやILSpy等のツールを使って確認して下さい。\n\n### 関数シグネチャ構文\n\n関数シグネチャは、呼び出し対象メソッドの引数群と戻り値の型を示す構文です。\n.NETでは、コールサイトと呼ばれる場合もあります。\nchibildでは、関数ポインタ型と同じような構文で指定します。\n\n関数ポインタ型と異なるのは、関数シグネチャはポインタではないため、終端に`*`が付かない事です。\n\n* `int32(string)*`: 関数ポインタ\n* `int32(string)`: 関数シグネチャ（コールサイト）\n\nこれらは、関数ディレクティブや、`call` や `ldftn` オプコードでメソッドのオーバーロードを特定したり、\n`calli` オプコードで使用します:\n\n```\n.function public int32() _start\n    ldstr \"123\"\n    ldftn int32(string) System.Int32.Parse\n    calli int32(string)\n    ret\n```\n\n### グローバル変数\n\nグローバル変数の書式は、ローカル変数の書式にスコープ記述子を加えたものです。\nただし、関数本体定義の外側に配置します:\n\n```\n.function public int32() _start\n    ldc.i4 123\n    stsfld foo\n    ldsfld foo\n    ret\n.global public int32 foo\n```\n\nグローバル変数名は、前方参照、後方参照のいずれも可能です。\n\nグローバル変数は `public` の場合、CABIに従って、`C.data` クラス内に配置されます。\n\n疑似的にC#で記述すると:\n\n```csharp\nnamespace C;\n\npublic static class data\n{\n    public static int foo;\n}\n\npublic static class text\n{\n    public static int main()\n    {\n        data.foo = 123;\n        return data.foo;\n    }\n}\n```\n\n### データの初期化\n\nグローバル変数の宣言は、初期化データを含むことが出来ます:\n\n```\n.function public int32() bar\n    ldsfld foo\n    ret\n; int32 foo = 0x76543210\n.global internal int32 foo 0x10 0x32 0x54 0x76\n```\n\nデータはバイト単位で埋める必要があります。\n\n初期化データを含んだ場合、そのメモリ領域に値を書こうとすると、`AccessViolationException`が発生する可能性があります。\n\n### イニシャライザ\n\nイニシャライザは、アセンブリのデータを操作する直前に実行される、関数の一種です。\n内部的には、.NETのタイプイニシャライザから呼び出されます。\n主に、グローバル変数の複雑な初期化処理に用いることが出来ます:\n\n```\n.initializer internal\n    ldc.i4 123\n    stsfld foo\n    ret\n.global public int32 foo\n```\n\nイニシャライザのスコープ記述子は、`public`と指定しても、`internal`と同じとみなされます。\nまた、スコープを定めるだけではなく、初期化が実行される契機も決定します:\n\n* `public`又は`internal`: `public`又は`internal`のスコープが指定されたグローバル変数を操作する直前に呼び出される。\n* `file`: `file`スコープが指定されたグローバル変数を操作する直前に呼び出される。\n\n### 値型の配列\n\n.NETには、値型のように振る舞う配列型がありません。\nchibildは、 `value array` 型を使ってこれを擬似的に実現することができます。\n値型の配列は、C言語コンパイラの実現において非常に重要な役割を担っています。\n\n値型の配列を使用するには、以下のように型を宣言します:\n\n```\n.function public int8[5]() bar   ; \u003c-- 値型の配列には要素数が必要\n    ldsfld foo\n    ret\n.global internal int8[5] foo 0x10 0x32 0x54 0x76 0x98\n```\n\nこのとき、`bar` 関数の戻り値と `foo` 変数の型は、 `System.SByte_len5` 型になります。\n具体的には、以下のような構造体型が自動的に宣言されます。\n\n疑似的にC#で記述すると:\n\n```csharp\nnamespace System;\n\n[StructLayout(LayoutKind.Sequential)]\npublic struct SByte_len5   // TODO: : IList\u003csbyte\u003e, IReadOnlyList\u003csbyte\u003e\n{\n    private sbyte item0;\n    private sbyte item1;\n    private sbyte item2;\n    private sbyte item3;\n    private sbyte item4;\n\n    public int Length =\u003e 5;\n    public sbyte this[int index]\n    {\n        get =\u003e /* ... */;\n        set =\u003e /* ... */;\n    }\n}\n```\n\nこの構造体型は、chibild（とchibicc）の外では、配列のように振る舞うことができます。\n\nまた、複合された型の自然な解釈も行われます。例えば:\n\n* `int8[5]*` --\u003e `System.SByte_len5*`\n* `int8*[5]` --\u003e `System.SByte_ptr_len5`\n* `int8[5][3]` --\u003e `System.SByte_len5_len3`\n* `int8[5]*[3]` --\u003e `System.SByte_len5_ptr_len3`\n\nネストした配列型を宣言する場合は、要素の順序に注意が必要です。\n例えば、C言語で以下のように表現される型は、chibildでは要素の順序が逆になります:\n\n```c\n// C言語\nchar foo[3][4][5];\n\n// chibild\nint8[5][4][3] foo\n```\n\nこれは、chibildが配列型を以下のように、左から右へと評価するためです。前述の複合された型定義も同様です:\n\n`( ( int8 [5] ) [4] ) [3]`\n\n注意: 値型配列を使用するには、`System.ValueType` 型と `System.IndexOutOfRangeException` 型への参照が解決される必要があります。\n`mscorlib.dll` 又は `System.Private.CoreLib.dll` への参照を追加して下さい。\n\n### 列挙体型\n\nchibildで定義できる列挙体型は、.NETでの列挙体型と同様で、`System.Enum` を暗黙のうちに継承した型です。\n\n```\n.enumeration public int32 foo\n    beef\n    pork\n    chicken\n```\n\n疑似的にC#で記述すると:\n\n```csharp\nnamespace C.type;\n\npublic enum foo : int\n{\n    beef,\n    pork,\n    chicken\n}\n```\n\nデフォルトでは、列挙値に割り当てられる値は、0から順にインクリメントされた値となります。\n明示的に指定する場合は:\n\n```\n.enumeration public int32 foo\n    beef 5\n    pork 13\n    chicken 42\n```\n\n列挙体型は、元となる数値の型を変更することが出来ます:\n\n```\n.enumeration public int64 foo   ; 値をint64として定義\n    beef 5\n    pork 13\n    chicken 42\n```\n\n元となる型には、以下の型のみ指定可能です:\n\n* `int8`, `uint8`\n* `int16`, `uint16`\n* `int32`, `uint32`\n* `int64`, `uint64`\n\n注意: 列挙体型を使用するには、`System.Enum` 型への参照が解決される必要があります。\n`mscorlib.dll` 又は `System.Private.CoreLib.dll` への参照を追加して下さい。\n\n### 構造体型\n\nchibildで定義できる構造体型は、.NETでの構造体型と同様で、`System.ValueType` を暗黙のうちに継承した型です。\n\n```\n.structure public foo\n    public int32 a\n    internal int8 b\n    public int32 c\n```\n\n疑似的にC#で記述すると:\n\n```csharp\nnamespace C.type;\n\n[StructLayout(LayoutKind.Sequential)]\npublic struct foo\n{\n    public int a;\n    internal sbyte b;\n    public int c;\n}\n```\n\n構造体の各メンバーには、スコープ記述子が指定出来ます。\n但し、`public` と `internal` のみで、`file` は指定出来ません。\n\nデフォルトでは、構造体のパッキングはCLRに任されています。\n明示的に指定する場合は:\n\n```\n.structure public foo 4  ; pack=4\n    public int32 a\n    public int8 b\n    public int32 c\n```\n\nまたは各メンバーにオフセットを与えます:\n\n```\n.structure public foo explicit\n    public int32 a 0     ; offset=0\n    public int8 b 4      ; offset=4\n    public int32 c 5     ; offset=5\n```\n\nオフセットを任意に調整することで、C言語における共用体型を再現することができます。\n\n構造体型の最後のメンバーには、要素数を指定しない値型配列を指定することが出来ます:\n\n```\n.structure public foo\n    public int32 a\n    public int8 b\n    public int32[*] c\n```\n\n配列の要素数を`*`と指定すると、この値型配列は要素数を特定しない型（フレックス配列）となります。\nこの型は特殊な値型配列で、配列のインデクサアクセスは、要素数の範囲外チェックが行われません。\n当然、存在しない要素にアクセスした場合の結果は未定義となるため、注意が必要です。\n\nフレックス配列は、構造体型の最後のメンバーに使用することを想定していますが、\nchibildはこのチェックを行いません。\n\n注意: 構造体型を使用するには、`System.ValueType` 型への参照が解決される必要があります。\n`mscorlib.dll` 又は `System.Private.CoreLib.dll` への参照を追加して下さい。\n\n### シンボルの重複について\n\nchibildは、任意の型・グローバル変数・関数（これらをメンバーと呼称します）を検索する際に、以下のように検索を実行します:\n\n1. 同一のオブジェクトファイル内に定義された、`file` スコープのメンバーが見つかれば、それを参照します。\n2. 異なる入力に定義された、 `public` または `internal` スコープのメンバーが見つかれば、それを参照します。\n   この時、検索の優先順位は、コマンドラインオプションに指定した入力群（オブジェクトファイル・アーカイブファイル・アセンブリファイル）の順に検索されます。\n3. 見つからないため、エラーが発生します。\n\nメンバーのシンボル名は、それぞれのメンバー種別に応じて検索されます。\nシンボル名が同一でも、型・グローバル変数・関数は、それぞれ別として扱われます。\n\n### 位置情報を明示する\n\n`.file`と`.location`ディレクティブは、シーケンスポイントと呼ばれるデバッグ情報を生成します。\nシーケンスポイントは、実行中のコードがソースコードのどこに対応するのかを検索するために使用されます。\nつまり、この情報を与えると、デバッガが実行中のコードの位置を、ソースコード上で示すことが出来るようになります。\n\nこれらの情報は任意で、存在しなくてもアセンブル処理に影響はありません。\n\n```\n.file 1 \"/home/kouji/Projects/test.c\" c\n.function public int32() _start\n    .location 1 10 5 10 36\n    ldc.i4 123\n    ldc.i4 456\n    add\n    .location 1 11 5 11 32\n    ldc.i4 789\n    sub\n    ret\n```\n\n* `.file`は，IDをソースコード・ファイルに対応付けます。\n  * 第1オペランド: ID (数値を含む任意のシンボル名。GNUアセンブラの `.fil` ディレクティブと同じ)\n  * 第2オペランド: ファイルパス（またはソースコードを識別する）文字列\n  * 第3オペランド: 言語名称。以下のリストを参照(オプション)\n  * `.file`ディレクティブは常に宣言することができ、同じIDを上書きします。\n* `.location`ディレクティブは、ソースコードの位置を示します。\n  * 第1オペランド: 参照するソースコード・ファイルのID。\n  * 第2オペランド: 開始行のインデックス (0ベースのインデックス)\n  * 第3オペランド: 開始桁のインデックス (0ベースのインデックス)\n  * 第4オペランド: 終了行のインデックス (0ベースのインデックス、かつ開始行以上)\n  * 第5オペランド: 終了桁のインデックス (0ベースのインデックス、かつ開始桁より大きい)\n  * `.location`ディレクティブは、関数本体でのみ宣言可能です。\n  * `.location`ディレクティブを指定した直後のオプコードにのみ、適用されます。\n\n言語名称の例（すべてではありません）:\n\n|言語名称|言語|\n|:----|:----|\n|`cil`|CIL|\n|`c`|C|\n|`cpp`|C++|\n|`csharp`|C#|\n|`fsharp`|F#|\n|`other`|-|\n\n言語名称は、[Mono.Cecil.Cil.DocumentLanguage](https://github.com/jbevain/cecil/blob/7b8ee049a151204997eecf587c69acc2f67c8405/Mono.Cecil.Cil/Document.cs#L27) に由来しています。\n\nこれらのディレクティブを適用しなかった場合は、CILソースファイル自身を示すようなデバッグ情報を生成します。\nしかし、`.hidden`ディレクティブを使用すると、以降のコードでシーケンスポイントを生成しなくなります:\n\n```\n.function public int32() _start\n    .hidden\n    ldc.i4 123     ; \u003c-- シーケンスポイントは出力されない\n    ldc.i4 456\n    add\n    ret\n```\n\nこのような場合でも、再び有効なIDを指定する`.location`ディレクティブを指定すれば、シーケンスポイントを出力する事に注意して下さい。\n\n\n----\n\n## 注入モード\n\n注入モードは、chibildの特徴的な機能の一つで、あらかじめ用意された .NETアセンブリファイル内に、直接CILコードを埋め込むモードです。\nこのモードは、コマンドラインオプションで `-i` を指定する事で有効化されます。\n\n例えば、C#でコンパイルされた .NETアセンブリ `managed.dll` が存在する場合、\n注入モードを使用することで、 `managed.dll` 内にアセンブルした結果のCILコードを直接埋め込むことが出来ます。\n\n以下のようなC#ソースから生成した `managed.dll` アセンブリが存在するとします:\n\n```csharp\nnamespace C;\n\n// CILコード側から認識できるように、C.textクラス内にメソッドを配置する\npublic static class text\n{\n    public static long add_int64(long a, long b) =\u003e\n        a + b;\n}\n```\n\n注入モードを使用すると、以下のCILコードを直接 `managed.dll` 内に「注入」して、`add_int64` と正しくリンク出来ます:\n\n```\n.function public int32() add_c\n    ldc.i4.1\n    conv.i8\n    ldc.i4.2\n    conv.i8\n    call add_int64    ; C#側のメソッドを呼び出す\n    conv.i4\n    ret\n```\n\n以下のコマンドを使用して `injected.dll` を生成します:\n\n```bash\n$ cil-ecma-chibild -mnet6.0 -L$HOME/.dotnet/shared/Microsoft.NETCore.App/6.0.13 -lSystem.Private.CoreLib \\\n  -i managed.dll -c -o injected.dll add_c.s\n```\n\nこれは、chibiccなどで生成されるC言語のソースコードを、直接C#ソースコードと合成して生成させ、\n単一の .NET相互運用アセンブリファイルを生成出来る事を意味します。\n\n現在のバージョンでは、CILソースコードから注入対象 .NETアセンブリ内のシンボルを参照することが出来ます。\n\n* 将来のバージョンで、.NETアセンブリからCILの関数シンボルを参照する事が出来るようにする予定です。\n\n\n----\n\n## ソースコードのビルド\n\nビルドは.NET 8 SDK環境で可能です。ビルドに必要な前提条件はありません。\n例えば:\n\n```bash\n$ dotnet build chibicc-cil-toolchain.sln\n```\n\nテストは現在のところ、ネイティブバイナリのILDAsmに依存しているため、Windows x64環境またはLinux x64でのみ実行できます。\n手元の環境で、30秒ほどかかりました。\n\n```bash\n$ dotnet test chibicc-cil-toolchain.sln\n```\n\n`build-nupkg.bat`又は`build-nupkg.sh`を使用すると、NuGetパッケージを`artifacts`ディレクトリに生成します。\n`chibias.net4`と`chibild.net4`プロジェクトは、`Release`ビルドで`net48`向けの単一ファイルバイナリを生成します。\n\n\n----\n\n## TODO\n\n[TODO (英語)](https://github.com/kekyo/chibicc-cil-toolchain#todo) を参照してください。\n\n----\n\n## chibicc-toolchainの背景\n\n当初は [ILAsm.Managed](https://github.com/kekyo/ILAsm.Managed) を使っていたのですが、いくつか問題点がありました:\n\n* アセンブリ参照の解決。\n  ILAsm では、外部アセンブリで定義されたメンバを参照する場合、明示的にアセンブリ名を修飾する必要があります。\n  しかし、コンパイラ内部でこれを解決するのは簡単ではありません。\n* `.maxstack`の計算。\n  評価スタック全体の消費量を測定するために、コンパイラ内部で実行フローを解析する必要があります。\n* デバッグ情報の提供\n  ILAsmはデバッグ情報を提供することができますが、以下のような問題点があります。\n  * CILソースコード自身を参照するようなデバッグ情報は得ることができるが、元のソースコードへの参照を作成することはできない。\n    これは、GNUアセンブラにおける `.fil` と `.loc` ディレクティブに相当します。\n    また、.NET環境では、より豊富なデバッグ情報を提供できる可能性がありましたが、ILAsmを使う限りは不可能です。\n  * マネージドデバッグ情報は「MDB」形式であり、現代では適しません。\n    \"Portable PDB\" や \"Embedded\" で出力できることが必要です。\n    MSが提供するILAsmを使えば解決するのですが、[別の問題](https://github.com/kekyo/ILAsm.Managed#background)があります。\n* ILAsmは構文規則が複雑で冗長です。\n  * 過剰なカーリーブレイス構文 ('{ ... }') をなくしたい。\n  * 殆ど使用されない、オプショナルなメンバー属性をなくしたい。\n  * 名前空間名やメンバー名の過剰な修飾をなくしたい。\n\nILAsmを使いながらこれらを回避するのは難しいと判断し、必要最低限の機能を備えた独自のアセンブラを実装することになりました。\n\nchibicc-cilの移植と並行して実装を行っていますが、その際に新たに見出した機能の追加や変更を行っています。例えば:\n\n* 値型の配列機能を追加\n* グローバル変数の初期化機能を統合\n* CABIの定義\n\n----\n\n## License\n\nUnder MIT.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkekyo%2Fchibicc-cil-toolchain","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkekyo%2Fchibicc-cil-toolchain","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkekyo%2Fchibicc-cil-toolchain/lists"}