Mercurial > hg > Papers > 2021 > anatofuz-master
changeset 111:4642d2f215d2
update
| author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
|---|---|
| date | Sat, 06 Feb 2021 15:42:26 +0900 |
| parents | 4f34c642e9fb |
| children | 8f0ff6d552ed |
| files | paper/chapter/04-interface.tex paper/chapter/05-perl.tex paper/chapter/news-items.tex paper/master_paper.pdf paper/src/AtomicT.h paper/src/AtomicTImpl.h |
| diffstat | 6 files changed, 90 insertions(+), 15 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/chapter/04-interface.tex Sat Feb 06 15:09:52 2021 +0900 +++ b/paper/chapter/04-interface.tex Sat Feb 06 15:42:26 2021 +0900 @@ -339,7 +339,7 @@ 主要なエディタであるvscodeのgolangの公式パッケージである\texttt{vscode-go}\cite{vscode-go}でも導入されており、 vscodeから呼び出すことが可能である。 vscode以外にもvimなどのエディタからの呼び出しや、 シェル上で呼び出して標準出力の結果を利用することが可能である。 -\section{GearsOSでのInterfaceを満たすCbCの雛形生成} +\section{GearsOSでのInterfaceを満たすCbCの雛形生成}\label{sec:impl2cbc} GearsOSでも同様のInterfaceの定義から実装するCodeGearの雛形を生成したい。 LanguageServerの導入も考えられるが、 今回の場合はC言語のLanguageServerをCbC用にまず改良し、 さらにGearsOS用に書き換える必要がある。 現状のGearsOSが持つシンタックスはCbCのシンタックスを拡張しているものではあるが、これはCbCコンパイラ側には組み込まれていない。 @@ -391,7 +391,7 @@ 順序はInterfaceをまず出力した後に、 Impl側を出力する。 -\subsection{コンストラクタの自動生成} +\subsection{コンストラクタの自動生成} \label{sec:autoConst} 雛形生成では他にコンストラクタの生成も行う。 GearsOSのInterfaceのコンストラクタは、 メモリの確保及び各変数の初期化を行う。 メモリ上に確保するのは主にInterfaceとImplのそれぞれが基本となっている。 @@ -416,7 +416,7 @@ あくまで雛形生成スクリプトはプログラマ支援であるため、 いくつかの手動での実装は許容している。 -\section{Interfaceの引数の数の確認} +\section{Interfaceの引数の数の確認} \label{sec:argNumber} GearsOSのノーマルレベルでは、 InterfaceのAPIの呼び出しは\texttt{interface->method(arg)}の呼び出し方であった。 \texttt{arg}は引数であり、これはInterfaceで定義したAPIの引数の一致している必要がある。 Interfaceの定義の引数は、Implの実装自身が第一引数でくる制約があった。 @@ -459,7 +459,7 @@ このローカル変数の型と、CodeGearの定義の引数の型が、完全に一致しているかどうかのチェックを行うと、さらに強固な引数チェックが可能となる。 ただし引数で渡す際に、例えばint型の値の加算処理などを行っていると、その処理の結果がint型になっているかどうかをPerlレベルでチェックする必要が出てしまう。 -\section{InterfaceのAPIにないものを呼び出した場合の検知} +\section{InterfaceのAPIにないものを呼び出した場合の検知} \label{sec:apinot} InterfaceAPI呼び出し時に、そもそもInterfaceファイルに定義していないAPIを呼び出してしまうことがある。 これもCbCファイルの変換前に処理を行いたい。 @@ -474,7 +474,7 @@ -\section{InterfaceのAPIを完全に実装していない場合の検知} +\section{InterfaceのAPIを完全に実装していない場合の検知}\label{sec:interfaceNotImpl} InterfaceのAPIで定義したCodeGearは、Impl側はすべて実装している必要がある。 しかし、 CodeGearの実装を忘れてしまうケースがある。 これをPerlレベルで検知したい。 @@ -494,7 +494,7 @@ \lstinputlisting[label=src:errNotDef, caption=未実装のInterfaceのAPIがあることを知らせるエラー]{src/errorNotDef.sh} -\section{par goto のInterface経由の呼び出しの対応} +\section{par goto のInterface経由の呼び出しの対応} \label{sec:interParGoto} 従来のpar gotoではInterface経由の呼び出しは想定していなかった。 par gotoで継続したいCodeGearはInterfaceのAPIとしてではなく、 Interfaceを入力として受け取るCodeGearとして実装する必要があった。 しかし食事する哲学者の問題(Dining Philosophers Problem、 DPP)の検証などでは、特定のInterfaceが並列で動いている必要がある。
--- a/paper/chapter/05-perl.tex Sat Feb 06 15:09:52 2021 +0900 +++ b/paper/chapter/05-perl.tex Sat Feb 06 15:42:26 2021 +0900 @@ -36,7 +36,7 @@ 本研究では様々なメタレベルのコードを、トランスパイラで生成することを検討した。 -\section{トランスパイラ用のPerlライブラリ作製} +\section{トランスパイラ用のPerlライブラリ作製}\label{sec:perlLib} 従来のPerlトランスパイラはgenerate\_stub.plとgenerate\_context.plの2種類のスクリプトで構築されていた。 これらのスクリプトはそれぞれ独立した処理を行っていた。 @@ -79,7 +79,7 @@ これらはgenerate\_stub.plおよびgenerate\_context.plおよび、本研究で作製したPerlのツールセットからも呼び出される。 -\section{context.hの自動生成} +\section{context.hの自動生成}\label{sec:context.hGen} GearsOSのContextの定義はcontext.hにある。 ContextはGearsOSの計算で使用されるすべてのCodeGear、 DataGearの情報を持っている。 context.hではDataGearに対応する\texttt{union Data}型の定義も行っている。 @@ -183,7 +183,7 @@ -\section{meta.pmによるメタ計算部分の入れ替え} +\section{meta.pmによるメタ計算部分の入れ替え} \label{sec:metapm} GearsOSでは次のCodeGearに移行する前のMetaCodeGearとして、 デフォルトでは\texttt{\_\_code meta}が使われている。 \texttt{\_\_code meta}はcontextに含まれているCodeGearの関数ポインタを、 enumからディスパッチして次のStub CodeGearに継続するものである。 @@ -253,7 +253,7 @@ -\section{別Interfaceからの書き出しを取得する必要があるCodeGear} +\section{別Interfaceからの書き出しを取得する必要があるCodeGear}\label{sec:interfaceInput} 従来のMetaCodeGearの生成では、 別のInterfaceからの入力を受け取るCodeGearのStubの生成に問題があった。 具体的なこの問題が発生する例題をソースコード\ref{src:insertTest1}に示す。 @@ -411,10 +411,33 @@ \lstinputlisting[label=src:replaceStubCode, caption=生成されたStubCodeGearと、もとのCodeGear]{src/replaceStubCode.cbc} -\section{ジェネリクスのサポート} +\section{ジェネリクスのサポート} \label{sec:generics} +型の安全性を保ったまま、柔軟な関数の定義を可能とする機能にジェネリクスがある。 +ジェネリクスは、型自体を変数(型変数)と設定し、あらゆる型でも同様のふるまいを行うという機能である。 + +GearsOSではInterface宣言に使われるType、Implなどの型キーワードは、そもそもジェネリクスを意識して作られていた。 +このジェネリクスをGearsOSにサポートしたい。 + +ジェネリクスは型変数を利用して関数、クラスを宣言する部分と、型変数に具体的な値を代入して操作する部分に意味が分離できる。 +GearsOSでは関数、クラス宣言の部分は、Interfaceの宣言およびImplmenetの実装に該当する。 +型変数に具体的な値をいれる部分は、 Interfaceを利用する場所、もしくはDataGearとして使う場所に相当する。 + +\subsection{ジェネリクスを使ったInterfaceの定義} +ジェネリクスを使ってInterfaceを定義した例を、ソースコード\ref{src:AtomicT}に示す。 +GearsOSでジェネリクスを扱う場合は、型名の宣言に続く\texttt{<>}の部分に、型変数を記述する。 +この例では、型変数としてTを使用している。 +型変数Tがどのような値を使うかは、ジェネリクスを呼び出している箇所で確定する。 +\lstinputlisting[label=src:AtomicT, caption=ジェネリクスを使ったAtomicTの定義]{src/AtomicT.h} + +\subsection{ジェネリクスを使ったImplの定義} +Implementの定義でも、ジェネリクスは同様に使うことが可能である。 +AtomicTの実装であるAtomicTImplの定義を、ソースコード\ref{src:AtomicTImpl}に示す。 +Interfaceでジェネリクスを使った場合、Impl側でもジェネリクスが伝搬される。 +この場合は型変数が、Interfaceと同様のTであるので、Interfaceで決定されたTの型と同様の型に決まる。 +\lstinputlisting[label=src:AtomicTImpl, caption=ジェネリクスを使ったAtomicTの実装の定義]{src/AtomicTImpl.h} -\section{generate\_stub.plのデバッグ機能の追加} +\section{generate\_stub.plのデバッグ機能の追加}\label{sec:generateStubDebug} 変換されたGearsOSのコードが意図しない結果になっていた場合、 generate\_stub.plのデバッグをする必要がある。 PerlスクリプトであるのでPerlのデバッガを使えばデバッグは可能である。 しかし、変換するGearsOSの行数もあり、さらにgenerate\_stub.pl自体の複雑度から、バグを生じている場所の検討をつけるのが難しい。 @@ -436,7 +459,7 @@ -\section{GearsOS初期化コードの自動生成} +\section{GearsOS初期化コードの自動生成} \label{sec:gmain} GearsOSでは、TaskManagerやWorker、Contextの初期化を起動時に行わなければならない。 GearsOSの例題では、これらの初期化関数や、初期化に関連するCodeGearはほぼ共通であった。
--- a/paper/chapter/news-items.tex Sat Feb 06 15:09:52 2021 +0900 +++ b/paper/chapter/news-items.tex Sat Feb 06 15:42:26 2021 +0900 @@ -1,4 +1,4 @@ -\chapter{新しくGearsOSに導入された機能} +\chapter{新しくGearsOSに導入された機能の概要} 本章では以降の章で解説するGearsOSに本研究を通して導入した機能について解説する。 機能の詳細は以降の章の確認されたい。 @@ -17,9 +17,50 @@ 本研究では型定義ファイルを導入し、メタ情報の自動書き込み機能を実装した。 詳細は\ref{sec:implType}章などで述べる。 +\section{Interfaceで未定義のAPIの検知} +従来のInterfaceは、実装していないAPI(CodeGear)があってもPerlスクリプトはCbCコードの変換をしてしまった。 +CbCコードの変換をする前に、 Perlスクリプトレベルで未定義のAPIを検知するようになった。 +詳細は\ref{sec:interfaceNotImpl}で述べる。 + +\section{Interfaceの引数の確認} +InterfaceのAPI呼び出しは、\texttt{goto meta}に変換されてしまうので、引数の数が揃っていない場合の確認がCbCレベルでは出来なかった。 +Perlスクリプトレベルで引数の数を確認するように実装し、GearsOSのプログラミングの安全性が向上した。 +詳細は\ref{sec:argNumber}で述べる。 + +\section{InterfaceにないAPIの呼び出しの検知} +InterfaceにないAPIの呼び出しも、従来はCbCに変換されコンパイルが走らないと解らなかった。 +PerlスクリプトレベルでAPI呼び出しの度にInterfaceに定義があるかの確認を行うように改善した。 +詳細は\ref{sec:apinot}で述べる。 + +\section{別のInterfaceからの出力の取得} +従来のGearsOSのInterfaceでは、入出力は自分のInterface内で完結している必要があった。 +このため、Stack Interfaceの出力をOther Interfaceで受け取る際に、自分でStubを実装する必要があった。 +この別のInterfaceの入力を受け取るStubの作製を自動化した。 +詳細は\ref{sec:interfaceInput}で述べる。 + +\section{Interfaceの雛形ファイルの作製スクリプトの導入} +満たすべきInterfaceと、満たしたい型が決定しても、従来はCodeGearの定義やコンストラクタをすべて手書きする必要があった。 +これらはバグの元であった為に、自動的に雛形ファイルを作製するスクリプトを導入した。 +詳細は\ref{sec:impl2cbc}で述べる。 + \section{実装のCodeGear名からメタ情報の切り離し} Interfaceの各APIであるCodeGearは、従来は実装する際にプログラマが実装の型の名前をCodeGearの名前の末尾につける必要があった。 この型名の情報はメタ情報であるため、 本研究ではCodeGearの宣言時に型名を末尾につけず、コンパイル時にトランスパイラ側で変換するように実装した。 +詳細は\ref{sec:autoCodeGearName}で述べる。 -\section{} \ No newline at end of file +\section{自由なMetaCodeGearの作製、継続の入れ替え機能} +従来はCodeGearの実行の後に継続するMetaCodeGearは\_\_code metaで決め打ちだった。 +ユーザーが定義したMetaCodeGearに継続できる機能を追加した。 +詳細は\ref{sec:metapm}で述べる。 + +\section{Perlトランスパイラの変換ルーチンのデバッグ機能の追加} +Perlトランスパイラでメタ計算を作製しているが、このPerlスクリプトは巨大な正規表現マッチのループで構成されている。 +変換したいCbCファイルがどの行の正規表現パターンにマッチしたかを可視化できる機能を追加した。 +詳細は\ref{sec:generateStubDebug}で述べる。 + +\section{DataGearの型集合ファイル、context.hの自動生成} +従来はInterface、Implの型を定義し、使いたいDataGearを決めると、手動でcontext.hにDataGearの型を記述する必要があった。 +この型情報はコンパイル時に決定するので、自動化が可能である。 +その為Perlトランスパイラを使い、自動的に生成する機能を実装した。 +詳細は\ref{sec:context.hGen}で述べる。 \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/src/AtomicT.h Sat Feb 06 15:42:26 2021 +0900 @@ -0,0 +1,6 @@ +typedef struct AtomicT <T>{ + __code checkAndSet(Impl* atomicT,T oldData, T newData, __code next(...), __code fail(...)); + __code set(Impl* atomicT,T newData, __code next(...)); + __code next(...); + __code fail(...); +} AtomicT;