exeGCC について
文責 京都マイクロコンピュータ（株）exeGCC 開発責任者 若槻俊宏 2020/12/2
注釈
本項は技術ドキュメントではなく読み物となります。個人の主観が入るため、文責を明記してあります。KMC 全体の意見を代表するものではありません。
SOLID ユーザにとっては同梱されているツールチェーンというイメージが強いかもしれませんが、exeGCC はもともとは単体の製品として販売されてきたもので、その歴史は SOLID よりもはるかに古く、1995 年頃まで遡ります。ここでは exeGCC に関する様々な情報を解説します。
exeGCC という名前について
現在では Windows 上で GCC が使用できるのは当たり前のことですが、90 年代当時はそうではありませんでした。Cygwin や MinGW が実用的になってきたのは 90 年代が終わる頃です。
（余談ですが筆者は 2002 年に大学に入学し、C プログラミング演習は SUN Microsystems 社の Solaris という UNIX が動作する SPARCStation 上で行われましたが、学友の多くは既に Windows Me/2000 上の Cygwin で課題を行っていた記憶があります。）
端的に言うと、KMC が 90 年代前半に販売していた EXE386 という DOS エクステンダ上で動く MS-DOS 向け GCC が発端なので、exeGCC という名前なのですが、これだけでは全く意味不明だと思います。
exeGCC ができあがるまでには長い苦労の歴史があり、ある意味では KMC という会社の発展そのものと言えます。ここでは KMC の創業関係者から聞き出した当時の話を元に、exeGCC という名前の由来とその歴史をまとめます。
本項に関しては、なにぶん 30 年前のことなので、当時の関係者の記憶違いや筆者の理解不足、わかりやすくするために説明を簡略化している点をご理解ください。
8086 のデバッガ製品の開発
以下が 1985 年の KMC 創業から 1995 年の exeGCC の販売までの略年表です。括弧書き内は関連する KMC 以外の動向となります。
（1981年 Microsoft Disk Operating System が IBM PC にバンドルされ発売）
（その後 IBM PC 以外でも MS-DOS 2.0 がバンドル販売され普及）
1985年 KMC 設立
1987年 PARTNER（MS-DOS 2.0 上で動作）発売
1988年 PARTNER v.2.0（NEC PC-98 上で動作）発売
（1989年 富士通 FM TOWNS 発売）
（1990年 Microsoft Windows 3.0 発売）
1990年 EXE386/286 DOS エクステンダ、PARTNER v.3.0（MS-DOS 上で動作）発売
1991年 Turbo-486（PC-98 用 intel 80486 CPU アクセラレーションボード）発売
1992年 PARTNER-ET（組み込み用 ROM ICE）発売
1995年 exeGCC、PARTNER/Win（Microsoft Windows 95 上で動作）発売
創業時はマクロアセンブラ PROASM-II や、様々なプラットフォーム向けの CPU アクセラレータ Turbo シリーズを販売（最も成功した Turbo-486 のみ記載）していましたが、その後の KMC の主製品は一貫して組み込みソフトウェア開発向けデバッガ（ハードウェア含む）となります。
デバッガは一見 GCC と直接は関係ないように思えます。しかしこの初代 PARTNER デバッガ（MS-DOS 2.0 上で動作し MS-DOS プログラムをデバッグ可能な 8086 コマンドラインデバッガ）が全ての始まりとなります。KMC はその後、68000 や Z80 などにも展開しながら、MS-DOS や Windows 上で動く PARTNER デバッガを開発・販売してきました。そして社内では PARTNER 自身を含む全ての DOS/WIN プログラムをデバッグするための（販売していない）デバッガを開発・使用しています。これは現在でも同じです。
その過程で MS-DOS プログラムの 640KB という非常に厳しいメモリ制限を緩和するために、EXE386 という 32 bitプロテクトモードでプログラムを動作させる仕組みを開発しました。GCC はもともと UNIX 上で開発されたプログラムなので、32bit フラットメモリ空間が必要不可欠です。もし EXE386 が存在しなければ、exeGCC も存在しなかったでしょう。
余談となりますが、EXE386 を開発できたのは、やはり自社でデバッガ技術を持っていたためであるという大きな成功体験となり、KMC の「自分たちの製品を自分たちのデバッガでデバッグしながら作り上げていく」という企業文化となりました。KMC のデバッガの一番のヘビーユーザーは KMC のデバッガ開発者ということです。
FM TOWNS GCC 環境
前置きが長くなりましたが、exeGCC の土台となったのは FM TOWNS という、DOS エクステンダ（RUN386）ネイティブな MS-DOS パーソナルコンピュータで誕生しつつあった GCC 環境です。EXE386 を FM TOWNS に対応させ、FM TOWNS 用の GCC 環境を最初のブートストラップに使用したそうです。DOS エクステンダで 1-2 MB ほどメモリが使用できたので、なんとか GCC を動かすことが可能だったそうです。 （もう関係者も当時の詳細は忘れてしまったそうですが、有名な MS-DOS 用 GCC の DJGPP では無かったようです。まだ始まったばかりのプロジェクトで、ライブラリなど様々なものが足りなかったそうです。）
当時は Linux マシンも珍しかったそうですが、Linux 上でネイティブの GCC をビルドし、生成したファイル類を FM TOWNS に持ってきて、その GCC 環境でなんとかビルドできるようにしたそうです。（GCC をビルドするためには、yacc/lex の GNU 版 bison/flex を始めとする GNU ツールがたくさん必要なため、それら全部を移植するのは非現実的です。）DOS はファイル名に 8 文字制限があり、ファイル名を相互変換する仕組みを作ったりと、とにかく大変だったそうです。
現代の感覚だと、Linux 上で DOS ターゲットのクロスコンパイラを動かせば良いのでは？と思いますが、当時も無くは無かったそうですがいろいろ難しかったとのことです。何よりも自分たちで開発していた PARTNER が自分たちは一番使いやすいので、DOS 上で動かしたかった、DOS 上で動けば後はなんとでもなるという思いが強かったそうです。
COFF ファイルを DOS 上で実行する exeGCC
なんとか GCC が DOS 上で動くようになったものの、これはあくまでも Linux ターゲットの GCC なので、生成される実行ファイルは COFF 形式で、DOS（COM 形式）では実行できません。そこで今度は DOS 上で COFF を実行するためのローダや、文字コードや改行コードを Linux に合わせるための仕組みなどを地道に作ったそうです。これは、GCC 自体を DOS 上で動かすためのランタイム（ホストの libc）の open や read を自前で実装していたので、日本語（Shift_JIS）を含むテキストデータを読んだ場合は、C 言語の "\xhh" 記法（16 進数埋め込み）に適切に変換した上で読み込むようにして実現したそうです。
これで、なんとか DOS 上で動くネイティブ GCC を作り上げ、次にそれを使って同じようにして Linux 上で準備したクロスの GCC（ARM などのターゲット向けの実行ファイルを生成可能）を DOS 向けにビルドすることにより、exeGCC は開発されました。
かなりややこしいですが、後の MinGW のように、直接 DOS の COM 形式を生成できるように GCC を改造したというわけではありません。あくまでも生成するのは COFF 形式ですが、それを DOS 上で実行できるようにしたということです。具体的には、gcc.exe というローダを実行すると、本体の gcc.out をメモリ上にロードしてソースコードをコンパイル、生成されるのは COFF 形式です。ターゲットがクロス（DOS 以外の ARM など）の場合は、最終的には ROM 化したイメージ（バイナリ）になれば良いので、実行ファイルの形式をユーザが意識する必要はありません。
現在の MinGW exeGCC
GCC4 以降は Linux 上の MinGW 環境でクロスビルドした Windows ネイティブの、ごく普通のプログラムとなりました。MinGW は PE（Portable Executable）という、COFF から派生した Microsoft Windows の実行ファイル形式を直接生成することができます。
exeGCC4 というバージョンについて
この 4 は、GCC のバージョンではなく、exeGCC の製品バージョンとなります。
もともとは、exeGCC3 まで、製品バージョンと GCC のバージョンはほぼ対応していました。（exeGCC2 は 2.x、exeGCC3 は 3.x のように。）
exeGCC4 も、GCC 4.x に対応してバージョンアップを重ね、GCC 5.1 が出てきて、次は exeGCC5 を予定していた時期もありました。しかしその後、GCC のバージョン番号ルールが変わり、GCC 6、GCC 7 とメジャー番号が毎年上がるようになりました。（本稿執筆時点では GCC 10.2 が最新安定板です。）
これはプログラミング言語 Java のバージョンが 1.4 の次から 5.0 に上がったように、世界的な流れに沿ったように思われます。おそらくマイナーバージョンが上がっただけではインパクトが弱いので、プロモーション的にはどんどんメジャー番号を上げて行きたいという狙いがあると思われます。
現状ではサポートの都合上（現在ではサポートが終わっているのですが、今でも exeGCC2 や exeGCC3 に関しての問い合わせをいただくことがあります。）4 というバージョンはそのままにしているのですが、将来的には廃止してシンプルに exeGCC だけ、あるいは SOLID Compiler Toolchain のような別の名前になるかもしれません。（SOLID では既に、GCC ではなく Clang コンパイラがメインとなっている現状もあります。）
このような歴史があり、現在では exeGCC4 は「MinGW でビルドされた GCC」という意味で使用しています。それ以前は前述したように、非常に特殊な構造のプログラムとなっていたため、セキュリティが厳しくなった Windows 10 以降は動作不可能になりました。MinGW でビルドできるようになってからは、通常の Windows プログラムなので、今後製品バージョンが上がることは無いと思われます。
exeGCC の各製品バージョンの概要
exeGCC(1995): 主に MS-DOS 用
SH、V85x、68k などがターゲット。当時の商用コンパイラが高価だったため、開発・販売開始。
exeGCC2(1999): Windows サポート開始
ARM, MIPS, PPC などターゲットがさらに広がり、C++ サポート開始。
exeGCC3(2003): GCC 3 対応
この頃にはほぼ機能的には現代と同等になります。
exeGCC4(2009): MinGW ビルド版
汎用版（単体製品）としては r004 までリリース。（GCC 4.8.5）
その後は SOLID 同梱の s シリーズに開発の中心が移る。
（s001: GCC 4.9.4、s002-s005: GCC 6.4.0）
AArch64（64 bit ターゲット）と C99 以降のサポートのため NetBSD の libc を採用。
r004 まで使用していた KMC 独自実装の libc（C89 までサポート）は、s005 で Cortex-M をサポートするにあたり省メモリターゲット用として一部復活。
参考サイト
wikipedia「DOSエクステンダ」2019/8/30 版
KMC に関する言及を本稿執筆の参考にしました。2020/12/2 最終閲覧。