C＃for .NET（パート2 +ボーナス）でクールな教育言語のコンパイラを開発しています

こんにちは、Habrahabr！

はじめに

この記事では、約束したとおり、 この記事で始まったCool言語用のコンパイラーの開発の説明を続けます。



風水での編集プロセスにはいくつかの段階が含まれていることを思い出させてください。これらの段階は下の図に示されています。 コンパイラには3つのステージのみが含まれており、それらは右側の同じ図に示されています。











字句解析器および構文解析器は、最初の記事で言及されました。



セマンティックアナライザーの主なタスクは、ソースプログラムで言語の定義とのセマンティクスの整合性をチェックすることです。 これは主に型チェック 、つまり コンパイラが、各演算子に適切なタイプのオペランドがあるかどうかを確認するとき。



ソースコードの中間表現を生成するには、中間コード生成が必要です。中間表現は、 簡単に生成され、ターゲットマシン言語に簡単に変換される必要があります 。 このような表現として、たとえば、 3つのアドレスコードが使用されます。



マシンに依存しないコード最適化のフェーズは、中間コードを改善するために使用されます（より速く、よりまれに、より短い）。



コード生成とは、中間表現をアセンブラーまたは仮想マシンの一連の命令に直接変換することです。



マシン依存の最適化フェーズは、コードを最適化するためにターゲットマシン（たとえばSSE ）からの特別な命令を使用することを除いて、 マシンに依存しない最適化に似ています。 私たちの場合、これらの責任はCLRによって引き受けられることは明らかです。



図からわかるように、1つの段階で、左側の図から最大3つの段階を組み合わせました。 これは、 System.Reflection.Emitツールを使用して中間コードを生成できないこと（変更できないCIL命令のシーケンスが生成されるため）、および全体としての考えの悪いアーキテクチャによって説明されています。

建築

うわー、どこから始めればいいのかわかりません！

コードジェネレーターの手順を説明します。

1. クラス定義
2. 関数とフィールドの定義
3. コンストラクターと関数コードの生成

クラス定義

クールなソースコードはクラスのコレクションであることが知られています。 当然、 エントリポイントが存在する必要があります。存在しない場合、何も実行されません。

したがって、エントリ関数はMainクラスのメイン関数です。 クラスと関数の両方を手動で登録する必要があります。 しかし、これについては後で詳しく説明します。



System.Reflection.Emitには、動的アセンブリの構築とCILコードの生成に使用される特別なクラスAssemblyBuilderとModuleBuilderがあります。

クラスの説明を宣言するには、メソッドを使用します

TypeBuilder ModuleBuilder.DefineType(string className, TypeAttributes attr, Type parent)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

classNameはクラスの名前、 attrはその属性、 parentは親（ある場合）です。

TypeBuilderは動的な型で、コードを生成するときに使用されます（たとえば、new演算子用）。



そのため、この段階では、下図に示すように、パーサーから取得した構文ツリーでクラスタイプのノードがバイパスされ、ソースコード内のすべてのクラスが上記の方法を使用して決定されます。



言語のオプションの文字は黄色で表示されます（親クラスの名前です。親がない場合、クラスはObjectを継承します）。



この段階では、クラス定義のみが作成され、その中の関数とフィールドの説明はありません。 関数とフィールドをすぐに説明すると、クラスが定義されていないというエラーが発生する場合がありますが、それについては後で説明します。



また、クラスを定義する前に、ソースコード内の説明を正しい順序で並べ替えることをお勧めします（たとえば、Aを継承するクラスBの説明があり、次にクラスAの説明があります）。 しかし、残念ながらこれは実装されていないため、すべてのクラスは使用される順序で記述する必要があります。



したがって、この段階で辞書が受信されます

 Dictionary<string, TypeBuilder> ClassBuilders_;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、キーはクラスの名前であり、値はそのビルダーです。



結論として、すべてのコードを生成した後、CreateTypeメソッドを使用して動的型を確定する必要があります（これはFinalAllClasses関数で行われます）。

関数とフィールドの定義

クラスを定義した後、各クラスで、さらに使用するためにその関数とメソッドを決定する必要があります。 これはメソッドを使用して行われます。

 public FieldBuilder DefineField(string fieldName, Type type, FieldAttributes attributes)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 public MethodBuilder DefineMethod(string name, MethodAttributes attributes, Type returnType, Type[] parameterTypes);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それに応じて。



