Mercurial > hg > Papers > 2019 > anatofuz-thesis
changeset 55:86caceecf1c9
update
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 16 Feb 2019 16:54:25 +0900 |
parents | dc67d629bdd9 |
children | aa2a9c95e294 |
files | prepaper/finalpre.pdf prepaper/finalpre.tex |
diffstat | 2 files changed, 58 insertions(+), 73 deletions(-) [+] |
line wrap: on
line diff
--- a/prepaper/finalpre.tex Sat Feb 16 14:19:38 2019 +0900 +++ b/prepaper/finalpre.tex Sat Feb 16 16:54:25 2019 +0900 @@ -50,7 +50,6 @@ \renewcommand{\abstractname}{Abstract} \begin{document} \title{CbCによるPerl6処理系} -%\title{Supporting NAT in Screen Sharing System TreeVNC} \author{135730B 氏名 {清水}{隆博} 指導教員 : 河野 真治} \date{} \twocolumn [ @@ -70,84 +69,73 @@ Since MoarVM is wrriten in C language, it can be rewritten in CbC. In this thesis, consider rewriting the instruction dispatch part of MoarVM with CbC. -%CbC で OS を記述する。 -%CbCはLLVMで実装されている。 -%codeとcode のあいだをcall ではなくjmpで結ぶことができる(goto) -%gotoをつかうことによりOSに必須なmeta計算を実現できる -%メタ計算は例えばメモリ管理スレッド管理CPUやGPUの資源管理そしてData/Code Gear の管理などである -%metaレベルではcode/data gear は一つの塊として操作される。これをcbcではunion dataとして実装している -%code gear 間の接続はつぎのcode gearの番号とthread structure に相当するcontextをmeta code gear にgoto する -%meta code gear で os の 機能であるメモリ管理やスレッド管理を行う。 -%ユーザーレベルではmeta構造を直接見ることはなく、継続を用いた関数型プログラミングに見える -%metaレベルから見たdata gearをゆーざーれべるのcode gearに接続するにはstub というmeta code gear を用いる -%stubとmetaはユーザーレベルcodegear とdatagearから生成することができる -%本論文ではstub とcontext 管理構造を生成するスクリプトを作成した -%これによりcode gear とdeta gear をデータを操作するinterface というまとまりにすることができる。 -%この仕組みの上に並列処理用のtaskmanagerを簡単なosとして構成することができた。 -%こんごはgears os の様々な構成要素を作成していきたい。 -%またメタ計算を用いて信頼性をあげる方法についても研究を進めていく。 -%例えばユーザーレベルプログラムから定理証明支援系であるagdaのコードを生成することにより、プログラムの正しさを証明していくことが考えられる。 + \end{onecolabstract}] \thispagestyle{fancy} -\section{CbC} -Perl6処理系の改良にはgccとLLVM/Clang上に実装したContinuation based C(CbC)を用いる. -CbCはCodeGearを基本的な処理単位とし,CodeGearの遷移でプログラムを記述するCの下位言語である. -CodeGearの宣言は\_\_codeという型を持つ関数として宣言する. -\_\_codeは内部的にはvoid型として扱っているが,プログラマからの扱いはCodeGearである事を示す指示子のような役割である. -CodeGearはCの関数とは異なり返り値を持たず,呼び差し元の関数に戻る代わりに別のCodeGearへ遷移する. -CbCにおけるCodeGear間の継続はスタックに値を積まず,環境も遷移時に持たない為軽量継続と呼ぶ. -CbCは軽量継続を中心にプログラミングする事が可能であるため,レジスタの移動などが行われない. -その為並列化やループ制御,関数呼び出しにおけるスタック制御などを意識したプログラミングスタイルでプログラミングする事が可能である. -\lstinputlisting[label=cbcexample, caption=cbc\_example.cbc]{src/cbc_example.cbc} -\section{Perl6} -Perlの現在の主流な実装はRakudoである.RakudoはMoarVM,とNQPと呼ばれるPerl6のサブセット,NQPで記述されたPerl6という構成である. -MoarVMはNQPを解釈する. -このNQPで記述されたPerl6の事をRakudoと呼ぶ. -RakudoはMoarVMの他にJVM,Javascriptを動作環境として選択可能である. -言語的な特徴ではPerl5とは違いオブジェクト指向のサポートが強力になり,漸進的型付け言語としての特徴を持つ. +\section{Perl6の現在の実装} +現在開発が進んでいるプログラミング言語 Perl6 は、 入力されたソースコードを複数の仮想機械で実行可能なバイトコードにコンパイルする。 +仮想機械はPerl6専用のVMである、 MoarVMと、 JVMが選択可能である。 +MoarVMで動作する主流なPerl6の実装に、 Rakudoがある。 -処理時間は状況によるが,231KBのファイルを正規表現で検索する例題の場合Perl5が0.04sに対しMoarVMに乗せたPerl6は0.86sとおよそ20倍の速度差がある. +Rakudo実装のPerl6は、 他スクリプト言語と比較すると、 実行速度が低速である。 +また、 MoarVMの実装が巨大なcase文が使用されていたりとモジュール化がし辛い状況にある。 +バイトコードから仮想機械を動作させる際、 バイトコード中のバイト列から、 実行する命令の処理を取得するフェッチ部分が時間的にはボトルネックとなっている。 +今後この部分を改善し、 速度向上を測るために、 命令そのものを巨大なcase文から分離し、 モジュール化するのが望ましい。 +その為、 本研究では、 MoarVMの命令対応部分のモジュール化の検討を行う。 -\section{NQP} -NQPとはPerl6のサブセットである. -その為基本的な文法などはPerl6に準拠しているが,変数を束縛で宣言するなどの違いが見られる. +\section{CbC} +Perl6処理系の改良には、 gccとLLVM/Clang上に実装した、 Continuation based C(CbC)を用いる。 +CbCはCodeGearを基本的な処理単位とし、 CodeGearの遷移でプログラムを記述するCの下位言語である。 +CodeGearの宣言は、 \_\_codeという型を持つ関数として宣言する。 +\_\_codeは内部的にはvoid型として扱っているが、 プログラマからの扱いはCodeGearである事を示す指示子のような役割である。 +CodeGearはCの関数とは異なり返り値を持たず、 呼び差し元の関数に戻る代わりに別のCodeGearへ遷移する。 +CbCにおけるCodeGear間の継続は、 スタックに値を積まず、 環境も遷移時に持たない為軽量継続と呼ぶ。 +CbCは軽量継続を中心にプログラミングする事が可能であるため、 レジスタの移動などが行われない。 +その為並列化やループ制御、 関数呼び出しにおけるスタック制御などを意識した、 プログラミングスタイルでプログラミングする事が可能である。 +\lstinputlisting[label=cbcexample, caption=cbc\_example.cbc]{src/cbc_example_test.cbc} -NQPは最終的にはNQP自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれたMoarvMByteCodeを必要とする. -このMoarVMByteCodeの状態をStage0と言う. -Perl6の一部はNQPを拡張したもので書かれている為,Rakudoを動作させる為にはMoarVMなどのVM,VMに対応させる様にビルドしたNQPがそれぞれ必要となる. -NQPは与えられたStage0を使いStage1をビルドし,そのStage1を利用しStage2をビルドする事で生成できる. +%\section{NQP} +%NQPとはPerl6のサブセットである. +%その為基本的な文法などはPerl6に準拠しているが,変数を束縛で宣言するなどの違いが見られる. +% +%NQPは最終的にはNQP自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれたMoarvMByteCodeを必要とする. +%このMoarVMByteCodeの状態をStage0と言う. +%Perl6の一部はNQPを拡張したもので書かれている為,Rakudoを動作させる為にはMoarVMなどのVM,VMに対応させる様にビルドしたNQPがそれぞれ必要となる. +%NQPは与えられたStage0を使いStage1をビルドし,そのStage1を利用しStage2をビルドする事で生成できる. +% \section{MoarVM} -MoarVMはPerl6に特化したVMである.C言語で実装されている. -JITコンパイルなどが現在導入されているが,起動時間などが低速である問題がある. -MoarVM独自のByteCodeがあり,NQPからこれを出力する機能などが存在している. +MoarVMはPerl6に特化したVMである。 +C言語で実装されている。 +JITコンパイルなどが現在導入されているが、 起動時間などが低速である問題がある。 +MoarVM独自のByteCodeがあり、 NQPからこれを出力する機能などが存在している。 \section{MoarVMのディスパッチ} -MoarVMはNQPから変換されたバイトコードを読み取り,都度実行する. -MoarVMの場合この処理はMVM\_interp\_runという関数で行われている. -この関数内ではMoarVMが実行すべき命令が並んだ命令列を持ち,その値で巨大なcase文,またはCのラベルジャンプによって分岐させる. -分岐後は命令に応じた処理をMoarVMが行い,次の命令を実行する. -分岐後は命令にごとの処理を実行し,現在の命令列から,実行した命令の長さ分命令列を進める. -進めた後にcase文の先頭もしくはCのラベルジャンプを利用して次の処理に遷移する. -これを命令コードのディスパッチと呼ぶ. -命令コードの実行の中では,現在のMoarVMのレジスタであるreg\_baseやスレッドごとの環境である構造体tcなどを参照する. -この方法の問題点として,巨大なcase文になっている為命令列の分割が出来ない. -ディスパッチ部分の処理が都度走る為低速になる. -Cファイルでの可読性とモジュール化が損なわれてしまう. -ラベルにbreak pointを設定できない為デバッグし辛いなどがあげられる. +MoarVMはNQPから変換されたバイトコードを読み取り、 都度実行する。 +MoarVMの場合この処理はMVM\_interp\_runという関数で行われている。 +この関数内ではMoarVMが実行すべき命令が並んだ命令列を持ち、 その値で巨大なcase文、 またはCのラベルジャンプによって分岐させる。 +分岐後は命令に応じた処理をMoarVMが行い、 次の命令を実行する。 +分岐後は命令にごとの処理を実行し、 現在の命令列から、 実行した命令の長さ分命令列を進める。 +進めた後にcase文の先頭もしくはCのラベルジャンプを利用して次の処理に遷移する。 +これを命令コードのディスパッチと呼ぶ。 +命令コードの実行の中では、 現在のMoarVMのレジスタであるreg\_baseやスレッドごとの環境である構造体tcなどを参照する。 +この方法の問題点として、 巨大なcase文になっている為命令列の分割が出来ない。 +ディスパッチ部分の処理が都度走る為低速になる。 +Cファイルでの可読性とモジュール化が損なわれてしまう。 +ラベルにbreak pointを設定できない為デバッグし辛いなどがあげられる。 \lstinputlisting[label=origdis, caption=MoarVM内のインタプリタのディスパッチ]{src/dispatch.c} \section{CbCMoarVMのディスパッチ} -本研究ではMoarVMは2018.04.01のバージョンで実装している. -命令コードの実行すべき単位はCbCのCodeGearの単位として扱える為命令処理をCodeGearに変換する. -変換されたCodeGearはオリジナルのMoarVMの命令コードと対応させる為にCodeGearの配列に格納する. -MoarVMはこの配列を参照し,要素として得られるCodeGearに軽量継続を行う. -CodeGearでの処理が終了すると,次のCodeGearを決定する為に必要な計算をcbc\_nextというCodeGearで行い,次の命令列に軽量継続する. +本研究ではMoarVMは2018.04.01のバージョンで実装している。 +命令コードの実行すべき単位はCbCのCodeGearの単位として扱える為命令処理をCodeGearに変換する。 +変換されたCodeGearはオリジナルのMoarVMの命令コードと対応させる為にCodeGearの配列に格納する。 +MoarVMはこの配列を参照し、 要素として得られるCodeGearに軽量継続を行う。 +CodeGearでの処理が終了すると、 次のCodeGearを決定する為に必要な計算をcbc\_nextというCodeGearで行い,次の命令列に軽量継続する。 \lstinputlisting[label=codeseg, caption=CbCMoarVM内のインタプリタの状態遷移]{src/cbc_codesegs.cbc} \begin{figure}[ht] @@ -159,21 +147,18 @@ \end{figure} -オリジナルのMoarVMとは異なり,同一関数上で実行する訳では無い為,MVM\_interp\_runで定義している局所変数のレジスタreg\_baseなどにアクセスすることは通常では出来ない. -その為CodeGearの遷移において,これら必要なインタプリタの情報を纏めた構造体INTERを宣言し,このポインタであるINTERPを引数として入力する. -各CodeGearではこのINTERPを経由することでレジスタ情報などにアクセスする. +オリジナルのMoarVMとは異なり、同一関数上で実行する訳では無い為、 MVM\_interp\_runで定義している局所変数のレジスタreg\_baseなどにアクセスすることは通常では出来ない。 +その為CodeGearの遷移において、 これら必要なインタプリタの情報を纏めた構造体INTERを宣言し、 このポインタであるINTERPを引数として入力する。 +各CodeGearではこのINTERPを経由することでレジスタ情報などにアクセスする。 -この方法の利点としてCodeGearは単なる関数として扱える為,元のソースコードの様に同一ファイル内に全ての処理を書く必要がない. -またラベルにはbreak pointを設定する事が出来なかったが,CodeGearはデバッガからは関数として見る事ができるため通常のCの関数の様にbreak pointを設定する事が可能である. +この方法の利点としてCodeGearは単なる関数として扱える為、元のソースコードの様に同一ファイル内に全ての処理を書く必要がない。 +またラベルにはbreak pointを設定する事が出来なかったが、 CodeGearはデバッガからは関数として見る事ができるため通常のCの関数の様にbreak pointを設定する事が可能である。 -このCbCMoarVMのデバッグにはオリジナルのMoarVMとCbCMoarVMが実行した命令コードをデバッガで出力しログを取る必要がある. -取得したログから実行すべき命令番号が設定されている変数opの値を,オリジナルとCbC版で違いが発生するか解析する. + \section{今後の課題} -本研究では interface の記述、CbC ファイルから Gears OS の記述に必要な Context と stub の生成を行う perlスクリプトの生成を行なった。 -これにより Gears OS のコードの煩雑さは改善され、ユーザーは Context への接続を意識する必要がなくなった。 -今後の課題は Code Gear からメタ計算を行う meta Code Gear を生成できるようにし、ユーザーがメタレベルの処理を意識せずにコードを記述できるようにする。 -また、今回 perl スクリプトによって Context や stub の生成を行なったが、LLVM/clang\cite{llvm} 上で実装しコンパイラで直接 CbC を実行できるようにすることも優先する。 +本研究では、 MoarVM の命令ディスパッチ部分のCodeGearへの変換を行った。 +この際に、 \nocite{*} \bibliographystyle{junsrt}