言語理論とコンパイラ

第十一回: エラー処理、意味解析と中間表現

2012 年 6 月 29 日

http://www.sw.it.aoyama.ac.jp/2012/Compiler/lecture11.html

Martin J. Dürst

© 2005-12 Martin J. Dürst 青山学院大学

今日の予定

• 前回のまとめ
• これからの予定
• bison の宿題のヒント
• 構文解析のエラー処理
• 中間表現: 構文木と名前表
• 意味解析

前回のまとめ

• 演算子の優先度と結合規則が文法の書き換え規則の形で決まる
• 導出の順番には最左導出と最右導出が存在
  
  • 再帰的下向き構文解析は最左導出の順
  • 上向き構文解析は最右導出の逆順
• LALR 構文解析は shift/reduce/goto/accept で動作
  • shift はトークンと状態をスタックに積む
  • reduce はスタックの再上の複数のトークンや非終端記号をまとめる
• その動作を bison -v で作成される .output ファイルと #define YYDEBUG 1 で出力される情報で確認可能

これからの予定

• 7月6日: コード生成
• 7月13日: 最適化
• 7月20日: 実行環境、仮想計算機、ゴミ集め、動的コンパイラ
• 7 月 23 日~ 8 月 4 日: 期末試験
• 2010 年の試験
• 2009 年の試験
• 2008 年の試験
• 2007 年の試験
• 2006 年の試験
• 2005 年の試験

宿題: 複素数の電卓

提出: 再来週の木曜日 (7月5日) 19 時 00 分、O 棟 529号室の前

簡単な電卓を複素数の電卓に拡張

複素数の表し方は 5i で虚数を表し、[実部,虚部] で複素数を表す

[] 内には実数演算は可能が 5i などが不可能に文法を設計

complex.lex と complex.y を提出

A4 両面印刷、表紙なし、左上ホチキス止め、名前と学生番号をコメントに記述

来週質問が可能なので、よく準備し、おおくの質問ができるようにすること!

入力の例: test.in

宿題のヒント

• 確認のためのファイル: test.check
• calc などからスタート、しかしファイル名を変更 (makefile 内も)
• .y で追加のトークンを定義
• .lex で追加のトークンを認識
• YYSTYPE は有理数が表現できる構造体; 両方の入力ファイルに同様に定義
• shift/reduce conflict や reduce/reduce conflict がありうる
  • .output ファイルを見て検討
  • 実際の入力で試してみる
• 文法を少しづつ拡張しながら念入りにテスト
• テストファイルを作成、文法を拡張するたびにテストを追加
• 関心の項目 (優先順位、結合規則) を仕分けるテストを作成
• テストの結果を取っておいて、次のテストの結果と比較
• [] 内の制限の扱い: [] 内と [] 外を別の非終端記号で扱う

構文エラー処理

• エラー処理の難しさ
• エラー処理の要点
• エラー処理の技法

エラー処理の難しさ

• プログラムの記述を短くするには「余計」な記号の削減が望ましい
• 一つの正しいプログラムに対してエラーのプログラムは多数存在
• 人間にとって間違いやすいものと間違いにくいものをプログラムで区別するのが困難
• 構文解析には理論があるが、エラー処理には理論が少ない

エラー処理の要点

• 分かりやすいエラーメッセージを出す
• 一つだけではなく、複数のエラーを見つける
• 二次エラーをできるだけ出さない
• 正しいプログラムの処理を遅くさせない
• コンパイラを複雑化しない

エラー処理の技法

• 文法に合ったトークンを見つけるまでにトークンを捨てる (panic mode)
• 少数のトークンを追加又は入れ替え
• 文法にエラーをキャッチする規則を追加 (error production)
• 入力に一番近い正しいプログラムを探す

bison でのエラー処理

• error トークンを含む規則を文法に追加可能
  例:

  statement: ... SEMICOLON { ... }
           | error SEMICOLON { yyerror("Statement error.\n"); yyerrok; }

• エラーが起こると、bison が一番近い error トークンの含まれる規則までエラー前のトークンや非終端記号を無視
• その規則の error トークンの後に来る入力も無視

コンパイラの段階

字句解析 (lexical analysis)

構文解析 (parsing; syntax analysis)

意味解析 (semantic analysis)

最適化 (optimization)

コード生成 (code generation)

中間表現: 名前表

(symbol table)

• 提供する機能:
  • 名前の検索
  • 名前の登録と取り消し
  • 名前についてのデータの管理
• 要点:
  • 使うことが多く、名前の数が多いので効率が大切
  • 同じ名前が複数ある可能性があるので区別が必要

名前表が扱うデータ

• 名前の種類 (変数、関数、型など)
• 定義か宣言だけか
• 変数、関数などの型
• 名前が有効な領域 (例えば関数、ブロック)
• 変数などの場合: 大きさ (必要なメモリ)
• 関数、変数などの (相対) アドレス

中間表現: 構文木

簡単なプログラム言語と簡単なマシーン・アーキテクチャの場合 (例えば Pascal からスタック・マシーン) には構文解析しながらコード生成を行う (構文木を生成しない) こともある

構文木の生成: 構文規則ごとの処理で生成。例:

expression: expression '+' term { $$ = $1 + $3; }

を次に変える:

expression: expression '+' term
            { $$ = newnode(PLUS, $1, $3); }

(YYSTYPE も変更)

構文木では二分木が多いが、関数の引数などに特別な措置が必要

意味解析

(semantic analysis)

• 主に型の処理:
  • 型が合うかどうかのチェック
  • 必要に応じて型の自動変換 (構文木に新たなノードの追加)
  • C などでは比較的簡単
  • オブジェクト指向言語の場合、もうちょっと複雑 (継承)
  • 型推論 (type inference) を行う言語もある (例: Haskell)
• 構文木の生成の時に行うか後で行うか

型の等価

(type equivalence)

型が同じかどうか複数の定義がある:

• 同じ名前の型が同じ (簡単だが利用者にとって不便)
• 同じ中身の型が同じ (複雑)
• オブジェクト指向などでは様々な考え方

C の例: type-equivalence.c (コンパイル可能か)