この段階の終わりに、二次元の辞書がいっぱいになります

 protected Dictionary<string, Dictionary<string, FieldObjectDef>> Fields_; protected Dictionary<string, Dictionary<string, MethodDef>> Functions_;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の次元の辞書キーはクラスの名前で、2番目は関数またはフィールドの名前です。 値はそれぞれ関数記述子またはフィールドです（これらのクラスについては後ほど説明します）。



ソースコード内の関数とフィールドの説明を並べ替える問題は、クラスを定義するときのように、ここにはありません。 クラス定義の段階で、他のクラスに関する情報が遺伝を決定するために使用され、DefineType関数で直接使用されるためです。 ただし、関数を定義するために他の関数に関する情報は必要ないため（ここではコード生成は行われません）、他の関数へのリンクは必要ありません。 これは、関数とフィールドの定義を任意の順序で生成できることを意味します。

コンストラクターと関数コードの生成

そして、ここで最も興味深いことになりました。 ここでは、すべてのクラスの関数本体とコンストラクターの直接再帰的なトラバーサルが発生します。



したがって、前の段階から、すべてのクラスのすべてのメソッド記述子（MethodBuilder）の辞書が取得されました。

メソッドにCILステートメントを追加するには、最初に使用して特別なILGeneratorオブジェクトを取得する必要があります

var ilGenerator = methodBuilder.GetILGenerator()



、このジェネレーターでEmitメソッドを使用します。

Emitメソッドには多くの形式があります。

 void Emit(OpCode opcode); void Emit(OpCode opcode, int arg); void Emit(OpCode opcode, double arg); void Emit(OpCode opcode, ConstructorInfo con); void Emit(OpCode opcode, LocalBuilder local); void Emit(OpCode opcode, FieldInfo field); void Emit(OpCode opcode, MethodInfo meth); void Emit(OpCode opcode, Type cls);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OpCodeは、仮想.NETマシン命令です。 説明付きの適切な手順のリストをここに示します 。

そして、2番目の引数（常に存在するとは限りません）は、前の2つの段階で取得されたクラスまたはメソッドの「ビルダー」または記述子です。



現在の関数と現在のクラスは、それぞれ、コードが現在生成されている関数とクラスです（構文ツリーを走査するとき）。



最初に、関数引数、ローカル変数、一時ローカル変数、およびクラスフィールドを記述するためにコードジェネレーターで導入したクラスについて説明します。 基本クラスはObjectDefであり、対応するオブジェクトをロードおよびリリースする抽象メソッドLoad（）、Remove（）が含まれます。

• FieldObjectDef-任意のクラスのフィールドを記述するために使用されます（クールフィールド-これは機能です）。 現在のクラスの関数およびコンストラクターのコードを生成する場合、フィールドの説明の配列が使用されます。これについては上記で説明しました。
• LocalObjectDef-現在の関数またはコンストラクターの本体内のすべてのローカル変数を記述するために使用されます（Coolでは、ローカル変数はletステートメントを使用して宣言されます）。
• ValueObjectDef-値によって送信されるデータを保存するための一種のローカル変数。 Coolでは、そのようなクラスはInt、String、Boolです。
• ArgObjectDefは、現在の関数の引数です。 引数の番号、名前、およびタイプが含まれます。

