|
4
|
1 \chapter{GearsOSのトランスコンパイラ}
|
|
|
2
|
|
|
3 GearsOSはCbCで実装を行う。
|
|
|
4 CbCはC言語よりアセンブラに近い言語であるため、 すべてを純粋なCbCで記述しようとすると記述量が膨大になってしまう。
|
|
|
5 またノーマルレベルの計算とメタレベルの計算を、全てプログラマが記述する必要が発生してしまう。
|
|
|
6 メタ計算では値の取り出しなどを行うが、 これはノーマルレベルのCodeGearのAPIが決まれば一意に決定される。
|
|
|
7 したがってノーマルレベルのみ記述すれば、 機械的にメタ部分の処理は概ね生成可能となる。
|
|
|
8 また、メタレベルのみ切り替えたいなどの状況が存在する。
|
|
|
9 ノーマルレベル、メタレベル共に同じコードの場合は記述の変更量が膨大であるが、 メタレベルの作成を分離するとこの問題は解消される。
|
|
|
10
|
|
|
11 GearsOSではメタレベルの処理の作成にPerlスクリプトを用いており、 ノーマルレベルで記述されたCbCから、 メタ部分を含むCbCへと変換する。
|
|
|
12 変換前のCbCをGearsCbCと呼ぶ。
|
|
2
|
13
|
|
8
|
14 \section{トランスコンパイラ}
|
|
|
15 プログラミング言語から実行可能ファイルやアセンブラを生成する処理系のことを、一般的にコンパイラと呼ぶ。
|
|
|
16 特定のプログラミング言語から別のプログラミング言語に変換するコンパイラのことを、 トランスコンパイラと呼ぶ。
|
|
|
17 トランスコンパイラとしてはJavaScriptを古い規格のJavaScriptに変換するBabel\cite{babel}がある。
|
|
|
18
|
|
|
19 またトランスコンパイラは、変換先の言語を拡張した言語の実装としても使われる。
|
|
|
20 JavaScriptに強い型制約をつけた拡張言語であるTypeScriptは、 TypeScriptから純粋なJavaScriptに変換を行うトランスコンパイラである。
|
|
|
21 すべてのTypeScriptのコードはJavaScriptにコンパイル可能である。
|
|
|
22 JavaScriptに静的型の機能を取り込みたい場合に使われる言語であり、 JavaScriptの上位の言語と言える。
|
|
|
23
|
|
|
24 GearsOSはCbCを拡張した言語となっている。
|
|
|
25 ただしこの拡張自体はCbCコンパイラであるgcc、 llvm/clangには搭載されていない。
|
|
|
26 その為GearsOSの拡張部分を、等価な純粋なCbCの記述に変換する必要がある。
|
|
|
27 現在のGearsOSでは、 CMakeによるコンパイル時にPerlで記述された\texttt{generate\_stub.pl}と\texttt{generate\_context.pl}の2種類のスクリプトで変換される。
|
|
|
28
|
|
12
|
29 \begin{itemize}
|
|
|
30 \item \texttt{generate\_stub.pl}
|
|
|
31 \begin{itemize}
|
|
|
32 \item 各CbCファイルごとに呼び出されるスクリプト
|
|
|
33 \item 対応するメタ計算を導入したCbCファイル(拡張子はc)に変換する
|
|
|
34 \end{itemize}
|
|
|
35 \item \texttt{generate\_context.pl}
|
|
|
36 \begin{itemize}
|
|
|
37 \item 生成したCbCファイルを解析し、使われているCodeGear、DataGearを確定する
|
|
|
38 \item これらの情報をもとにContext及びContext関係の初期化ルーチン、APIを作成する
|
|
|
39 \end{itemize}
|
|
|
40 \end{itemize}
|
|
|
41
|
|
|
42 これらのPerlスクリプトはプログラマが自分で動かすことはない。
|
|
|
43 GearsOSでプログラミングする際は、ビルドしたいプロジェクトをCMakeLists.txtに記述し、 移行はCMakeのビルドに移譲する。
|
|
|
44 CMakeはMakefileやNinja fileを生成し実際にビルドを行うのはmakeやninja-buildとなっている。
|
|
8
|
45
|
|
9
|
46 \section{GearsCbCのInterfaceの実装時の問題}
|
|
2
|
47
|
|
|
48 Interfaceとそれを実装するImplの型が決定すると、最低限満たすべきCodeGearのAPIは一意に決定する。
|
|
|
49 ここで満たすべきCodeGearは、Interfaceで定義したCodeGearと、 Impl側で定義した privateなCodeGearとなる。
|
|
|
50 例えばStack Interfaceの実装を考えると、各Implで\texttt{pop}, push, shift, isEmptyなどを実装する必要がある。
|
|
|
51
|
|
|
52 従来はプログラマが手作業でヘッダーファイルの定義を参照しながら\texttt{.cbc}ファイルを作成していた。
|
|
|
53 手作業での実装のため、 コンパイル時に次のような問題点が多発した。
|
|
|
54
|
|
|
55 \begin{itemize}
|
|
|
56 \item CodeGearの入力のフォーマットの不一致
|
|
|
57 \item Interfaceの実装のCodeGearの命名規則の不一致
|
|
|
58 \item 実装を忘れているCodeGearの発生
|
|
|
59 \end{itemize}
|
|
|
60
|
|
|
61
|
|
|
62 特にGearsOSの場合はPerlスクリプトによって純粋なCbCに一度変換されてからコンパイルが行われる。
|
|
|
63 実装の状況とトランスコンパイラの組み合わせによっては、 CbCコンパイラレベルでコンパイルエラーを発生させないケースがある。
|
|
|
64 この場合は実際に動作させながら、gdb, lldbなどのCデバッガを用いてデバッグをする必要がある。
|
|
|
65 またCbCコンパイラレベルで検知できても、すでに変換されたコード側でエラーが出てしまうので、トランスコンパイラの挙動をトレースしながらデバッグをする必要がある。
|
|
|
66 Interfaceの実装が不十分であることのエラーは、 GearsOSレベル、最低でもCbCコンパイラのレベルで完全に検知したい。
|
|
|
67
|
|
9
|
68 \section{Interfaceを満たすコード生成の他言語の対応状況}
|
|
2
|
69
|
|
|
70 Interfaceを機能として所持している言語の場合、これらはコンパイルレベルか実行時レベルで検知される。
|
|
|
71 例えばJavaの場合はInterfaceを満たしていない場合はコンパイルエラーになる。
|
|
|
72
|
|
|
73
|
|
|
74 InterfaceのAPIを完全に実装するのを促す仕組みとして、Interfceの定義からエディタやツールが満たすべき関数と引数の組を自動生成するツールがある。
|
|
6
|
75
|
|
|
76 Javaでは様々な手法でこのツールを実装している。
|
|
|
77 Microsoftが提唱しているIDEとプログラミング言語のコンパイラをつなぐプロトコルにLanguage Serverがある。
|
|
|
78 Language Serverはコーディング中のソースコードをコンパイラ自身でパースし、 型推論やエラーの内容などをIDE側に通知するプロトコルである。
|
|
|
79 主要なJavaのLanguage Serverの実装であるeclipse.jdt.ls\cite{eclipse.jdt.ls}では、 LanguageServerの機能として未実装のメソッドを検知する機能が実装されている。\cite{eclipse.jdt.pull322}
|
|
8
|
80 この機能を応用してvscode上から未実装のメソッドを特定し、 雛形を生成する機能がある。
|
|
|
81 他にもIntelliJ IDEなどの商用IDEでは、 IDEが独自に未実装のメソッドを検知、雛形を生成する機能を実装している。
|
|
6
|
82
|
|
|
83
|
|
2
|
84 golangの場合は主に\texttt{josharian/impl}\cite{golang_impl}が使われている。
|
|
6
|
85 これはインストールすると\texttt{impl}コマンドが使用可能になり、 実装したいInterfaceの型と、 Interfaceを実装するImplの型(レシーバ)を与えることで雛形が生成される。
|
|
2
|
86 主要なエディタであるvscodeのgolangの公式パッケージである\texttt{vscode-go}\cite{vscode-go}でも導入されており、 vscodeから呼び出すことが可能である。
|
|
6
|
87 vscode以外にもvimなどのエディタから呼び出すことや、 シェル上で呼び出して標準出力の結果を利用することが可能である。
|
|
2
|
88
|
|
9
|
89 \section{GearsOSでのInterfaceを満たすCbCの雛形生成}
|
|
|
90
|
|
2
|
91
|
|
4
|
92 GearsOSでも同様のプログラマ支援ツールを導入したい。
|
|
6
|
93 LanguageServerの導入も考えられるが、 今回の場合はC言語のLanguageServerをCbC用にまず改良し、 さらにGearsOS用に書き換える必要がある。
|
|
|
94 現状のGearsOSが持つシンタックスはCbCのシンタックスを拡張しているものではあるが、これはCbCコンパイラ側には組み込まれていない。
|
|
|
95 LanguageServerをGearsOSに対応する場合、 CbCコンパイラ側にGearsOSの拡張シンタックスを導入する必要がある。
|
|
|
96 CbCコンパイラ側への機能の実装は、 比較的難易度が高いと考えらる。
|
|
|
97 CbCコンパイラ側に手をつけず、 Interfaceの入出力の検査は既存のGearsOSのビルドシステム上に組み込みたい。
|
|
|
98
|
|
|
99 対してgolangの\texttt{impl}コマンドのように、 シェルから呼び出し標準出力に結果を書き込む形式も考えられる。
|
|
|
100 この場合は実装が比較的容易かつ、 コマンドを呼び出して標準出力の結果を使えるシェルやエディタなどの各プラットフォームで使用可能となる。
|
|
|
101 先行事例を参考に、コマンドを実行して雛形ファイルを生成するスクリプトをGearsOSに導入した。
|
|
4
|
102
|
|
|
103
|
|
2
|
104 Interfaceでは入力の引数がImplと揃っている必要があるが、 第一引数は実装自身のインスタンスがくる制約となっている。
|
|
4
|
105 実装自身の型は、Interface定義時には不定である。
|
|
|
106 その為、 GearsOSではInterfaceのAPIの宣言時にデフォルト型変数\texttt{Impl}を実装の型として利用する。
|
|
|
107 デフォルト型\texttt{Impl}を各実装の型に置換することで自動生成が可能となる。
|
|
6
|
108
|
|
|
109
|
|
|
110 実装すべきCodeGearはInterfaceとImpl側の型を見れば定義されている。
|
|
|
111 \texttt{\_\_code}で宣言されているものを逐次生成すればよいが、 継続として呼び出されるCodeGearは具体的な実装を持たない。
|
|
|
112 GearsOSで使われているInterfaceには概ね次の継続である\texttt{next}が登録されている。
|
|
|
113 \texttt{next}そのものはInterfaceを呼び出す際に、入力として与える。
|
|
|
114 その為各Interfaceに入力として与えられた\texttt{next}を保存する場所は存在するが、 nextそのものの独自実装は各Interfaceは所持しない。
|
|
|
115 したがってこれをInterfaceの実装側で明示的に実装することはできない。
|
|
|
116 雛形生成の際に、入力として与えられるCodeGearを生成してしまうと、プログラマに混乱をもたらしてしまう。
|
|
|
117
|
|
7
|
118 入力として与えられているCodeGearは、Interfaceに定義されているCodeGearの引数として表現されている。
|
|
|
119 コードに示す例では、\texttt{whenEmpty}は入力して与えられているCodeGearである。
|
|
|
120 雛形を生成する場合は、入力として与えられたCodeGearを除外して出力を行う。
|
|
10
|
121 順序はInterfaceをまず出力した後に、 Impl側を出力する。
|
|
7
|
122
|
|
|
123 雛形生成では他にコンストラクタの生成も行う。
|
|
9
|
124 GearsOSのInterfaceのコンストラクタは、 メモリの確保及び各変数の初期化を行う。
|
|
|
125 メモリ上に確保するのは主にInterfaceとImplのそれぞれが基本となっている。
|
|
|
126 Interfaceによっては別のDataGearを内包しているものがある。
|
|
|
127 その場合は別のDataGearの初期化もコンストラクタ内で行う必要があるが、 自動生成コマンドではそこまでの解析は行わない。
|
|
|
128
|
|
|
129
|
|
12
|
130 コンストラクタのメンバ変数はデフォルトでは変数は0、ポインタの場合はNULLで初期化するように生成する。
|
|
|
131 このスクリプトで生成されたコンストラクタを使う場合、 CbCファイルから該当する部分を削除すると、\texttt{generate\_stub.pl}内でも自動的に生成される。
|
|
|
132 自動生成機能を作成すると1CbCファイルあたりの記述量が減る利点がある。
|
|
|
133
|
|
|
134 明示的にコンストラクタが書かれていた場合は、 Perlスクリプト内での自動生成は実行しないように実装した。
|
|
10
|
135 これはオブジェクト指向言語のオーバーライドに相当する機能と言える。
|
|
12
|
136 現状のGearsOSで使われているコンストラクタは、 基本は\texttt{struct Context*}型の変数のみを引数で要求している。
|
|
|
137 しかしオブジェクトを識別するためにIDを実装側に埋め込みたい場合など、 コンストラクタ経由で値を代入したいケースが存在する。
|
|
|
138 この場合はコンストラクタの引数を増やす必要や、 受け取った値をインスタンスのメンバに書き込む必要がある。
|
|
|
139 具体的にどの値を書き込めば良いのかまではPerlスクリプトでは判定することができない。
|
|
|
140 このような細かな調整をする場合は、 generate\_stub.pl側での自動生成はせずに、 雛形生成されたコンストラクタを変更すれば良い。
|
|
10
|
141 あくまで雛形生成スクリプトはプログラマ支援であるため、 いくつかの手動での実装は許容している。
|
