Martin Otte は、Linux を実行している PPC ベースの Macintosh で g95 をコンパイルしたと書いています。彼が抱えていた唯一の問題は、次のサブルーチンで のva_list型 の不正な操作でした。error_print
static void error_print(char *type, char *format0, va_list argp0) {
…
va_list argp;
…
argp = argp0;
割り当てステートメントを . に置き換えるハックを彼に送りました memcpy。これがどれほど合法的または移植可能になるかはわかりません…どんなアイデアでもいただければ幸いです。私は C が得意だと思っていましたが、魔法使いの意見が必要です。ここで移植性が非常に悪い場合は、おそらくコピー/代入の必要性を回避するようにコーディングできます。
その後、型チェック コードを解析フェーズから新しい解決フェーズに移行する作業を開始しました。割り当て、IF、および代替 RETURN ステートメントが変換されました。SELECT ステートメントは、より多くの労力を費やしています。
昨日、Sourceforge のパーミッションが再び台無しになりましたが、修正されたようです。また。
5月17日
よく考えた結果、gcc バックエンド用に SGI のコンパイラを再ターゲットするのではなく、現在の g95 で作業を再開することにしました。決定の他のいくつかの理由は次のとおりです。
他の人のコードではなく、自分のコードを扱う方が常に簡単です。
SGI コンパイラは、いくつかの fortran 95 拡張機能を備えた fortran 90 のみです。SGI はこれに取り組んでいます。
私以外の何人かは、g95 を十分に理解しており、バグ修正やコードの新しい部分を提出することができます。
G95 は、後付けするのではなく、最初から gcc を使用することを意図しています。
G95 は、バックエンド自体と通信を開始する準備がほぼ整っています。g95 がそれほど進んでいなかったら、私はおそらく、リターゲットについてより長く、より懸命に検討していたでしょう。
SGI コンパイラの再ターゲットに向けた最初の進行は、非常に遅く、困難です。
プログラミングに関する最も皮肉なことの 1 つは、これまでに書かれた最悪のコードの一部を作成する科学者が、通常、他の人のコードを自分の目的に適合させることにほとんどの時間を費やしていることです。私自身科学者として、私はそこに行ったことがありますが、あまり好きではありません。
SGI フロントエンド (380k 行) と初期 (現在は幼虫?) の g95 コンパイラのサイズが大きいにもかかわらず、g95 は fortran 95 ソースを読み取るためのアプローチがまったく異なるため、g95 は SGI コンパイラよりもはるかに小さくなると思います。ファイル。SGI の作成者は、語彙アナライザーを非常に複雑にする従来のトークンベースのコンパイラーを選択しました。
g95、SGI-IA-64、および gcc に関するライセンスの問題がいくつかありましたが、最終的には比較的重要ではないと思いました。興味のある方は、g95-develop および gcc メーリング リストの冗談をフォローしてください。私の見解では、ライセンスの問題が g95/SGI-64 の「最終的な安息の地」を決定するものであり、それ以外のことはほとんどありません。
私が欲しいのは、今後数十年にわたって使用するほとんどのコンピューターで動作する Fortran 95 コンパイラーです。したがって、私はその一般的な方向に向かっています。
5月15日
ビッグ ニュース — SGI が 自社の fortran 90 コンパイラのソースをリリースしました。ライセンスは FSF の匂いテストに合格しない GPL-2 です。
これが g95 の開発にどのように影響するかはわかりません。現在の g95 を続行しますか? SGI のコンパイラをジャンプシップしてリターゲットし、代わりに RTL を生成しますか? （ライセンスの問題はこちら）。SGI にライセンスを GPL-1 に変更するよう説得しますか?
私たちは興味深い時代に生きています…
