組み込み関数の大規模な再編成を開始しました。現在、各組み込み関数には、チェック関数、単純化関数、および解決関数があります。解決関数は引数を見て、戻り値の型と種類を決定し、呼び出す内部ライブラリ サブルーチンも決定します。修正が完了し、すべてがコンパイルされましたが、まだテストしていません。
intrinsic.c を見て、大きすぎる (3500 行) ので、小さくする必要があると判断しました。当然行うべきことは、チェック関数を独自のファイルに分割することです。それらは現在約 1500 行を占めているため、これにより、すべてを扱いやすいチャンクに戻すことができます。解決関数とチェック関数のすべてのプロトタイプをそこに移動する必要があるため、simplify.h はintrinsic.h に名前が変更されると思います。
スティーブン ボッシャーは今朝、他の人々がこれをどのように処理しているかを指摘する手紙を私に送りました。pro64 コンパイラには、13,000 行の単一の C 初期化子を含む .h ファイルがあります。すべての Fortran 組み込み関数は、さまざまな方法で呼び出すことができます。たとえば、MATMUL には 349 のエントリがあることがわかります。
現実には、このファイルはおそらくスクリプトによって作成されたものですが、私たちのソリューションは非常にコンパクトで柔軟性があると思います。つまり、関数ごとに 1 つのエントリを持つテーブルです。関数が十分に奇妙である場合、正しい結果を与える関数への null 以外のポインターがあり、これはインターフェイスをチェックし、関数を単純化し、型解決を行います。
1月27日
なんてこった。Steve K. と Steven B から送られてきたバグの修正に午前中から午後中頃まで費やしました。小さな小さな問題がたくさん修正されています。また、Paul Brook は、パッチ内のコンポーネント タイプの解決とメールに関する問題を発見しました。キャサリンは、いくつかのバグ修正も行いました。
1月23日
キャサリンは、逆正接恒等式が壊れる極限で逆余弦が間違った値を返す問題を修正しました。
Steven は、式のランクが設定されていない問題を指摘し、expression_rank() が正しく機能するように修正しました。彼はまた g95 のプロファイリングを行い、g95 はモジュールのロードが非常に遅く、実行時間の約 1/4 がシンボルの真の名前の総当り検索に費やされていることを発見しました。現時点では真名はまったく索引付けされていないため、それらをすべて検索することが唯一の方法です。より大きなモジュール階層の中には、約 2 ～ 3,000 のシンボルが含まれているものもあるため、高速化が重要になってきています。
私の Pentium III/866 では、g95 は純粋な Fortran 77 コード (モジュールなし) で約 3700 行/秒でコンパイルされます。
