Mercurial > hg > Papers > 2022 > pine-thesis

changeset 13:ae09749b0890 default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix summary and add figs for debugger
author Takato Matsuoka <t.matsuoka@cr.ie.u-ryukyu.ac.jp>
date Tue, 15 Feb 2022 00:08:04 +0900
parents 538bcf79ca64
children
files GearsDebugger.xmind paper/figs/cbc_c.png paper/figs/codeGear_dataGear.png paper/figs/codegear_goto.png paper/figs/debugMeta.png paper/figs/gearsDebuggerArchi.drawio.png paper/text/cbc.tex paper/text/gearsdebugger.tex paper/text/summary.tex paper/thesis.pdf
diffstat 10 files changed, 14 insertions(+), 6 deletions(-) [+]
line wrap: on
line diff
Binary file GearsDebugger.xmind has changed
Binary file paper/figs/cbc_c.png has changed
Binary file paper/figs/codeGear_dataGear.png has changed
Binary file paper/figs/codegear_goto.png has changed
Binary file paper/figs/debugMeta.png has changed
Binary file paper/figs/gearsDebuggerArchi.drawio.png has changed
--- a/paper/text/cbc.tex	Mon Jan 31 18:18:54 2022 +0900
+++ b/paper/text/cbc.tex	Tue Feb 15 00:08:04 2022 +0900
@@ -19,7 +19,7 @@
 特に、CodeGearからの入力を受け取るDataGearをInputDataGear、CodeGear実行後にCodeGearからの出力を受け取るDataGearをOutputDataGearという。
 
 \section{メタ計算}
-記述したプログラムの計算を行うためには、メモリ管理や、スレッド管理、GPUの資源管理などのOSレベルの計算を行う必要がある。このOSレベルの計算をメタ計算と呼び、ユーザーが記述したプログラムをノーマルレベルの計算と呼ぶことで2つの計算を区別している。
+記述したプログラムの計算を行うためには、メモリ管理や、並列処理、GPUの資源管理などのOSレベルの計算を行う必要がある。このOSレベルの計算をメタ計算と呼び、入力から出力までの純粋な計算のことをノーマルレベルの計算と呼ぶことで2つの計算を区別している。
 
 \section{MetaCodeGearとMetaDataGear}
 CbCにおいてメタ計算を行うCodeGearをMetaCodeGearといい、特に実行したいCodeGearの直前で実行されるMetaCodeGearをStubCodeGearという。
--- a/paper/text/gearsdebugger.tex	Mon Jan 31 18:18:54 2022 +0900
+++ b/paper/text/gearsdebugger.tex	Tue Feb 15 00:08:04 2022 +0900
@@ -1,5 +1,5 @@
 \chapter{GearsDebugger}
-本研究では、GearsOSに特化したデバッガとしてGearsDebuggerの開発を行った。本章ではGearsDebuggerの持つ機能や仕組みについて記述する。
+本研究では、GearsOSに特化したデバッガとしてGearsDebuggerの開発を行った。本章ではGearsDebuggerの持つ機能や仕組みについて説明する。
 
 \section{GearsDebuggerの持つ機能}
 GearsDebuggerの持つ機能として以下が挙げられる。
@@ -48,8 +48,14 @@
 \newpage
 
 \section{meta.pm}
-\ref{debugMeta}にて各CodeGearの呼び出し後にdebugMetaを呼び出すと説明したが、その呼び出し方法としてmeta.pm\cite{meta.pm}というGearsOSのビルドシステムのAPIを用いている。通常はCodeGear実行後、次のCodeGearのStubCodeGearへと遷移するが、meta.pmを使うことでCodeGear実行後の遷移先を特定のMetaCodeGearへと変更することができる。ソースコード\ref{src:meta.pm}にmeta.pmを示す。ソースコード\ref{src:meta.pm}の7行目にqr/HelloImpl/と正規表現がある。トランスパイラはこの正規表現にマッチしたCodeGearのgoto先を切り替えている。例でいうと、HelloImplという文字列を含むCodeGearがあった場合、ソースコード\ref{src:meta.pm} 13行目のサブルーチンgeneratedebugMetaを呼び出し、goto先をdebugMetaへと切り替えている。
+\ref{debugMeta}にて各CodeGearの呼び出し後にdebugMetaを呼び出すと説明したが、その呼び出し方法としてmeta.pm\cite{meta.pm}というGearsOSのビルドシステムのAPIを用いている。通常はCodeGear実行後、次のCodeGearのStubCodeGearへと遷移するが、meta.pmを使うことでCodeGear実行後の遷移先を特定のMetaCodeGearへと変更することができる。図\ref{figs:insertDebugger}を見るとCodeGear1の呼び出し後にdebugMetaを呼び出していることがわかる。ソースコード\ref{src:meta.pm}にmeta.pmを示す。ソースコード\ref{src:meta.pm}の7行目にqr/HelloImpl/と正規表現がある。トランスパイラはこの正規表現にマッチしたCodeGearのgoto先を切り替えている。例でいうと、HelloImplという文字列を含むCodeGearがあった場合、ソースコード\ref{src:meta.pm} 13行目のサブルーチンgeneratedebugMetaを呼び出し、goto先をdebugMetaへと切り替えている。
 
