--- a/paper/chapter/03-gears.tex	Wed Feb 03 17:05:54 2021 +0900
+++ b/paper/chapter/03-gears.tex	Wed Feb 03 18:50:12 2021 +0900
@@ -16,6 +16,10 @@
 
 \section{GearsOSの構成}
 
+GearsOSは様々な役割を持つCodeGearとDataGearで構成されている。
+特にOSであるために並行処理用の機構などが搭載されている。
+GearsOSの構成図を図\ref{fig:gearsstruct}に示す。
+
 \begin{figure}[h]
   \begin{center}
    \includegraphics[width=150mm]{fig/gears_structure.pdf}
@@ -79,15 +83,24 @@
 GearsOSでは通常のWorkerとしてCPUWorkerを、GPUに関連した処理をするCUDAWorker、合間にモデル検査関連のメタ計算をはさむMCWorkerが定義されている。
 \section{union Data型}
 
-ContextはすべてのDataGearの型定義を持っている。
+CbC/GearsOSではDataGearは構造体の形で表現されていた。
+すべてのDataGearを管理する、Contextは計算で使うすべてのDataGearの型定義を持っている。
+各DataGearは当然ではあるが別の型である。
+例えばStack DataGearとQueue DataGearは、それぞれstruct Stackとstruct Queueで表現されるが、 C言語のシステム上別の型とみなされる。
 メタレベルで見れば、 この型定義は\texttt{union Data}型にすべて書かれている。
-union Data型は、 C言語の共用体を使って実装されている。
-共用体とは、構成するメンバ変数で最大の型のメモリサイズと同じメモリサイズになる特徴がある。
+しかしContextはこれらの型をすべてDataGearとして等しく扱う必要がある。
+この為にC言語の共用体を使用し、汎用的なDataGearの型であるunion Data型を定義している。
+共用体とは、構成するメンバ変数で最大の型のメモリサイズと同じメモリサイズになる特徴があり、複数の異なる型をまとめて管理することができる。
 構造体と違い、1度に一つの型しか使うことができない。
-実際にどの型が書き込まれているかは、 DataGearに付随しているMetaDataGearにアクセスすれば良い。
 
 
+実際にどの型が書き込まれているかは、 Contextのどこに書き込まれているかによって確認の方法が異なる。
+Interfaceの入出力で利用しているdata配列の場合は、enumの番号とdata配列の添え字が対応している。
+このためenumで指定した場所に入っているunion Dataの具体的な型は、 enumと対応するDataGearになる。
+contextのヒープにアロケートされたDataGearの場合は、 型情報を取得できるMetaDataGearにアクセスすると、なんの型であったかが分かる。
 
+union DataからDataGearの型への変換はメタ計算で行われる。
+GearsOSの場合は、計算したいCodeGearの直前で実行されるStubCodeGearで値のキャストが行われる。
 \section{GearsOSのビルドシステム}
 GearsOSではビルドツールにCMakeを利用している。
 ビルドフローを図\ref{fig:gearsbuild1}に示す。
@@ -203,6 +216,7 @@
 この場合x86のマシンからARMのバイナリを出力する必要があり、 コンパイラやリンカーなどをARMのクロスコンパイル対応のものに指定する必要がある。
 また、 xv6の場合はリンク時に特定のリンカスクリプトを使う必要がある。
 これらのリンカスクリプトもCMake側に、 CMakeが提供しているリンカ用の特殊変数を使って自分で組み立てて渡す必要がある。
+CMake側に使用したいコンパイラの情報を渡せれば、以降はCMake側が自動的に適切なビルドスクリプトを生成してくれる。
 このようなCMakeの処理を手打ちで行うことは難しいので、 \texttt{pmake.pl}を作成した。
 \texttt{pmake.pl}の処理の概要を図\ref{fig:pmake}に示す。
 \texttt{pmake.pl}はPerlスクリプトで、 シェルコマンドを内部で実行しクロスコンパイル用のオプションを組み立てる。

--- a/paper/chapter/04-interface.tex	Wed Feb 03 17:05:54 2021 +0900
+++ b/paper/chapter/04-interface.tex	Wed Feb 03 18:50:12 2021 +0900
@@ -107,6 +107,8 @@
 private CodeGearの入力もStubから取得したいと考え、 ImplementをInterfaceのつもりでGearsOSのコードを記述した。
 
 
