CYCLE、EXIT、DO ステートメントのマッチャーを実装しました。parse_do_block() で開始。ここで注意が必要なのは、次のような非ブロック ENDDO を正しく結び付ける方法です。
DO 10、i=1、5
DO 10、j=1、6
…
10 続ける
何が起こらなければならないかというと、 parse_executable() がラベル付きのステートメントを監視する必要があるということです。ラベル付けされたステートメントが表示されると、それがブロックを正しく終了するか正しく終了するかを確認します。正しい場合、呼び出し元に ST_ENDDO を返します。これは parse_do_block() でなければなりません。
同様に、parse_do_block() は、ステートメントがさらに別の DO ブロックを終了するかどうかを確認します。もしそうなら、parse_executable() でなければならない呼び出し元に再び戻ります。
4月3日
世界のどこかで、GOTO ステートメントが別のコンパイラに実装されると、Edsger Dijkstra が苦痛に叫びます…
ステートメント ラベルを照合する g95_match_label() を追加しました。ラベルに一致する ‘%l’ コードを g95_match() に追加しました。ストレート GOTO と計算された GOTO の両方が解析され、明らかに機能します。計算された GOTO は、実際には SELECT CASE ブロックとして g95_code 構造体に配置されます。これは、まもなく g95 を支配するテーマの 2 番目のインスタンスです。単一のステートメントは、かなり大きなコードに拡張される可能性があります。これは、各ステートメントが小さなコードに変換される C のような言語とは対照的です。
また、ループ制御仕様、つまり SYMBOL = START, END [, STEP] に一致する g95_match_loop_control() を作成しました。これは、DO ループや READ ステートメント、WRITE ステートメントで使用されます。まだテストする機会がありません。
次のステップは、組み込みの fortran 95 ステートメントに関する作業を継続することだと思います。これが完了すると、オブジェクト コードが生成されなくても、実際のコードで g95 を実行して正しく解析できるはずです。残りのステートメントの大部分は I/O ステートメントであり、すべてオプションのパラメーターを持つ CALL ステートメントを思い起こさせるかなり単純な構文を持っています。
その後、ALLOCATE、DEALLOCATE、NULLIFY の 3 つの割り当てステートメントがあり、構造は単純です。最後に、DO ループです。
また、バイナリの安定版を Web ページに置いて、人々が遊べるようにするというアイデアも考えていました。現在、メインの開発マシンは glibc2 を搭載した x86 Linux です。コメントはありますか？
G95 は現在 12,000 行の長さです。
4月2日
SELECT CASE パーサーが完成しました。重複するケース値を検出するためのツリー構造は、まだ実行する必要があります。うまくいくようです。STOP ステートメントと CONTINUE ステートメントのマッチャーも配置します。これらも同様に機能するようです。DO ステートメントを読みました。もっと醜いものになるだろう。
コード構造にステートメント番号を付けるコードも追加されました。
