Mercurial > hg > Papers > 2021 > anatofuz-master

comparison paper/chapter/04-interface.tex @ 84:88ae1e4d83c6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update
author anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp>
date Fri, 05 Feb 2021 11:01:56 +0900
parents 3fb7c17d8e91
children c6c4b103c705
comparison
equal deleted inserted replaced
83:7f5bb7c5b433 84:88ae1e4d83c6
1 \chapter{GearsOSのInterfaceの改良} 1 \chapter{GearsOSのInterfaceの改良}
2 GearsOSのモジュール化の仕組みであるInterfaceは、 GearsOSの中心的な機能である。
3 Interfaceの取り扱いには様々なメタ計算が含まれ、 このメタ計算はPerlスクリプトによって生成される。
4
5 InterfaceをGearsOSで使ったプログラミングをするにつれて、様々な不足している機能や、改善すべき点が見つかった。
6 またPerlスクリプトがInterfaceを適切に取り扱う為のAPIも必要となることが分かった。
7 本章では本研究で行ったGearsOSのInterfaceの改良について述べる。
2 8
3 \section{GearsOSのInterfaceの構文の改良} 9 \section{GearsOSのInterfaceの構文の改良}
4 GearsOSのInterfaceでは、 従来はDataGearとCodeGearを分離して記述していた。 10 GearsOSのInterfaceでは、 従来はDataGearとCodeGearを分離して記述していた。
5 CodeGearの入出力をDataGearとして列挙する必要があった。 11 CodeGearの入出力をDataGearとして列挙する必要があった。
6 CodeGearの入出力として\texttt{\_\_code()}の間に記述したDataGearの一覧と、Interface上部で記述したDataGearの集合が一致している必要がある。 12 CodeGearの入出力として\texttt{\_\_code()}の間に記述したDataGearの一覧と、Interface上部で記述したDataGearの集合が一致している必要がある。
45 51
46 52
47 構文を変更するには、 GearsOSのビルドシステム上でInterfaceを利用している箇所を修正する必要がある。 53 構文を変更するには、 GearsOSのビルドシステム上でInterfaceを利用している箇所を修正する必要がある。
48 Interfaceはgenerate\_stub.plで読み込まれ、 CodeGearと入出力のDataGearの数え上げが行われる。 54 Interfaceはgenerate\_stub.plで読み込まれ、 CodeGearと入出力のDataGearの数え上げが行われる。
49 この処理はInterfaceのパースに相当するものである。 55 この処理はInterfaceのパースに相当するものである。
50 当然ではあるが、パース対象のInterfaceの構文は、変更前の構文にしか対応していない。 56 パース対象のInterfaceの構文は、変更前の構文にしか対応していなかった。
57 後方互換性を維持したまま、新しい構文に対応させるために、generate\_stub.plが利用するInterfaceの解析ルーチンを両方の構文に対応させた。
51 58
52 59
53 \section{Implementの型定義ファイルの導入} 60 \section{Implementの型定義ファイルの導入}
54 Interfaceを使う言語では、 Interfaceが決まるとこれを実装するクラスや型が生まれる。 61 Interfaceを使う言語では、 Interfaceが決まるとこれを実装するクラスや型が生まれる。
55 GearsOSもInterfaceに対応する実装が存在する。 62 GearsOSもInterfaceに対応する実装が存在する。
86 型定義の中では独自に定義したCodeGearを書いてもいい。 93 型定義の中では独自に定義したCodeGearを書いてもいい。
87 これはJavaのプライベートメソッドに相当するものである。 94 これはJavaのプライベートメソッドに相当するものである。
88 特にプライベートメソッドがない場合は、 実装側で所持したい変数定義を記述する。 95 特にプライベートメソッドがない場合は、 実装側で所持したい変数定義を記述する。
89 SynchronizedQueueの例では\texttt{top}などが実装側で所持している変数である。 96 SynchronizedQueueの例では\texttt{top}などが実装側で所持している変数である。
90 \lstinputlisting[label=src:syncqueue, caption=SynchronizedQueueの定義ファイル]{src/SynchronizedQueue.h} 97 \lstinputlisting[label=src:syncqueue, caption=SynchronizedQueueの定義ファイル]{src/SynchronizedQueue.h}
91 従来context.hに直接記述していたすべてのDataGearの定義は、 スクリプトで機械的にInterfaceおよびImplementの型定義ファイルに変換している。 98 従来context.hに直接記述していたすべてのDataGearの定義は、 スクリプトで機械的にInterfaceおよびImplementの型定義ファイルに変換を行った。
99
100 context.hからInterfaceおよびImplementの型定義をファイルに分割することができた。
101 しかしGearsOSのContextはすべてのDataGearの型定義を持つ必要がある。
102 この為、context.hには分割した型定義ファイルをもとに、CbCのメタレベルに変換された型情報を書き込む必要がある。
103 この処理はgenerate\_context.pl内でビルド時に行うようにした。
92 104
93 \section{Implementの型をいれたことによる間違ったGearsプログラミング} 105 \section{Implementの型をいれたことによる間違ったGearsプログラミング}
94 Implementの型を導入したが、 GearsOSのプログラミングをするにつれていくつかの間違ったパターンがあることがわかった。 106 Implementの型を導入したが、 GearsOSのプログラミングをするにつれていくつかの間違ったパターンがあることがわかった。
95 自動生成されるStubCodeGearは、 goto metaから遷移するのが前提であるため、 引数をContextから取り出す必要がある。 107 自動生成されるStubCodeGearは、 goto metaから遷移するのが前提であるため、 引数をContextから取り出す必要がある。
96 Contextから取り出す場合は、 実装しているInterfaceに対応している置き場所からデータを取り出す。 108 Contextから取り出す場合は、 実装しているInterfaceに対応している置き場所からデータを取り出す。
109 121
110 \section{Interfaceのパーサーの構築} 122 \section{Interfaceのパーサーの構築}
111 従来のGearsOSのトランスコンパイラでは、 generate\_stub.plがInterfaceファイルを開き、情報を解析していた。 123 従来のGearsOSのトランスコンパイラでは、 generate\_stub.plがInterfaceファイルを開き、情報を解析していた。
112 この情報解析はgetDataGear関数で行われていた。 124 この情報解析はgetDataGear関数で行われていた。
113 しかしこの関数は、CbCファイルのCodeGear、DataGearの解析で使用するルーチンと同じものである。 125 しかしこの関数は、CbCファイルのCodeGear、DataGearの解析で使用するルーチンと同じものである。
114 従って、 Interface特有のパースが出来ていなかった。 126 この為Interface特有のパースが出来ていなかった。
115 127
116 例えば開いたヘッダファイルがInterfaceのファイルでも、そうでないCのヘッダファイルでも同様の解析をしてしまう。 128 また、開いたヘッダファイルがInterfaceのファイルでも、そうでないCのヘッダファイルでも同様の解析をしてしまう。
117 Interfaceの定義ファイルの構文はすでに統一されたものを使用している。 129 Interfaceの定義ファイルの構文はすでに統一されたものを使用している。
118 この構文で実装されていないInterfaceファイルを読み込んだ場合は、 エラーとして処理したい。 130 Interfaceの定義の構文で実装されていないInterfaceファイルを読み込んだ場合は、 エラーとして処理したい。
119 また、Interfaceが満たすべきCodeGearの種類やInputDataGearの数の管理も行いたい。 131 また、Interfaceが満たすべきCodeGearの種類やInputDataGearの数の管理も行いたい。
120 さらにInterfaceではなく、Implementの定義ファイルも同様にパースし、情報を解析したい。 132 さらにInterfaceではなく、Implementの定義ファイルも同様にパースし、情報を解析したい。
121 133
122 これらを実現するには、最初からInterfaceに特化したパーサーが必要となる。 134 これらを実現するには、今までgenerate\_stub.plで使っていた情報解析ルーチンをもとに、最初からInterfaceに特化したパーサーが必要となる。
123 本研究ではGears::Interfaceモジュールとして実装した。 135 本研究ではGears::InterfaceモジュールとしてInterfaceのパーサーを実装した。
124 136
125 \subsection{Gears::Interfaceの構成} 137 \subsection{Gears::Interfaceの構成}
138 Gears::InterfaceはPerlのモジュールであるが、 実際はパーサー用のAPIを提供しているサブルーチンのまとまりである。
139 その為オブジェクトを作らずに直接メソッドを呼び出して利用する。
140
141 パーサーはInterfaceであるかどうかを、構文の正規表現にマッチするかどうかで確認をする。(ソースコード\ref{src:IsInterface})
142 \lstinputlisting[label=src:IsInterface, caption=Interfaceであるかどうかの確認]{src/IsInterface.pm}
143
144 \subsection{Interfaceパーサーの呼び出し}
145 \lstinputlisting[label=src:createHeaderName2Info, caption=ヘッダファイルの名前とInterfaceのパース結果の対応リストの作製]{src/createHeaderName2Info.pl}
126 146
127 147
128 \section{Interfaceの実装のCbCファイルへの構文の導入} 148 \section{Interfaceの実装のCbCファイルへの構文の導入}
129 今までのGearsOSではマクロに似た\texttt{\#interface}構文で使用するInterfce名を指定した。 149 今までのGearsOSではマクロに似た\texttt{\#interface}構文で使用するInterfce名を指定した。
130 しかしInterfaceを実装する場合も、 InterfaceのAPIを利用する際も同じシンタックスであった。 150 しかしInterfaceを実装する場合も、 InterfaceのAPIを利用する際も同じシンタックスであった。