# HG changeset patch # User Takahiro SHIMIZU # Date 1543478791 -32400 # Node ID 57547b9cbf5ff854967641584d7937dbee607627 # Parent 1c1307cedf1126bb779d510ebab3ef4ced15a665 update diff -r 1c1307cedf11 -r 57547b9cbf5f Paper/anatofuz.pdf Binary file Paper/anatofuz.pdf has changed diff -r 1c1307cedf11 -r 57547b9cbf5f Paper/anatofuz.tex --- a/Paper/anatofuz.tex Tue Nov 27 16:12:50 2018 +0900 +++ b/Paper/anatofuz.tex Thu Nov 29 17:06:31 2018 +0900 @@ -48,11 +48,11 @@ スクリプト言語であるPerl5の後継言語としてPerl6が現在開発されている． Perl6は設計と実装が区分されており様々な処理系が開発されている．現在主流なPerl6はRakudoと言われるプロジェクトである． RakudoではPerl6自体をNQP(NotQuitPerl)と言われるPerl6のサブセットで記述し, NQPをVMが解釈するという処理の流れになっている． -このVMは任意のVMが選択できるようになっており, 現在はMoarVM, JavaVM, JavaScriptが動作環境として選択可能である． -主に利用されているVMにCで書かれたMoarVMが存在する． +このVMは任意のVMが選択できるようになっており,主に利用されているVMにCで書かれたMoarVMが存在する． MoarVMはJITコンパイルなどをサポートしているが, 全体的な起動時間及び処理速度がPerl5と比較し非常に低速である． この問題を解決するためにContinuation based C (CbC)という言語を一部用いてMoarVMの書き換えを行う． CbCはCよりも細かな単位で記述が可能である為, 言語処理系の実装に適していると考えられる. +CbCに関する今までの研究においては, 言語処理系にCbCを利用した事例が少ない. その為, 本稿ではCbCを言語処理系に用いた場合の利点やデバッグ手法などについても述べる. @@ -79,7 +79,7 @@ また, 現在までのCbCを用いた研究においては言語処理系への応用例が少ない. 従って, 本稿はCbCをスクリプト言語の実装に適応した場合, どのような利点やプログラミング上の問題点に遭遇するか, CbCの応用としての側面でも行う． この際にCbCを用いた言語処理系のデバッグを行う際には, CbCを使わずに記述されたオリジナルの言語処理系との並列デバッグが必要となる. -従ってMoarVMにCbCを適応した場合, どのようにすれば並列デバッグが行えるかについて述べる． +従ってMoarVMにCbCを適応した場合, どのようにすれば並列デバッグが行えるかについても述べる． 本稿ではまずCbC, Perl6の特徴及び現在の実装について述べ, CbCで書き換えたMoarVMについてデバッグ手法も含め解説する. 研究にあたり, 得られたCbCを言語処理系に適応した場合の利点と欠点について述べ, 今後の展望について記載する. @@ -135,7 +135,7 @@ その為今回検証するMoarVMのビルドにおいてもCbCで書き換えたソースコードがあるMoarVMと, 手を加えていないオリジナルのMoarVMの2種類を同一のCbCコンパイラでビルドする事が可能である． またCからCbCへの遷移時に, 再びCの関数に戻るように実装したい場合がある． -その際は環境付きgotoと呼ばれる手法を取る．これは\_CbC\_return及び\_CbC\_environmentという変数を渡す． +その際は環境付きgotoと呼ばれる手法を取る．これは\_CbC\_return及び\_CbC\_environmentという変数を使用する． この変数は\_CbC\_returnが元の環境に戻る際に利用するCodeGearを指し, \_CbC\_environmentは復帰時に戻す元の環境である． 復帰する場合, 呼び出した位置には帰らず, 呼び出した関数の終了する位置に帰る． \lstinputlisting[label=cbcreturn, caption=環境付き継続の例]{./src/return.cbc} @@ -229,7 +229,8 @@ \end{figure} NQPのビルドフローを図\ref{fig:nqpbuild}に示す． -実際にPerl6の処理系であるperl6を動かすためにはself buildしたNQPコンパイラが必要となる．その為にStage0を利用してStage1をビルドしNQPコンパイラを作成する． +RakudoによるPerl6に処理系はNQPにおけるnqpと同様に, moarにライブラリパスなどを設定したperl6というシェルスクリプトである． +このperl6を動かすためにはself buildしたNQPコンパイラが必要となる．その為にStage0を利用してStage1をビルドしNQPコンパイラを作成する． Stage1は中間的な出力であり, 生成されたNQPファイルはStage2と同一であるが, MoarVMのバイトコードが異なる． Perl6では完全なセルフコンパイルを実行したNQPが要求される為, Stage1を利用してもう一度ビルドを行いStage2を作成する． @@ -263,7 +264,6 @@ \begin{itemize} \item Perl6 (MoarVM) ver.2018.04.01 \item Perl6 (JVM) 2018.06-163-g612d071b8 built on JVM - \item Python 3.6.5 \item Java 10 \item Perl5 \end{itemize} @@ -598,7 +598,8 @@ perlccはPerlのバイトコードをCへの変換のみ行う為, Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない． またperlccで生成されたCのソースコードは難解であり, これをデバッグするのが困難でもある． MoarVMでthreaded codeを実現出来た場合, その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である． -Cレベルでもperlccの様に内部構造をCの関数化すればThrededCodeの様な物を構築できるが, CbCと比較して処理の単位が明確ではない為高速化は見込めない． +C言語でもperlccの様に内部構造をCの関数化すればThrededCodeの様な物を構築できるが, CbCと比較して処理の単位が明確ではない為高速化は見込めない． +また, CbCのCodeGearは基本ブロックそのものである為, CbCプログラムとして切り出す場合, CodeGearをそのまま出力すればよく, 生成されたCbCプログラム自体もperlccと比較して扱いやすい． CbCを用いたThrededCodeでperlccの様なツールを作成した場合, CodeGearの単位が正常に機能すればCbCのCodeGearがThrededCodeをより効率化出来ると推測できる．