お気づきかもしれませんが、Coolでは、すべての結果は表現です。 また、各コンストラクターと各関数内には、 exprが 1つだけあります。 これがコードジェネレーターの主要なポイントであり、この構造を処理するためにEmitExpression（ITree expressionNode）関数が導入されました。 コードは次のとおりです（一部の部分をマーク付きの楕円に置き換えて省略しました）。

 ObjectDef result; switch (expressionNode.Type) { case CoolGrammarLexer.ASSIGN: result = EmitAssignOperation(expressionNode); break; //  ... case CoolGrammarLexer.EQUAL: result = EmitEqualOperation(expressionNode); break; case CoolGrammarLexer.PLUS: case CoolGrammarLexer.MINUS: case CoolGrammarLexer.MULT: case CoolGrammarLexer.DIV: result = EmitArithmeticOperation(expressionNode); break; //... case CoolGrammarLexer.Term: if (expressionNode.ChildCount == 1) result = EmitExpression(expressionNode.GetChild(0)); else result = EmitExplicitInvoke(expressionNode); break; case CoolGrammarLexer.ImplicitInvoke: result = EmitInplicitInvoke(expressionNode); break; case CoolGrammarLexer.IF: result = EmitIfBranch(expressionNode); break; case CoolGrammarLexer.Exprs: for (int i = 0; i < expressionNode.ChildCount - 1; i++) { var objectDef = EmitExpression(expressionNode.GetChild(i)); objectDef.Remove(); } result = EmitExpression(expressionNode.GetChild(expressionNode.ChildCount - 1)); break; //... case CoolGrammarLexer.INTEGER: result = EmitInteger(expressionNode); break; } return result;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ツリーノード（expressionNode）のタイプに応じて、この演算子の命令を生成する長いケースから関数が呼び出されます。



生成された関数で結果を返すには、式コードの生成後に単純なOpCodes.Ret命令を使用します（関数がMainなどの何も返さない場合、スタックがオーバーフローしないように、Retの前にOpCodes.Popを追加します）。



エントリポイントを決定するには、 AssemblyBuilderで定義されているSetEntryPointメソッド（MethodInfo entryMethod） が使用されます。 また、 STAThreadAttribute属性は、アプリケーションが単一のスレッドで実行されていることを示すエントリポイントメソッドに設定する必要があります。 関数とエントリポイントを定義するコードは、DefineFunctionにあります。



質問 ：これらのような構造のコードを生成する方法：

math：数学←新しい数学。 （何らかの式のフィールドを割り当てる、ここでは新しい数学）。



回答 ：まず最初に、C＃コンパイラー、したがってコンパイラーがその場で計算を生成しないことを理解する必要があります-これは不可能です。 つまり 右側の式はデフォルトのコンストラクターで評価されると言いたいです。

そして、式コード（ここでは新しい数学）が生成された後、命令OpCodes.StfldまたはOpCodes.Stsfldが 、それぞれ非静的フィールドおよび静的フィールドのこのコンストラクターの本体に追加されます。

いくつかのCIL命令と設計の説明

CILはスタック言語です。つまり、すべての操作はスタックを使用して実行されます。 たとえば、Mathクラスからフィボナッチ数を計算する関数呼び出しは、次のようにエンコードされます。

 ldsfld class Math Main::math ldsfld int32 Main::i callvirt instance int32 Math::fibonacci(int32) stloc.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、最初に数学インスタンスハンドルがスタックにロードされ、次に渡されたint型の引数がロードされます。 その後、 OpCodes.callvirt命令を使用してfibonacci関数が呼び出されます（クラスの内部関数を呼び出すときに通常のOpCodes.call命令が使用されるため、クラス記述子を渡す必要はありません）。 最後のstloc.0ステートメントは、戻り値をローカル変数の番号0に格納します。

さて、上記に従って、関数の最初の引数は、明示的な形式の引数がなくても、呼び出されるクラスのインスタンス（this）へのポインターであることに注意してください。



CILのより詳細な説明は、たとえば、 Wikipediaにあります。

、しかしReflection.Emitを使用していくつかの構文構造をコーディングする方法を説明した方が良いでしょう。

算術演算と比較演算

これらの操作は単純にエンコードされます-最初にスタックにプッシュされます

オペランド、次にオペレーションコード：算術演算の場合、これらはOpCodes.Add、OpCodes.Sub、OpCodes.Mul、OpCodes.Divであり、比較演算の場合、 OpCodes.Ceq、OpCodes.Clt、OpCodes.Cgtです。



CILには、「以下」または「以上」の比較のための命令がないため、このような比較を生成するために、1つではなく3つの命令が使用されます（ここで、「<=」は「not>」と同等です）。

 OpCodes.Cgt OpCodes.Ldc_I4_0 OpCodes.Ceq
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OpCodes.Ceqは、スタック上の2つの要素を比較し、等しい場合は1を返し、等しくない場合は0を返します。

構築する場合

算術演算のコーディングと比較すると、この命令のコーディングには困難があります。これは、条件付きジャンプと無条件ジャンプのラベルに何らかの方法でラベルを付ける必要があるという事実にあります。 ただし、これは簡単に行えます。 DefineLabelメソッドを使用して、ILGeneratorでラベルを作成します。その後、Labelメソッドを使用して、MarkLabelメソッドを使用してコードをマークする必要があります。 これらのラベルは、条件付きおよび無条件の分岐命令をエンコードするために使用されます。 したがって、 OpCodes.Brfalseは、スタックの最上部の値がゼロに等しいときに発生する条件付き遷移です。 OpCodes.Brは無条件の移行です。 明確にするために、コードを示しました。

 protected ObjectDef EmitIfBranch(ITree expressionNode) { var checkObjectDef = EmitExpression(expressionNode.GetChild(0)); checkObjectDef.Load(); checkObjectDef.Remove(); var exitLabel = CurrentILGenerator_.DefineLabel(); var elseLabel = CurrentILGenerator_.DefineLabel(); CurrentILGenerator_.Emit(OpCodes.Brfalse, elseLabel); var ifObjectDef = EmitExpression(expressionNode.GetChild(1)); ifObjectDef.Load(); ifObjectDef.Remove(); CurrentILGenerator_.Emit(OpCodes.Br, exitLabel); CurrentILGenerator_.MarkLabel(elseLabel); var elseObjectDef = EmitExpression(expressionNode.GetChild(2)); elseObjectDef.Load(); elseObjectDef.Remove(); CurrentILGenerator_.MarkLabel(exitLabel); return LocalObjectDef.AllocateLocal(GetMostNearestAncestor(ifObjectDef.Type, elseObjectDef.Type)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構築しながら

この設計はIfによく似ています。 このデザインの本体の中で、常にPopを実行する必要があることを忘れないでください。 内部式が評価され、その結果は使用されません。 （Coolでは、このステートメントは常にvoidを返します）。

演算子「@」および「Case」

@演算子は基本的にC＃コードの式（a as B）.methodNameに一致し、Caseステートメントは動的型チェックを使用し、式a is B in C＃に一致します。

残念ながら、これらの演算子は実装されていません。

ただし、特定の型へのキャストはcastclass <class>ステートメントを使用して実装されていると言えます （メソッドへのキャストとメソッドの呼び出しは、 constrainedを使用してすぐに実装されます。<thisType> [prefix] ）

また、動的な型チェックはisinst <class>ステートメントを使用して実装されます。

トークンID処理

ツリーノードタイプがIdタイプに対応する場合、次のアクションが実行されます（ EmitIdValue関数で）。

1. ローカル変数での識別子検索（見つからない場合）
2. 関数の引数で識別子を検索し、見つからない場合は、
3. 現在のクラスのフィールドで識別子を検索し、見つからない場合は、
4. Idが定義されていないエラーを生成します

このセクションでは、CIL命令と、複雑であると思われる構文構造のコード生成について説明しました。 他のすべてのCILの手順については、Wikiページを参照できます。このページへのリンクは、トピックの最後にあります。 また、ソースコードでコード生成の詳細を確認できます。

エラー処理

コンパイラのエラーは異なります： 黒、白、赤の 字句 、 構文 、 セマンティック 、および一般 。



エラー番号、コード内の位置（行と列）、エラーの種類、およびその説明を含む抽象クラスCompilerErrorがそれらすべてに対して作成されました。



字句エラーと構文エラーを制御することは不可能です（少なくともこのプロジェクトでは、レクサーとパーサーのレベルでエラーから回復することをANTLRで処理しませんでした）。 ここでは、例外が単純にキャッチされ、対応するエラーインスタンスが作成されます。 これらはすべてCoolCompier.csファイルで確認できます。



ただし、セマンティックエラーのチェック（主に型チェック）は、「emit」のすべての機能に実装されています。 型チェックは簡単な方法で実装されます。 それにもかかわらず、このアプローチにより、1つのパスで複数のセマンティックエラーの認識を実現できます。 以下に例を示します：算術演算、エラーが検出された場合、構文ツリーは引き続き走査します：

 protected ObjectDef EmitArithmeticOperation(ITree expressionNode) { var returnObject1 = EmitExpression(expressionNode.GetChild(0)); var returnObject2 = EmitExpression(expressionNode.GetChild(1)); if (returnObject1.Type != IntegerType || returnObject1.Type != returnObject2.Type) CompilerErrors.Add(new ArithmeticOperatorError( returnObject1.Type, returnObject2.Type, CompilerErrors.Count, expressionNode.Line, expressionNode.GetChild(1).CharPositionInLine, expressionNode.GetChild(0).CharPositionInLine)); ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、一般的な種類のエラーには、「ファイルが別のプロセスでビジーです」、「エントリポイントが見つかりませんでした」などのエラーがあります。それらについて話すのは特に面白くありません。

インターフェース

構文の強調表示

私が言ったように、コードを操作するためのコンポーネントとして、WPFでAvalonEditを使用しました 。



構文を強調するために、拡張子.xshdを持つ特別なファイルが使用されます。これは、さまざまな単語や規則のフォントスタイルを記述しています。



たとえば、コメントは次のように示されます。

 <Span color="Comment" begin="--" /> <Span color="Comment" multiline="true" begin="\(\*" end="\*\)" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなキーワード：

 <Color name="Keywords" foreground="Blue" /> ... <Keywords color="Keywords"> <Word>classWord> <Word>elseWord> <Word>falseWord> ... Keywords>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、どの文字シーケンスが数字または文字列であるか、およびそれらを強調表示する方法を決定するために必要なルールもあります。

 <Rule foreground="DarkBlue"> \b0[xX][0-9a-fA-F]+ # hex number |\b ( \d+(\.[0-9]+)? #number with optional floating point | \.[0-9]+ #or just starting with floating point ) ([eE][+-]?[0-9]+)? # optional exponent Rule>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のすべての強調表示ルールは、ファイルCoolHighlighting.xshdにあります。

折りたたみと自動補完

このエディターではブロックの折りたたみと展開が可能で、 CoolFoldingStrategy.csに実装されています 。 コードは私のものではないので、コメントすることは控えます。 彼のおかげで、中括弧の間にあるすべてのものを最小化または拡張できるとしか言えません。 ループにはこのような機会はないはずなので、これはあまり正しくないようです。



また、このコンポーネントを使用すると自動補完を実行できますが、コード生成に関係なくセマンティックツリーを生成できる別のアーキテクチャを最初から実行する必要があったため、実行しませんでした。



最後に、インターフェイスの観点から、見つかったエラーをコード行に関連付ける方法について説明します。 以下に示すコードでは、キャリッジがスクロールされ、特定のエラーが発生した場所にキャリッジが転送されます。

 tbEditor.ScrollTo((int)compilerError.Line, (int)compilerError.ColumnStart); int offset = tbEditor.Document.GetOffset((int)compilerError.Line, (int)compilerError.ColumnStart); tbEditor.Select(offset, 0); tbEditor.Focus();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

tbEditor-エディターコンポーネントのインスタンス。

compilerError-エラー（説明は前のセクションにあります）;



そしてもちろん、このセクションは、コンパイラ自体のスクリーンなしでは完全ではありません。







コードエディタは左上にあり、ログとエラーのリストは左下にあります。 右側には、コードをコンパイルするためのボタンがあります（F5を押してコンパイルして実行することも、F6を押してコンパイルすることもできます）。

明確にするために、プログラムはトークンのリストと構文ツリー（右側）を表示します。 トークンまたは構文構造をダブルクリックすると、キャリッジがスクロールされ、キャリッジが適切な場所に移動します。

さらなるアーキテクチャの改善

現在の知識と十分なモチベーションで再びCool言語のコンパイラを書き始めた場合、おそらく2つのコンパイル段階-セマンティックツリーの構築と3または4アドレスの中間コードの生成-を選択するでしょう。



セマンティックツリーは、既に述べたように、コード生成の前にリアルタイムでセマンティックエラーの自動置換とチェックを実現します。



3アドレスの中間コードを使用すると、現在のアプローチでは適用できない最適化手法を適用できます。 たとえば、この種のコマンドの畳み込みと他の最適化：

stloc.0

ldloc.0

ソースの説明（ボーナス）

2011年にMSTUで開催された「Designing Compilers」コースで持っていたすべてのラボを、 コードごとのコレクションにまとめることにしました。 N.E.バウマン（11番目のオプション）。 彼らは誰かに役立つと思います。



すべての実験室の説明：

1. タスク1.文法を分割します。 このラボでは、文法分割アルゴリズムを実装しています 。 手順の詳細な説明と順序は、102ページの第2巻の教科書「Aho A.、Ulman J.解析、翻訳、およびコンパイルの理論」にあります。 ）文法の文字。
   
   当時はまだLINQで遊んでいたことを覚えています。 したがって、これらの関数のコードは、効率的で美しいとはほど遠いものの、かなり短いことが判明しました。 :)
   
   
   
   
2. タスク2.通常の言語のチェーンの認識。 ここでは、次のサブタスクが実装されています。
   
   
   1. 通常の係数を使用した標準システムのソリューション。
      
      説明 ：正規表現は左側の文法から作成する必要があります。 つまり 通常の係数（SRS）を使用してシステムを「解決」します。 係数は終端であり、未知数は非終端です。
      
      たとえば、そのような文法の場合：
      
      
      
      Σ = {0, 1}

N = {S, A, B}

P = {S → 0∙A|1∙S|λ, A → 0∙B|1∙A, B → 0∙S|1∙B}

S = S
      
      
      
      
      
      次の式が判明します（小さなエラーがありますが、ポイントはありません）。
      
      
      
      S = 1*+1*∙0∙1*∙0∙1*∙0∙1*+1*∙0∙1*∙0∙(0∙1*∙0∙1*∙0)*∙0∙1*

A = 1*∙0∙1*∙0∙1*+1*∙0∙(0∙1*∙0∙1*∙0)*∙0∙1*

B = 1*∙0∙1*+(0∙1*∙0∙1*∙0)*∙0∙1*


      
      
      
      
      
      
      
      
      
      このラボで作業しているとき、代数「+」、「*」、「/」の通常の操作を、正規表現のコンテキストで対応する「or」、「concatenation」、「iteration」の操作にオーバーロードすることで、SRKメソッドを解くことができることに気付きましたガウス、通常のSLAEを解決するときも！ 唯一のことは、最適化のために何かが変更されたことです。
      
      
      
      ただし、これらの操作をオーバーロードすることも重要なタスクです。これらは数字ではありませんが、ここの行とルールは異なるためです：連結する場合、行を「接着」する必要があり、「or」操作では同じ形式のままにする必要があり、ゼロは空のセットです（Ø）単位はラムダ（λ）です。 したがって、0または1による乗算または加算の場合、これらの行を最適化する必要もあります。最適化しないと、すぐに「膨張」します。
      
      
   2. 正規係数を使用した標準の連立方程式の解である正規表現を使用して、NFA（非決定性有限オートマトン）を構築します。
   3. NCAをシミュレートすることを決定しました。 要するに-これは修正された深さ検索です
   
   
   
3. 問題3. Coca-Yanger-Kasamiアルゴリズム
   
   ここでは、Kok-Yanger-Kasamiアルゴリズムを使用して解析を実装する必要がありました
   
   
   
   このアルゴリズムでは、文法をChomskyの標準形式で指定する必要がありますが、これはもちろん不便です。字句解析器の欠如も不便さを引き起こすので、パーサーがそれらを認識するように、すべてのトークンはスペースで区切られなければなりません。
   
   
   
   この実習ラボの結果は、解析テーブルと、入力された文字列が特定の文法に属するかどうかの実際の定義です。
   
   
   
   
4. タスク4.再帰降下の方法
   
   ここでは、再帰降下の方法を実装する必要がありました。同じ原則について、すべてのLL（*）コードジェネレーター（たとえば、ANTLR）はコードを生成します。ここでのみ、すべてが手動で実装されます。明確にするために、解析ツリーもここに構築されます。
   
   
   
   
   
   
   
   
5. 5-8. Cool
   
   ---- Cool .NET, .
   
   
   
   , , Cool, , , :
   
   
   • Example1.cool — ( , , ).
   • BinaryTree.cool — , — (, , ).
6. , ( .pdf):
   
   
   1. Evaluating Simple C Expressions — - .
   2. iFlop — iFlop .

一部のラボでは、Microsoft.GLEEグラフのレンダリングに素晴らしい、しかし閉鎖された有料のライブラリを使用していることに注意してください。この記事から判断すると、このライブラリではいくつかの巧妙なアルゴリズムとヒューリスティックが使用され、レンダリングされたグラフが人によって描かれ、ノードサイズが最大で最小の領域を占有しているように見えます。 （ハブでほとんど誰も言及していないのは奇妙です）。

利点は、このライブラリの使用が簡単なことです。たとえば、ノード間のエッジの追加は、ソースが1つのノードの名前で、ターゲットが別のノードの名前である関数を使用して実行さEdge AddEdge(string source, string target)



れます。

つまりノード間に通信を追加するために、最初にノードを作成する必要はありません。



関数を使用Edge AddNode(string nodeId)





すると、Edgeオブジェクトのインスタンスが返され、属性（テキストの色、ノードの色、インデントなど）を変更



できますが、私は何を考えても、私はMicrosoftのサポーターではありません。 ）



すべてのスキームを作成および編集するには、便利なオンラインサービスlucidchart.comを使用しました。

文学

私はこのトピックの著者に同意します。このテーマに関する多くの本を読む必要はありませんが、1冊で十分ですが十分です。

コンパイラをお勧めします。Principles、Technologies and Tools、2008、Alfred W. Aho、Monica S. Lam、Ravi Seti、Jeffrey D. Ullman。

また、私がよく使用するCIL指示のリストへのリンクも投稿します。

GitHubプロジェクト

それだけです！