こんにちは、川合です。
まず最初にこの移植計画の名称についてです。
今は単に「gcc移植計画」となっていますが、今後はこの見方を改め
て、「GO計画」の足がかりとしてgccを移植している、という風に進め
たいと思っています。それにともない、名称も変えようと思います。
名称については、最初、「MinGO」（みんご）にしようと思っていま
した。つまり、MinGWのような方向性でOSASK版gccを作ろうと思ってい
たわけです。しかし、いろいろ考えていると、「gccを動かせるような
環境をどうにかして構築する」というよりも、「OSASKで動くgcc（Cと
C++）をどうにかして用意する」という感じになってきました。MinGW
は、gccにはほとんど手を加えずにうまくやっているようですが、僕が
やろうとしているのはその方向性ではないわけです。gccをOSASK向き
に改造してしまいたいわけです。
そうなると、もうMinimalistを名乗る意味が希薄になると思います
し、それに方向性が違うのにMinGWと似たような名前にしたら、混乱
するだけでしょう。ということで、「GO」（じーおー）と名前を変え
ます。これから開発していくプログラムもGO-CとかGO-C++と呼んでく
ださい。
---
さてそれでは具体的な開発の方向性を書きます。
まずライセンスについてです。改変部分については川合堂ラインセ
ンス-01を適用します。一言で言ってしまえば、これに尽きます。
もちろんGPLのコードが部分的に混ざっている以上、GOのバイナリ全
体としてはGPLです。しかしそのGPLの規定によって公開されるソース
は、GPL部分と川合堂ライセンス-01部分に分解します。もしこの分解
解釈がGPLの規定によって許されないなら、以下のようにします。
１．書き加えた部分だけのソースをパッチとして（diffなどで分離さ
せる）、川合堂ライセンス-01で、しかも別の名前（たとえばGOKLとか
）でまずリリースする。
２．そしてGOそのものは、GOKLとgccをマージしたものと解釈し、そ
れゆえにGOはgccとGOKLの派生物になります。そして川合堂ライセンス-
01とGPLによりGOのライセンスはGPLになります。
３．これでGOKLだけをベースに開発する人にとっては、制限の強いGP
Lからは無関係でいられます。
そして将来的には、GO全体が川合堂ライセンス-01だけで書けるかも
しれません。僕はもちろんそこまではできません。みなさんがどれだけ
GO計画に賛同するかで決まるでしょう。
---
gccやMinGWは、たとえばg++.exeという実際のコンパイラ本体を作る
ことを主眼にしています。GOでは、そういう考え方をしません。GOが作
成するのは、以下の3つの関数です。
void cpp0(struct STR_CPP0_INTERFACE *interface);
void cc1(struct STR_CC1_INTERFACE *interface);
void cc1plus(struct STR_CC1PLUS_INTERFACE *interface);
また、この3つの関数群の記述には条件が付きます。それは、
「入出力方法は、メモリアクセスか、もしくは"GO_lib.h"で規定さ
れる10個程度の関数しか使わない」
というものです。
もちろん、いきなりこの状態に持っていくのはあまりに大変です。で
すから最初は、メモリと"GO_lib.h"しか使わない<stdio.h>や<stdlib.h
>などを用意します。これをかぶせれば、まあとりあえずソースをそれ
ほど大規模にいじらないで済むでしょう。
予定では、たとえば<string.h>については、Gakuさんが以前作ってく
ださったものをそのまま使うつもりです。あれはメモリアクセスだけで
完結していて、外部の関数を使っていませんから。それにすでに川合堂
ライセンス-01になっているので、ライセンス上も問題無しです（あり
がたいことです）。
"GO_lib.h"は主にファイルアクセス方法を提供します。ファイルアク
セスとは言っても、fread()などのバッファアクセス群ではなく、メモ
リマップトか、もしくはフルロード型のアクセスです。具体的に言うと
、
unsigned char *GO_mmap(GO_FILE *gfp);
で定義される関数を呼び出すと、gfpで指定されたファイルがどこかの
アドレスに展開されて（とりあえず全部読み込まれたと思ってください
）、そのアドレスが返されます。ファイルサイズについては、gfp->siz
eで分かります。
なお、"GO_lib.h"ではライトアクセスはサポートされません。生成し
たプリプロセス済みソースや、アセンブラソースなどはinterface->out
buf0で示されるアドレスへバイトデータとして書き並べるだけです。そ
してinterface->outbuf1で示されるアドレスを超えて書き込んではいけ
ないので、その場合はinterface->errcodeにGO_ERR_BUFOVERをセットし
てリターンします。エラー出力に関しても、interface->errbuf0とinte
rface->errbuf1を使います。
また入力ファイルについても原則としてinterface->inbuf0に展開さ
れていますので、このGO_mmap()関数は、もっぱらインクルードファイ
ルを読み込むときだけ使います。
こんな感じでGOが提供するcpp0()、cc1()、cc1plus()の3つの関数は
とにかく実行に際して必要になる環境依存がとても小さいです。後は、
コマンドライン部を解釈してこれらの3関数を呼び出すプログラムを作
って、さらに"GO_lib.h"に規定された10個程度の関数を実装すれば、O
SASKだろうと、win32だろうと、POSIXだろうと、実に簡単に移植でき
ることになります。newlib仕様などという豪華なライブラリは不要で
す。
もう気づいた人もいるかもしれませんが、これはNASKの開発方法と
全く同じです。
---
gccのソースは、いろいろなC言語環境でコンパイルできるように、非
常にたくさんの条件コンパイル部分を持っていますが、GOではそれをあ
えてなくしてしまってもかまわないとします。GOはGOでコンパイルでき
ればいいです。古いプロトタイプ宣言しかできないような処理系に対応
しなきゃいけないとか、そういうことは一切ありません。
条件コンパイルの中でも、たとえばconstなデータを.textに置くかそ
れとも.dataに置くかなどの自由度はそのまま残しておきたいと思って
います。
またcpp0()などの3つの関数を記述するに当たっては、取り扱う全て
のファイルサイズはunsigned intで表現可能であると想定することにし
ます。unsigned intで表現できないようなファイルサイズは全部を読み
込めないことになり、そもそもGOで扱う範疇を超えているためです。
いまのところでは、こんな感じです。"GO_lib.h"の詳細については、
今日の夜か、明日の夜くらいには明確にしたいと思っています。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/