changeset 91:4232c9dc1431

update
author anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp>
date Fri, 05 Feb 2021 19:09:08 +0900
parents a93c2401753b
children f5766148955f
files paper/chapter/01-introduction.tex paper/chapter/03-gears.tex paper/chapter/04-interface.tex paper/chapter/05-perl.tex paper/chapter/06-evaluation.tex paper/chapter/abstract.tex paper/chapter/news-items.tex paper/drawio/generate_stub_about.drawio paper/drawio/getDataGearAbout.drawio paper/drawio/getDataGearAbout.pdf paper/master_paper.pdf paper/master_paper.tex paper/src/generateStubInterfaceExample.pl
diffstat 13 files changed, 110 insertions(+), 39 deletions(-) [+]
line wrap: on
line diff
--- a/paper/chapter/01-introduction.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/01-introduction.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -93,7 +93,13 @@
 GearsOSでは拡張性の保証も重要な課題である。
 拡張性を保証するにはすべて純粋なCbCで実装すると、実装がきわめて煩雑である。
 その為にはCbCとセマンティックが等しいより簡潔なGearsOS独自のシンタックスなどが必要である。
-これらを踏まえて実装したGearsOSを動作させる際のビルドフローもより効率的なものにしたい。
+独自のシンタックスはPerlスクリプトによって等価なCbCのソースコードに変換していた。
+
+従来のPerlスクリプトによるソースコードの変換では、 CodeGearが出力をDataGearに書き出す際に、 手でメタ計算を書かなければならない問題があった。
+また、 GearsOSのモジュール化の仕組みであるInterfaceの実装であるImplementの型定義ファイルが存在していなかった。
+GearsOSではノーマルレベルで宣言したDataGearは、構造体の形で表現される。
+従来のシステムではこの構造体も手で実装しなければならず、メタレベルの計算のうち大半を手で実装する必要があった。
+これらのメタレベルの計算はコンパイル時に決定するために、自動化を行いたい。
 
 本研究ではGearsOSの信頼性と拡張性の保証につながる、メタ計算に関するAPIについて考察する。
-GearsOSがメタ計算を自動生成しているトランスコンパイラで従来のGearsOSのシステムよりさらに拡張性の充実と、信頼性の保証を図る。
\ No newline at end of file
+GearsOSがメタ計算を自動生成しているPerlトランスパイラで従来のGearsOSのシステムよりさらに拡張性の充実と、信頼性の保証を図る。
\ No newline at end of file
--- a/paper/chapter/03-gears.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/03-gears.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -342,7 +342,7 @@
 generate\_stub.plは、 CbCファイルにメタレベルの情報を付け加え、GearsOSの拡張構文を取り除いた結果のCbCファイルを新たに生成する。
 返還前のGearsOSのファイルの拡張子は.cbcであるが、 generate\_stub.plによって変換されると、 同名で拡張子のみ.cに切り替わったファイルが生成される。
 拡張子は.cであるが、中身はCbCで記述されている。
-generate\_stub.plはあるプログラムのソースコードから別のプログラムのソースコードを生成するトランスコンパイラとして見ることができる。
+generate\_stub.plはあるプログラムのソースコードから別のプログラムのソースコードを生成するトランスパイラとして見ることができる。
 
 
 \begin{figure}[h]
@@ -354,8 +354,29 @@
 \end{figure}
 
 generate\_stub.plはGearsOSのソースコードを2回読む。
