昨日の更新は少し遅れました — Sourceforge に問題がありました。内部の motd は、IRC の人々に問題があることについて何か言いました….
今日は g95 の時間があまりありません。算術変換を から に移動しexpr.cましたarith.c。これには 2 つの目的があります。外部からの GMP ライブラリへの呼び出しを取り除き、GMP の arith.c置き換えへの道を切り開きます。2 番目の目的は、コンパイラが独自により多くの演算を実行できるようにすることです。特に、評価できる必要がある組み込み関数を評価できるようにすることです。
たとえば、ABS() 組み込み関数を評価する場合、値をゼロと比較し、必要に応じて否定できる必要があります。比較と否定はすでに行われていますが、比較を可能にするには、値がゼロの式ノードを割り当てる何らかの方法が必要です。
6月26日
Niels Jensen は、タイプミスなどを修正するいくつかのマイナー パッチを送信しました。多くの表面的なクリーンアップが含まれているintrinsic.cのリビジョンを受け入れ g95_warning()、警告が適用される行が受け入れられるまでメッセージの表示を遅らせるための新しいスキームに取り組んでいます。これにより、ステートメントが拒否された場合に間違ったメッセージが表示されるのを防ぎます。
FSF から、著作権譲渡の状況を確認するために使用できるアカウントについて連絡がありました。もちろん、彼らは Kerberos を使用しているため、さらに別のソフトウェア パッケージをインストールする必要があります…
6月25日
式マッチャーの大幅な書き直し。これは実際に書かれた g95 の最も初期の部分の 1 つです。スキャンの仕組みが完成した後は、表情のマッチングに大きく依存しているように見えました。結局のところ、FORTRAN は FORmula TRANslation です。
このマッチャーは、字句解析器によって提供されたトークンのストリームを受け取り、それらを式ノードのツリーに組み込む単純な中置パーサーでした。根本的な問題は、このパーサーが標準で定められたすべての規則に従っていると確信できなかったことです。たとえば、次のようなものA+-Bは、ルールでは許可されていませんが、許可されていますA.EQ.-B。
とにかく、パーサーを修正するためのパッチが山積みされ続け、まだそこにある問題とそれらを見つける方法が明確ではありませんでした.
新しい式マッチャーは、g95 内の他のマッチャーと同じように機能します。何かに一致させようとし、それが機能しない場合は、別のものに一致させようとします。これにより、標準にあるように式を一致させるためのルールを実装することもでき、驚きを隠さずに、正しいことを行っているという自信が得られます。
この方法の欠点は (一般的に)、トークンのストリーム アプローチよりも遅いことです。これは、特定の構文状態が間違っていると判断された場合、トークン アプローチの方が早く元に戻すことができるためです。g95 のマッチング アプローチは、より大きな「トークン」を消費するため、より多くのバックアップが必要になります。
論文プロジェクトで実行すると、以前よりも遅くなったように感じますが、それでも許容範囲内です。これは g77 (fortran を解析するだけでなく、多くのことを行っている) よりも高速ですが、コンパイル時間が同程度である限り、問題ありません。
Tobi と Niels から送られてきたパッチを適用して、多くの小さな問題を修正しました。私のメールボックスは、久しぶりに居眠り文字未満になりました。私の次の優先事項は、キャサリンを元に戻すことです。何度パッチを当てても…