-
+\begin{figure}[htbp]
+  \begin{center}
+   \includegraphics[width=12cm]{./figs/debugMeta.png}
+   \caption{debugMetaの呼び出し}
+   \label{figs:insertDebugger}
+   \end{center}
+\end{figure}
 
 \lstinputlisting[label=src:meta.pm, caption=meta.pm]{src/meta.pm}
--- a/paper/text/summary.tex	Mon Jan 31 18:18:54 2022 +0900
+++ b/paper/text/summary.tex	Tue Feb 15 00:08:04 2022 +0900
@@ -2,8 +2,10 @@
 本研究では、GearsOSに特化したデバッガの作成を行った。CodeGear単位で遷移を行うGearsOSのデバッグを行うために、CodeGear単位でプログラムを一時停止させ、デバッグコマンドを入力することでDataGearの値を見ることが可能となった。また、デバッグ用のWorkerとTaskManagerを作成し、通常のWorkerとTaskManagerと変更することで、様々な例題を対象としてDataGearの値を確認することが可能となった。
 
 \section{今後の課題}
-今後の課題としてデバッガ呼び出し手順の煩雑さが挙げられる。現状でデバッガを呼び出すには通常のWorkerとTaskManagerからデバッグ用のWorker、TaskManagerへの入れ替えや、meta.pmの記述・配置、debugMetaのプロトタイプ宣言の記述を行い、再ビルドを行う必要がある。
-WorkerやTaskManagerに関しては、通常のWorkerやTaskManagerをデバッグ用に拡張させ、例題実行時にオプションとしてデバッグオプションを指定することで振る舞いを通常の振る舞いからデバッグ用へと分岐させることが可能だと考えられる。またmeta.pmやdebugMetaに関してはGearsOSのビルドシステムであるgenerate\_stub.plやgenerate\_context.pl側でデバッグオプションの有無により継続を先を変更することが出来れば、通常の例題を再ビルドさせることなく、オプションの有無によって通常実行とデバッグ実行を切り替えられると考える。
+今後の課題としてデバッガ呼び出し手順の煩雑さが挙げられる。現状でデバッガを呼び出すには通常のWorkerとTaskManagerからデバッグ用のWorker、TaskManagerへの入れ替えや、meta.pmの記述、debugMetaのプロトタイプ宣言の記述後、再ビルドを行う必要がある。これはデバッグ時に手動で行っているため面倒かつ人為的ミスが起こりやすいことが挙げられる。
+そのため将来的にはデバッグオプションによって通常実行とデバッグ実行を指定できるようにしたい。WorkerやTaskManagerに関しては、通常のWorkerやTaskManagerをデバッグ用に拡張させ、例題実行時にオプションとしてデバッグオプションを指定することで振る舞いを通常の振る舞いからデバッグ用へと分岐させることが可能だと考えられる。またmeta.pmやdebugMetaに関してはGearsOSのビルドシステムであるgenerate\_stub.plやgenerate\_context.pl側でデバッグオプションの有無により継続を先を変更することが出来れば、通常の例題を再ビルドさせることなく、オプションの有無によって通常実行とデバッグ実行を切り替えられると考える。
+
+また、課題としてトレース・再実行機能が挙げられる。デバッグ時に1つ前のCodeGearへと戻って値を確認したい場合があるが、GearsOSにはスタックが無いため戻ることができない。これについては先行研究\cite{ikkunMaster}のモデル検査で状態の保存に用いているstateDBの仕組みを利用することで、スタックの代わりに状態を保存し、その状態まで戻ることができるのではないかと考える。
 
 \begin{comment}
 \begin{itemize}
Binary file paper/thesis.pdf has changed