+\section{Interfaceのパーサーの構築}
+
 \section{Interfaceの実装のCbCファイルへの構文の導入}
 
 \section{GearsCbCのInterfaceの実装時の問題}

--- a/paper/chapter/05-perl.tex	Wed Feb 03 17:05:54 2021 +0900
+++ b/paper/chapter/05-perl.tex	Wed Feb 03 18:50:12 2021 +0900
@@ -35,6 +35,47 @@
 本研究では様々なメタレベルのコードを、トランスコンパイラで生成することを検討した。
 
 
+\section{Perlによるトランスコンパイラ用のライブラリ作製}
+従来のPerlトランスコンパイラはgenerate\_stub.plとgenerate\_context.plの2種類のスクリプトで構築されていた。
+これらのスクリプトはそれぞれ独立した処理を行っていた。
+
+しかし本研究を進めるにつれて、 Interfaceのパーサーやメタ計算部分の操作を行うAPIなど、 Perlスクリプトで共通した実装が見られた。
+さらにgenerate\_stub.plらPerlスクリプトの行数や処理の複雑度が上がり、 適切に処理をモジュール化する必要が生じた。
+この為新しく実装したPerlトランスコンパイラが利用するAPIは、 Perlのモジュール機能を利用しモジュールの形で実装した。
+以下に実装したモジュールファイルと、その概要を示す。
+
+\begin{itemize}
+  \item \texttt{Gears::Context}
+  \begin{itemize}
+    \item context.hの自動生成時に呼び出されるモジュール
+    \item 変換後のCbCのコードを解析し、使用されているDataGearの数え上げを行う
+  \end{itemize}
+  \item \texttt{Gears::Interface}
+  \begin{itemize}
+    \item InterfaceおよびImplementのパーサー
+  \end{itemize}
+  \item \texttt{Gears::Template}
+  Gears::Template以下はPerlスクリプトが生成する際に、テンプレートとして呼び出すファイルの定義などがある
+  \begin{itemize}
+    \item \texttt{Gears::Template::Context}
+    \begin{itemize}
+      \item context.hのテンプレート
+    \end{itemize}
+    \item \texttt{Gears::Template::Context::XV6}
+    \begin{itemize}
+      \item CbC Xv6 専用のcontext.hのテンプレート
+    \end{itemize}
+    \item \texttt{Gears::Template::Gmain}
+    \begin{itemize}
+      \item GearsOS Main関数のテンプレート
+    \end{itemize}
+  \end{itemize}
+  \item \texttt{Gears::Stub}
+  \begin{itemize}
+    \item Stub Code Gear生成時に呼び出されるモジュール
+  \end{itemize}
+\end{itemize}
+
 \section{context.hの自動生成}
 GearsOSのContextの定義はcontext.hにある。
 ContextはGearsOSの計算で使用されるすべてのCodeGear、 DataGearの情報を持っている。
@@ -110,6 +151,9 @@
 変換するCodeGearがルールになかった場合は、 デフォルト設定が呼び出される。
 
 
+
+\section{コンパイルタイムでのコンストラクタの自動生成}
+
 \section{InterfaceのAPIの自動保管}
 
 

--- a/paper/chapter/history.tex	Wed Feb 03 17:05:54 2021 +0900
+++ b/paper/chapter/history.tex	Wed Feb 03 18:50:12 2021 +0900
@@ -1,6 +1,8 @@
 \chapter*{研究関連業績}
 \begin{itemize}
-\item Takahiro SHIMIZU. How to build traditional Perl interpreters. PerlCon2019 , Aug, 2019
+\item CbCを用いたPerl6処理系  清水 隆博, 河野真治  第60回プログラミング・シンポジウム, Jan, 2019
+\item How to build traditional Perl interpreters. Takahiro SHIMIZU PerlCon2019 , Aug, 2019
+\item Perl6 Rakudo の内部構造について  清水 隆博  オープンソースカンファレンス 2019 Okinawa, Apr, 2020
 \item 継続を基本としたOS Gears OS  清水 隆博, 河野真治  第61回プログラミング・シンポジウム, Jan, 2020
 \item Perl6のサーバを使った実行 福田 光希, 清水 隆博, 河野真治  第61回プログラミング・シンポジウム, Jan, 2020
 \item xv6の構成要素の継続の分析 清水 隆博，河野 真治(琉球大学), 情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS), May, 2020

Binary file paper/master_paper.pdf has changed