-1度目の読み込みで、ソースコード中に登場するCodeGearと、CodeGearの入出力を検知する。
-この際に\texttt{\#interface}構文でInterfaceの利用が確認された場合、 Interfaceの定義ファイルを開き、実装されているCodeGearとDataGearの組を取得する。
+1度目の読み込みは関数getDataGearが担当する。(図\ref{fig:aboutDataGear})
+ソースコード中に登場するCodeGearと、CodeGearの入出力を検知する。
+この際に\texttt{\#interface}構文でInterfaceの利用が確認された場合、 Interfaceの定義ファイルを開き、getDataGearをさらに呼び出す。
+これらの処理で、 1つのGearsOSのファイル自身と、 呼び出しているInterfaceの定義ファイルに実装されているCodeGearとDataGearの組を取得する。
+データの収集は、入力で与えられたファイルを1行ずつ読み込み、 あらかじめ設定した正規表現にパターンマッチすることで処理を行っている。
+ソースコード\ref{src:generateExampleInterface}は、GearsOSのソースコード中でInterfaceの使用宣言部分のパターンマッチ処理である。
+\lstinputlisting[label=src:generateExampleInterface, caption=CMakeList.txt内でのPerlの実行部分]{src/generateStubInterfaceExample.pl}
+
+ここでは使用しているInterfaceの名前を変数\texttt{\$interfaceHeader}にキャプチャし、 Interfaceの読み込み処理を8行目の\texttt{includeInterface}関数で実行している。
+includeInterface関数の中ではgetDataGearを呼び出し、CodeGear、DataGearの情報を取得している。
+
+
+取得した情報はgenerate\_stub.plが持つ変数に書き込まれる。
+この変数は主にPerlのハッシュ(連想配列)が利用される。
+
+
+\begin{figure}[h]
+    \begin{center}
+        \includegraphics[width=120mm]{drawio/getDataGearAbout.pdf}
+    \end{center}
+    \caption{getDataGearの処理の概要}
+    \label{fig:aboutDataGear}
+\end{figure}
 
 1度ファイルを完全に読み込み、 CodeGear、DataGearの情報を取得し終わると、以降はその情報をもとに変換したファイルを書き出す。
 ファイルを書き出す際は、 元のCbCファイルを再読み込みし、 変換する必要があるキーワードが出現するまでは、変換後のファイルに転記を行う。
@@ -363,7 +384,7 @@
 この為にgenerate\_stub.plは、goto文を検知するとcontext経由で引数のやりとりをするメタ処理を付け加える。
 また、すべてのCodeGearはcontextを入力として受け取る必要があるため、 引数を書き換えてContextを付け加えている。
 
-generate\_stub.plはPerlで書かれたトランスコンパイラであり、 C言語のコンパイラのように文字列を字句解析、構文解析をする訳ではない。
+generate\_stub.plはPerlで書かれたトランスパイラであり、 C言語のコンパイラのように文字列を字句解析、構文解析をする訳ではない。
 いくつかあらかじめ定義した正規表現パターンに読み込んでいるCbCファイルの行がパターンマッチされたら、 特定の処理をする様に実装されている。
 
 CodeGearの入力をcontextから取り出すStubCodeGearの生成もgenerate\_stub.plで行う。
@@ -407,6 +428,12 @@
 
 書き換えにおいてはビルドシステムはCMakeを利用し、 Perlクロスコンパイラを導入してたりとGearsOSのビルドシステムとほぼ同じシステムを利用している。
 GearsOSを使った比較的巨大な実用的なアプリケーションであるため、 xv6の書き換えを進むに連れて様々な面で必要な機能や課題が生まれている。
+
+従来の研究ではxv6はCMakeを使わずにMakeを用いてクロスコンパイルしていた。
+現在はxv6にGearsOSのCMakeを使ったビルドシステムを導入している。
+ARM用のバイナリが出力できるCbCコンパイラがある場合、x86マシンからCMakeを利用してクロスコンパイル可能となっている。
+
+CMakeを導入したことでGearsOSの拡張構文が使えるようになった。
 xv6はUNIX OSである為プロセス単位で処理を行っていたが、 ここに部分的にContextを導入した。
 xv6では割り込みのフラグなどを大域変数として使っていた。
 GearsOSで実装する場合はDataGear単位になるため、 これらのフラグもDataGearの形で実装し直した。
--- a/paper/chapter/04-interface.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/04-interface.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -6,7 +6,7 @@
 またPerlスクリプトがInterfaceを適切に取り扱う為のAPIも必要となることが分かった。
 本章では本研究で行ったGearsOSのInterfaceの改良について述べる。
 
-\section{GearsOSのInterfaceの構文の改良}
+\section{GearsOSのInterfaceの構文の改良\label{sec:newInterface}}
 GearsOSのInterfaceでは、 従来はDataGearとCodeGearを分離して記述していた。
 CodeGearの入出力をDataGearとして列挙する必要があった。
 CodeGearの入出力として\texttt{\_\_code()}の間に記述したDataGearの一覧と、Interface上部で記述したDataGearの集合が一致している必要がある。
@@ -57,7 +57,7 @@
 後方互換性を維持したまま、新しい構文に対応させるために、generate\_stub.plが利用するInterfaceの解析ルーチンを両方の構文に対応させた。
 
 
-\section{Implementの型定義ファイルの導入}
+\section{Implementの型定義ファイルの導入}\label{sec:implType}
 Interfaceを使う言語では、 Interfaceが決まるとこれを実装するクラスや型が生まれる。
 GearsOSもInterfaceに対応する実装が存在する。
 例えばStack Interfaceの実装はSingleLinkedStackであり、 Queueの実装はSingleLinkedQueueやSynchronizedQueueが存在する。
@@ -68,7 +68,7 @@
 \lstinputlisting[label=src:singleContext.h, caption=cotnext.hに直接書かれた型定義]{src/singleContext.h}
 
 CbCファイルからはcontext.hをインクルードすることで問題なく型の使用は可能である。
-Perlのトランスコンパイラであるgenerate\_stub.plはInterfaceの型定義ファイルをパースしていた。
+Perlのトランスパイラであるgenerate\_stub.plはInterfaceの型定義ファイルをパースしていた。
 しかし型定義ファイルの存在の有無がInterfaceと実装で異なっている為に、 generate\_stub.plでImplementの型に関する操作ができない。
 Implementの型も同様に定義ファイルを作製すれば、generate\_stub.plで型定義を用いた様々な処理が可能となり、ビルドシステムが柔軟な挙動が可能となる。
 また型定義は一貫して\texttt{*.h}に記述すれば良くなるため、 プログラマの見通しも良くなる。
@@ -119,8 +119,8 @@
 private CodeGearの入力もStubから取得したいと考え、 ImplementをInterfaceのつもりでGearsOSのコードを記述した。
 
 
-\section{Interfaceのパーサーの構築}
-従来のGearsOSのトランスコンパイラでは、 generate\_stub.plがInterfaceファイルを開き、情報を解析していた。
+\section{Interfaceのパーサーの構築}\label{sec:interfaceParser}
+従来のGearsOSのトランスパイラでは、 generate\_stub.plがInterfaceファイルを開き、情報を解析していた。
 この情報解析はgetDataGear関数で行われていた。
 しかしこの関数は、CbCファイルのCodeGear、DataGearの解析で使用するルーチンと同じものである。
 この為Interface特有のパースが出来ていなかった。
@@ -199,7 +199,7 @@
 \lstinputlisting[label=src:createHeaderName2Info, caption=ヘッダファイルの名前とInterfaceのパース結果の対応リストの作製]{src/createHeaderName2Info.pl}
 
 
-\section{Interfaceの実装のCbCファイルへの構文の導入}
+\section{Interfaceの実装のCbCファイルへの構文の導入} \label{sec:newInterfaceInCbC}
 今までのGearsOSではマクロに似た\texttt{\#interface}構文で使用するInterfce名を指定した。
 しかしInterfaceを実装する場合も、 InterfaceのAPIを利用する際も同じシンタックスであった。
 この2つは意味が異なっている為、 シンタックスを分離したい。
@@ -214,7 +214,7 @@
 \lstinputlisting[label=src:implHeader, caption=Intefaceの実装をする際の宣言]{src/implHeader.h}
 
 
-\section{Interface APIに対応したCodeGearの名前の自動変換}
+\section{Interface APIに対応したCodeGearの名前の自動変換} \label{sec:autoCodeGearName}
 InterfaceのAPIに対応したCodeGearを実装する際、今までは暗黙にInterface名とImplの型名をつなげた名前で定義していた。
 例えばStack InterfaceのAPIであるpopをSingleLinkedStackが実装した場合、CodeGearの名前はpopSingleLinkedStackにしていた。
 
@@ -256,10 +256,10 @@
 
 
 特にGearsOSの場合はPerlスクリプトによって純粋なCbCに一度変換されてからコンパイルが行われる。
-実装の状況とトランスコンパイラの組み合わせによっては、 CbCコンパイラレベルでコンパイルエラーを発生させないケースがある。
+実装の状況とトランスパイラの組み合わせによっては、 CbCコンパイラレベルでコンパイルエラーを発生させないケースがある。
 この場合は実際に動作させながら、gdb, lldbなどのCデバッガを用いてデバッグをする必要がある。
 またCbCコンパイラレベルで検知できても、すでに変換されたコード側でエラーが出る。
-このため、 トランスコンパイラの挙動をトレースしながらデバッグをする必要がある。
+このため、 トランスパイラの挙動をトレースしながらデバッグをする必要がある。
 Interfaceの実装が不十分であることのエラーは、 GearsOSレベル、最低でもCbCコンパイラのレベルで完全に検知したい。
 
 \section{Interfaceを満たすコード生成の他言語の対応状況}
--- a/paper/chapter/05-perl.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/05-perl.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -1,4 +1,4 @@
-\chapter{トランスコンパイラによるメタ計算}
+\chapter{トランスパイラによるメタ計算}
 
 GearsOSはCbCで実装を行う。
 CbCはC言語よりアセンブラに近い言語である。
@@ -12,36 +12,37 @@
 GearsOSではメタレベルの処理の作成にPerlスクリプトを用いており、 ノーマルレベルで記述されたCbCから、 メタ部分を含むCbCへと変換する。
 変換前のCbCをGearsCbCと呼ぶ。
 
-\section{トランスコンパイラ}
+\section{トランスパイラ}
 プログラミング言語から実行可能ファイルやアセンブラを生成する処理系のことを、一般的にコンパイラと呼ぶ。
-特定のプログラミング言語から別のプログラミング言語に変換するコンパイラのことを、 トランスコンパイラと呼ぶ。
-トランスコンパイラとしてはJavaScriptを古い規格のJavaScriptに変換するBabel\cite{babel}がある。
+特定のプログラミング言語から別のプログラミング言語に変換するコンパイラのことを、 トランスパイラ、トランスコンパイラ、トランスラなどと呼ぶ。
+本論文では以下トランスパイラと呼ぶ。
+トランスパイラとしてはJavaScriptを古い規格のJavaScriptに変換するBabel\cite{babel}がある。
 
-またトランスコンパイラは、変換先の言語を拡張した言語の実装としても使われる。
-JavaScriptに強い型制約をつけた拡張言語であるTypeScriptは、 TypeScriptから純粋なJavaScriptに変換を行うトランスコンパイラである。
+またトランスパイラは、変換先の言語を拡張した言語の実装としても使われる。
+JavaScriptに強い型制約をつけた拡張言語であるTypeScriptは、 TypeScriptから純粋なJavaScriptに変換を行うトランスパイラである。
 すべてのTypeScriptのコードはJavaScriptにコンパイル可能である。
 JavaScriptに静的型の機能を取り込みたい場合に使われる言語であり、 JavaScriptの上位の言語と言える。
 
 
 GearsOSはCbCにノーマルレベル、メタレベルの書き別けの機能などを追加した拡張言語であると言える。
 コンパイル時にCMakeによって呼び出される2種類のPerlスクリプトで等価な純粋なCbCに変換される。
-これらのPerlスクリプトはGearsOSのCbCから純粋なCbCへと変換している為に一種のトランスコンパイラと言える。
+これらのPerlスクリプトはGearsOSのCbCから純粋なCbCへと変換している為に一種のトランスパイラと言える。
 
-\section{トランスコンパイラによるメタレベルのコード生成}
-トランスコンパイラはノーマルレベルで記述されたGearsOSを、メタレベルを含むCbCへと変換する役割である。
+\section{トランスパイラによるメタレベルのコード生成}
+トランスパイラはノーマルレベルで記述されたGearsOSを、メタレベルを含むCbCへと変換する役割である。
 変換時に様々なメタ情報をCbCのファイルに書き出すことが可能である。
-従来はStubの生成や、 引数の変更などを行っていたが、 さらにメタレベルのコードをトランスコンパイラで作製したい。
-トランスコンパイラ上でメタレベルのコードを作製することによって、 GearsOS上でのアプリケーションの記述が容易になり、かつメタレベルのコードを柔軟に扱うことができる。
-本研究では様々なメタレベルのコードを、トランスコンパイラで生成することを検討した。
+従来はStubの生成や、 引数の変更などを行っていたが、 さらにメタレベルのコードをトランスパイラで作製したい。
+トランスパイラ上でメタレベルのコードを作製することによって、 GearsOS上でのアプリケーションの記述が容易になり、かつメタレベルのコードを柔軟に扱うことができる。
+本研究では様々なメタレベルのコードを、トランスパイラで生成することを検討した。
 
 
-\section{トランスコンパイラ用のPerlライブラリ作製}
-従来のPerlトランスコンパイラはgenerate\_stub.plとgenerate\_context.plの2種類のスクリプトで構築されていた。
+\section{トランスパイラ用のPerlライブラリ作製}
+従来のPerlトランスパイラはgenerate\_stub.plとgenerate\_context.plの2種類のスクリプトで構築されていた。
 これらのスクリプトはそれぞれ独立した処理を行っていた。
 
 しかし本研究を進めるにつれて、 Interfaceのパーサーやメタ計算部分の操作を行うAPIなど、 Perlスクリプトで共通した実装が見られた。
 さらにgenerate\_stub.plらPerlスクリプトの行数や処理の複雑度が上がり、 適切に処理をモジュール化する必要が生じた。
-この為新しく実装したPerlトランスコンパイラが利用するAPIは、 Perlのモジュール機能を利用しモジュールの形で実装した。
+この為新しく実装したPerlトランスパイラが利用するAPIは、 Perlのモジュール機能を利用しモジュールの形で実装した。
 以下に実装したモジュールファイルと、その概要を示す。
 
 \begin{itemize}
@@ -93,7 +94,7 @@
 さらにInterfaceファイルで定義した型をcontext.hに転記し、それをもとにImplの型を考えてCbCファイルを作製する必要があった。
 これらをすべてユーザーが行うと、ファイルごとに微妙な差異が発生したりとかなり煩雑な実装を要求されてしまう。
 DataGearの定義はInterfaceファイルを作製した段階で決まり、 使用しているDataGear、CodeGearはコンパイル時に確定する。
-使用している各Gearがコンパイル時に確定するならば、 コンパイルの直前に実行されるPerlトランスコンパイラでもGearの確定ができるはずである。
+使用している各Gearがコンパイル時に確定するならば、 コンパイルの直前に実行されるPerlトランスパイラでもGearの確定ができるはずである。
 ここからcontext.hをコンパイルタイミングでPerlスクリプト経由で生成する手法を考案した。
 
 \subsection{ビルド時のcontext.hの生成タイミング}
@@ -165,9 +166,9 @@
 
 GearsOSのビルドシステムのAPIとして\texttt{meta.pm}を作製した。
 これはPerlのモジュールファイルとして実装した。
-meta.pmはPerlで実装されたGearsOSのトランスコンパイラであるgenerate\_stub.plから呼び出される。
+meta.pmはPerlで実装されたGearsOSのトランスパイラであるgenerate\_stub.plから呼び出される。
 meta.pmの中のサブルーチンである\texttt{replaceMeta}に変更対象のCodeGearと変更先のMetaCodeGearへのgotoを記述する。
-ユーザーはmeta.pmのPerlファイルをAPIとしてGearsOSのトランスコンパイラにアクセスすることが可能となる。
+ユーザーはmeta.pmのPerlファイルをAPIとしてGearsOSのトランスパイラにアクセスすることが可能となる。
 
 具体的な使用例をコード\ref{src:metapm}に示す。
 meta.pmはサブルーチン\texttt{replaceMeta}が返すリストの中に、特定のパターンで配列を設定する。
@@ -180,7 +181,7 @@
 generate\_stub.plはGears CbCファイルの変換時に、 CbCファイルがあるディレクトリにmeta.pmがあるかを確認する。
 meta.pmがある場合はモジュールロードを行う。
 meta.pmがない場合はmeta Code Gearにgotoするものをデフォルト設定として使う。
-これらの処理はPerlのクロージャの形で表現しており、 トランスコンパイラ側では共通のAPIで呼び出すことが可能である。
+これらの処理はPerlのクロージャの形で表現しており、 トランスパイラ側では共通のAPIで呼び出すことが可能である。
 各Gode Gearが\texttt{goto文}を呼び出したタイミングでreplaceMetaを呼び出し、 ルールにしたがってgoto文を書き換える。
 変換するCodeGearがルールになかった場合は、 デフォルト設定が呼び出される。
 
@@ -226,7 +227,7 @@
 
 ここで必要となってくるのは、 実装しているInterface以外の呼び出し元のInterfaceからの値の取得である。
 今回の例ではStackTest InterfaceではなくStack Interfaceからdata、 data1を取得したい。
-どのInterfaceから呼び出されているかは、 コンパイルタイムには確定できるのでPerlのトランスコンパイラでStub Codeを生成したい。
+どのInterfaceから呼び出されているかは、 コンパイルタイムには確定できるのでPerlのトランスパイラでStub Codeを生成したい。
 
 \begin{figure}[h]
   \begin{center}
@@ -243,7 +244,7 @@
 pop2Test1の引数はdata, data1, stackであるので、前2つにpop2の出力を代入したい。
 
 Contextから値を取り出すのはメタ計算であるStub CodeGearで行われる。
-別Interfaceから値を取り出そうとする場合、 すでにPerlトランスコンパイラが生成しているStubを書き換える方法も取れる。
+別Interfaceから値を取り出そうとする場合、 すでにPerlトランスパイラが生成しているStubを書き換える方法も取れる。
 しかしStubCodeGearそのものを、 別Interfaceから値を取り出すように書き換えてはいけない。
 これは別Interfaceの継続として渡されるケースと、 次のgoto先として遷移するケースがあるためである。
 前者のみの場合は書き換えで問題ないが、 後者のケースで書き換えを行ってしまうとStubで値を取り出す先が異なってしまう。
@@ -255,7 +256,7 @@
 StubCodeGearを実装した分だけenumの番号が降られるため、 \texttt{goto meta}で遷移する際にenumの番号さえ合わせれば独自定義のStubに継続させることが可能である。
 別Interfaceから値を取り出したいケースの場合、 取り出してくる先のInterfaceと呼び出し元のCodeGearが確定したタイミングで別のStubCodeGearを生成する。
 呼び出し元のCodeGearが継続として渡すStubCodeGearのenumを、独自定義したenumに差し替えることでこの問題は解決する。
-この機能をPerlのトランスコンパイラである\texttt{generate\_stub.pl}に導入した。
+この機能をPerlのトランスパイラである\texttt{generate\_stub.pl}に導入した。
 
 \section{別Interfaceからの書き出しを取得するStubの生成}
 別Interfaceからの書き出しを取得する場合、 generate\_stub.plでは次の点をサポートする機能をいれれば実現可能である。
--- a/paper/chapter/06-evaluation.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/06-evaluation.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -9,6 +9,6 @@
 しかし、CbC xv6などの実用的なアプリケーションを実装する場合は、ファイルの数が莫大になる可能性がある。
 1ファイル内で様々な型が定義可能になれば、 より見通しの良いプログラミングが可能であると考えられる。
 
-\section{GearsOSのトランスコンパイラ}
+\section{GearsOSのトランスパイラ}
 
 \section{GearsOSのメタ計算}
--- a/paper/chapter/abstract.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/chapter/abstract.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -25,7 +25,7 @@
 GearsOSの開発ではノーマルレベルのコードとメタレベルのコードの両方が必要であり、メタレベルの計算の数は多岐にわたる。
 GearsOSの開発を進めていくには、メタレベルの計算を柔軟に扱うAPIや、 自動でメタレベルの計算を作製するGearsOSのビルドシステムが必須となる。
 本研究ではGearsOSの信頼性と拡張性の保証につながる、メタ計算に関するAPIについて考察し、言語機能などの拡張を行った。
-また、メタ計算を自動生成しているトランスコンパイラを改良し、従来のGearsOSのシステムよりさらに柔軟性が高いものを考案した。
+また、メタ計算を自動生成しているトランスパイラを改良し、従来のGearsOSのシステムよりさらに柔軟性が高いものを考案した。
 \chapter*{Abstract}
 In order to guarantee the reliability of an application, the reliability of the underlying OS must be highly guaranteed.
 The source code of an OS is huge, and there are bugs such as parallel processing that can only be discovered by actually running the OS.
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/chapter/news-items.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -0,0 +1,25 @@
+\chapter{新しくGearsOSに導入された機能}
+
+本章では以降の章で解説するGearsOSに本研究を通して導入した機能について解説する。
+機能の詳細は以降の章の確認されたい。
+
+\section{ARMクロスコンパイル用のCMakeの定義}
+ARM用のアーキテクチャに向けてクロスコンパイルするCMakeを定義した。
+これによってGearsOSのビルドシステムに手を加えずにクロスコンパイルが可能となった。
+
+\section{Interface構文の簡素化}
+従来APIの定義とCodeGearの定義を別で記述する必要があった箇所を、より簡潔に記述できるように定義した。
+詳細は\ref{sec:newInterface}章で述べる。
+
+\section{Interfaceの実装の型の導入}
+従来はInterfaceの実装の型は、プログラマが自分でメタ情報に変換し、Contextに書き込む必要があった。
+また、Interfaceの定義ファイルはあるものの、 Interfaceの実装は型定義ファイルが無かった。
+本研究では型定義ファイルを導入し、メタ情報の自動書き込み機能を実装した。
+詳細は\ref{sec:implType}章などで述べる。
+
+\section{実装のCodeGear名からメタ情報の切り離し}
+Interfaceの各APIであるCodeGearは、従来は実装する際にプログラマが実装の型の名前をCodeGearの名前の末尾につける必要があった。
+この型名の情報はメタ情報であるため、 本研究ではCodeGearの宣言時に型名を末尾につけず、コンパイル時にトランスパイラ側で変換するように実装した。
+
+
+\section{}
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/drawio/generate_stub_about.drawio	Fri Feb 05 19:09:08 2021 +0900
@@ -0,0 +1,1 @@
+<mxfile host="Electron" modified="2021-02-05T09:54:41.643Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/14.1.8 Chrome/87.0.4280.88 Electron/11.1.1 Safari/537.36" etag="0rlBr2AZKI-3WFYymnwI" version="14.1.8" type="device"><diagram id="6el_CxAvzxrmXDuHbWZK" name="ページ1">7VnbcuI4EP0aqnYfQtkWNvAYyG2msptUUTUzedoSWBhthOWV5QD79duy5asMIRtMUlPjF6y23LZOH/dpNT00XW9vBY5Wf3CfsJ5j+dseuuo5cAzG8KMsu8wyGnuZIRDUz0x2aZjRf4k2WtqaUJ/EtYmScyZpVDcueBiShazZsBB8U5+25Kz+1AgHxDDMFpiZ1u/Ulyu9CmdY2u8IDVb5k21PL3iN88l6JfEK+3xTMaHrHpoKzmV2tt5OCVPg5bhk993suVq8mCChPOaGxI7x/XPy9REvf1zfIftL5KILHYwXzBK9YP2ycpcjIHgS+kQ5sXtosllRSWYRXqirG4g52FZyzfTlJQ+lDqI9gnEsBX8ukENg0Q8kQpLt3pXYBT5ALMLXRIodTMlZlZNDc8oe6fGmjJCT21bV6OSxwJoVQeG7BA5ONHZvwNE2cLzCEt8SLAw8wRuQl3wWLMeDGpYtUBaoVaEcdYWkYyA5haSikPwTr8lnR7PJzHELnG4LnF5XcCIDznsO2e0bFhTP2afHs8FO5Hw0PYcGnlgEnxxFlGuSRtFBJorjFhDdzrIlMhHzQXb1kAu54gEPMbsurZNShywYlXPuOY80mn8TKXcaTpxIXseabKn8UTl/Uq76rh5dbbXndLDTg2Pjo17/cHRgtTwRC3IIlrzAAUoReWii0x5vQRiW9KX+JqePnil27ysaAoF9CmhNOeMivR8t00MFgDKW20MeKiIEDMexjk9RVKkBw3PCJnjxHKSPr7ibTm/gONf3ZnuNrOUanxtqK0/c7j44U1UDEhKBJfkrlsm8H4ELj8F7TOaiFknvn0QVqClwF3GK3CVMsEfRNgUrvw5ngfp90cISn8jfb3c4XvUcWLZ1KQTe/W5QDSgQqdPFjlHgnECvE26esfN+XhgK0jwkEtwQbY81Vdwm1aoc3EO7nK2HyH0ONnpevSaBAsTU0EFbtTzujI4Dg44xfjGLEVi0rEcuQ6gBcUuOwIwGoSIFgESE4iVASKHwudQX1tT32T6BrkvN/wz8WYLrjhrBHZrS3hbb7jZCw4+U9ly/n6parqCy7Zq021Y+fCSCwsoVR7I7QkBBubqw+pYzyC1ZrQBw54ayXEhHu+qo6dOMfJMbPiS5Qi1PWVF4x1YUe2h2porCbEPcCizih1lVRTJBmGVrdiy1LdwrBiGXR1Tf+9K+j8XzA9xFZRrXvvWO/N8S/Eq6qqrBW5TiBKnjoqkLLVsru00Whp3ljtGH5o5iK/BUudK+LTiYOax60nBfSRmvZwcS+peqlan0TPGOLjLjDWX5IjpLINa5Ekh6a1riVSZEnIYyrnh+VIbKztatV9reoNEDbcxvtGfeOB3ZVoPj2fuWjC8W/o6PwDJyIVU1zFIlsTOmu/N0Jmy779YwHgzMNDRyW7JQdxXMuGWvJPe2c3/VqK828VCjKfrBJapj9i9oGCXyiNAeHzJBYO+YdlizOOhMBn7dSc+9Ur5AifL9ZTcK39gbtDWj23rRqDPgzS7Ezwm825CZFsafCHgYlv8gZhJU/g+Lrv8D</diagram></mxfile>
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/drawio/getDataGearAbout.drawio	Fri Feb 05 19:09:08 2021 +0900
@@ -0,0 +1,1 @@
+<mxfile host="Electron" modified="2021-02-05T10:01:06.391Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/14.1.8 Chrome/87.0.4280.88 Electron/11.1.1 Safari/537.36" etag="8ATM5_-z53k7rt3_dtvR" version="14.1.8" type="device"><diagram id="6el_CxAvzxrmXDuHbWZK" name="ページ1">7Vpbc+o2EP41zLQPML5gA4+B3NpJm8xk5vTkqSNsYasRlivLAfrru7Llq8zlNJhkMuUFay2vrW8/77daGNiL9faOozj8jfmYDizD3w7s64FlWYY7hi9p2eUWczpTloATX9kqwzP5Byujoawp8XHSmCgYo4LETaPHogh7omFDnLNNc9qK0eZdYxRgzfDsIapb/yC+CHPr1JpU9ntMgrC4s+nO8jNrVExWK0lC5LNNzWTfDOwFZ0zkR+vtAlOJXoFLft3tnrPlg3EciVMuSM0EPbymvz6h1febe9v8JXbsoZt7eUM0VQtWDyt2BQKcpZGPpRNzYM83IRH4OUaePLuBoIMtFGuqTq9YJFQQzSmME8HZa4mcDRZ1Q8wF3u5diVniA8zCbI0F38GUglYFOUpSqfGmipBV2MJ6dIpYIMWKoPRdAQcHCrsfwNHUcLxGAt1hxDU8wRuQF38WLIv3UWHZAWWJWh3KaV9IWhqSC8gqEsnf0Rp/djTbzJx1wOl0wOn2BaetwfnAILt9Q5ygJf30eLbYaVsfTc+JhifiwSdH0S40SaFo2TqKsw4Qnd6ypa0j5oPsqiHjImQBixC9qazzSocMGFVzHhiLFZp/YSF2Ck6UCtbEGm+J+F47fpGuRo4aXW+V52ywU4NT4yMf/3B0YLUs5R4+BEtR4AClsDg00eqON8cUCfLWfJLzR08Xu/cVDQFHPgG0Fowynl1vr7KPDAChtLBHLJJECChKEhWfsqiSA4qWmM6R9xpkt6+5Wyxu4XOp923WFAHb0d62sTPueN36e990UQ1whDkS+M9EpMtRDC5cCs8xX/JGIN2/U1mfZrgNkwy4K5hgTuNthlVxHo4C+f2mdCU5k7+f7lESDixYtnHFOdr9rDENGBDLQ29HCVCO28f5tszJ+bAsDSVnHlMBbrCyJ4opTptpdQruYV1B1kPcvgQZXbfJRqg/dAkddxXLs97oONbomKA3vRaBRYtm5HKEWhB3pAhESRBJUgBImEteAoQE6p4rdWJNfJ/u0+em0vzHwF8kuM60FdyJruxdse1vHzT5SGUv5PulLuUSKtNsKLtpFMMnzAmsXHIkvyICFKSroTEyrHFhyUsFgLswVNVCNtrVR22feuTb3PAhyZViec6Cwj21oNhDswsVFHoX4o4jnjw+11UkF4TnfM2WIXeFe8UgYuKE4ntf2vcRf32Eq4jI4joy3pH/O4JfS1d1NfgRpThD6hi2qpRh19bK7NKFSW/JY/qhyaPcCrzUznRvCw6mDqOZNZwjOeN4esCRfyVbmVLQJPGIlxtvCS0W0VsGMS6VQbJLsxqvNiFmJBJJzfOTNNR2tk6zP+COWz3Q1vyhbbxrvm0aLZbnT1xxvlz6O14DQ0uHRJYxK5nHLpjxLtObMM2R08B4PNYT0dTpyEP9FTGzju2S2NvQ/b9MPdrGa71G5gdXqZbewSBRnIoTQnt6yDiG7WPWY83joHIZ+HXmA+da+gItKraY/Yi81cK9ox3d1Y22ewNeb0R8TeCdls50MP6ywOu/A+yVEi/ldDfnkDGk4h+TlGan76tVyWWxu//nsa6fH8b9BVLvncBqEigMXLSWoYmWSZw30Fo7J4y8EC7MVP9LS9gZwt7umXX8YGK651EsGFb/AchLyOqvFPbNvw==</diagram></mxfile>
\ No newline at end of file
Binary file paper/drawio/getDataGearAbout.pdf has changed
Binary file paper/master_paper.pdf has changed
--- a/paper/master_paper.tex	Fri Feb 05 17:45:51 2021 +0900
+++ b/paper/master_paper.tex	Fri Feb 05 19:09:08 2021 +0900
@@ -109,6 +109,7 @@
 \input{chapter/01-introduction.tex}
 \input{chapter/02-cbc.tex}
 \input{chapter/03-gears.tex}
+\input{chapter/news-items.tex}
 \input{chapter/04-interface.tex}
 \input{chapter/05-perl.tex}
 \input{chapter/06-evaluation.tex}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/src/generateStubInterfaceExample.pl	Fri Feb 05 19:09:08 2021 +0900
@@ -0,0 +1,9 @@
+} elsif(/^#interface "(.*)"/) {
+    debug_print("getDataGear",__LINE__, $_) if $opt_debug;
+    # use interface
+    my $interfaceHeader = $1;
+    next if ($interfaceHeader =~ /context.h/);
+    $interfaceHeader =~ m|(\w+)\.\w+$|; #remove filename extension
+    my $interfaceName = $1;
+    includeInterface(\%call_interfaces, $filename, $interfaceName, $headerNameToInfo);
+