Mercurial > hg > Papers > 2019 > anatofuz-prosym
comparison Paper/anatofuz.tex @ 37:79ba487d3576
modfy punctuation mark
author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 09 Nov 2018 11:29:54 +0900 |
parents | 4aa6a08b7dc9 |
children | 7d9b01a98b9a |
comparison
equal
deleted
inserted
replaced
36:4aa6a08b7dc9 | 37:79ba487d3576 |
---|---|
46 %概要 | 46 %概要 |
47 \begin{abstract} | 47 \begin{abstract} |
48 スクリプト言語であるPerl5の後継言語としてPerl6が現在開発されている. | 48 スクリプト言語であるPerl5の後継言語としてPerl6が現在開発されている. |
49 Perl6は設計と実装が区分されており様々な処理系が開発されている.現在主流なPerl6はRakudoと言われるプロジェクトである. | 49 Perl6は設計と実装が区分されており様々な処理系が開発されている.現在主流なPerl6はRakudoと言われるプロジェクトである. |
50 RakudoではPerl6自体をNQP(NotQuitPerl)と言われるPerl6のサブセットで記述し,NQPをVMが解釈するという処理流れになっている. | 50 RakudoではPerl6自体をNQP(NotQuitPerl)と言われるPerl6のサブセットで記述し,NQPをVMが解釈するという処理流れになっている. |
51 このVMは任意のVMが選択できるようになっており,現在はMoarVM,JavaVM,Javascriptが動作環境として選択可能である. | 51 このVMは任意のVMが選択できるようになっており,現在はMoarVM,JavaVM,Javascriptが動作環境として選択可能である. |
52 主に利用されているVMにCで書かれたMoarVMが存在する. | 52 主に利用されているVMにCで書かれたMoarVMが存在する. |
53 MoarVMはJITコンパイルなどをサポートしているが,全体的な起動時間及び処理速度がPerl5と比較し非常に低速である. | 53 MoarVMはJITコンパイルなどをサポートしているが,全体的な起動時間及び処理速度がPerl5と比較し非常に低速である. |
54 この問題を解決するためにContinuation based C (CbC)という言語を一部用いてMoarVMの書き換えを行う. | 54 この問題を解決するためにContinuation based C (CbC)という言語を一部用いてMoarVMの書き換えを行う. |
55 本論文ではCbCを用いたMoarVMの書き換えを検討し,得られた知見について述べる. | 55 本論文ではCbCを用いたMoarVMの書き換えを検討し,得られた知見について述べる. |
56 | 56 |
57 | 57 |
58 \end{abstract} | 58 \end{abstract} |
59 | 59 |
60 \begin{jkeyword} | 60 \begin{jkeyword} |
64 \maketitle | 64 \maketitle |
65 | 65 |
66 % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | 66 % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
67 \section{研究目的} | 67 \section{研究目的} |
68 現在も広く使われているスクリプト言語PerlことPerl5の後継言語としてPerl6が開発されている. | 68 現在も広く使われているスクリプト言語PerlことPerl5の後継言語としてPerl6が開発されている. |
69 Perl6は設計と実装が区分されており,現在広く使われている実装はRakudoと呼ばれるプロジェクトである. | 69 Perl6は設計と実装が区分されており,現在広く使われている実装はRakudoと呼ばれるプロジェクトである. |
70 Rakudoの実装はPerl6コンパイラ開発者用のサブセットであるNQP(NotQuitPerl)で実装されているPerl6の事を指す. | 70 Rakudoの実装はPerl6コンパイラ開発者用のサブセットであるNQP(NotQuitPerl)で実装されているPerl6の事を指す. |
71 現在RakudoはNQPを解釈できる実行環境として,C言語で実装されたMoarVM,JVM,Javascript上で動作する様に開発されている. | 71 現在RakudoはNQPを解釈できる実行環境として,C言語で実装されたMoarVM,JVM,Javascript上で動作する様に開発されている. |
72 Rakudoとして主に使われている処理系はMoarVMであるが,MoarVMの処理時間がPerl5などの多くのスクリプト言語と比較し非常に低速である. | 72 Rakudoとして主に使われている処理系はMoarVMであるが,MoarVMの処理時間がPerl5などの多くのスクリプト言語と比較し非常に低速である. |
73 その為現在日本国内ではPerl6を実務として利用するケースは概ね存在しない. | 73 その為現在日本国内ではPerl6を実務として利用するケースは概ね存在しない. |
74 Perl6の持つ言語機能や型システムは非常に柔軟かつ強力であるため実用的な処理速度に達すれば言語の利用件数が向上することが期待される. | 74 Perl6の持つ言語機能や型システムは非常に柔軟かつ強力であるため実用的な処理速度に達すれば言語の利用件数が向上することが期待される. |
75 この問題を解決するために現在当研究室で開発しているContinuation Based C(以下CbC)を用いて改良を行う. | 75 この問題を解決するために現在当研究室で開発しているContinuation Based C(以下CbC)を用いて改良を行う. |
76 CbCはCよりさらにきめ細やかな記述が可能であるためスクリプト言語などのプログラミング言語の記述と親和性が高い事が推測される. | 76 CbCはCよりさらにきめ細やかな記述が可能であるためスクリプト言語などのプログラミング言語の記述と親和性が高い事が推測される. |
77 本研究はCbCをスクリプト言語の実装に適応した場合,どのような利点やプログラミング上の問題点に遭遇するかCbCの応用としての側面でも行う. | 77 本研究はCbCをスクリプト言語の実装に適応した場合,どのような利点やプログラミング上の問題点に遭遇するかCbCの応用としての側面でも行う. |
78 本稿ではまずCbC,Perl6の特徴及び現在の実装について述べ,本研究で行ったCbCで書き換えたMoarVMについてデバッグ手法も含め解説する. | 78 本稿ではまずCbC,Perl6の特徴及び現在の実装について述べ,本研究で行ったCbCで書き換えたMoarVMについてデバッグ手法も含め解説する. |
79 そして本研究で得られたCbCを言語処理系に適応した場合の利点と欠点について述べ,今後の展望について記載する. | 79 そして本研究で得られたCbCを言語処理系に適応した場合の利点と欠点について述べ,今後の展望について記載する. |
80 | 80 |
81 \section{CbC} | 81 \section{CbC} |
82 \subsection{CbCの概要} | 82 \subsection{CbCの概要} |
83 CbCは当研究室で開発しているプログラミング言語である. | 83 CbCは当研究室で開発しているプログラミング言語である. |
84 Cレベルでのプログラミングを行う場合,本来プログラマが行いたい処理の他にmallocなどを利用したメモリのアロケートやエラーハンドリングなどを記述する必要がある. | 84 Cレベルでのプログラミングを行う場合,本来プログラマが行いたい処理の他にmallocなどを利用したメモリのアロケートやエラーハンドリングなどを記述する必要がある. |
85 これらの処理をmeta computationと呼ぶ.これらmeta computationと通常の処理を分離することでバグの原因がmeta computation側にあるか処理側にあるかの分離などが可能となる. | 85 これらの処理をmeta computationと呼ぶ.これらmeta computationと通常の処理を分離することでバグの原因がmeta computation側にあるか処理側にあるかの分離などが可能となる. |
86 しかしC言語などを用いたプログラミングでmeta computationの分離を行おうとすると,それぞれ事細かに関数やクラスを分割せねばならず容易ではない. | 86 しかしC言語などを用いたプログラミングでmeta computationの分離を行おうとすると,それぞれ事細かに関数やクラスを分割せねばならず容易ではない. |
87 CbCでは関数よりmeta computationを細かく記述する為にCodeSegmentという単位を導入した. | 87 CbCでは関数よりmeta computationを細かく記述する為にCodeSegmentという単位を導入した. |
88 またCodeSegmentの実行に必要なデータをDataSegmentという単位で受け渡す. | 88 またCodeSegmentの実行に必要なデータをDataSegmentという単位で受け渡す. |
89 CbCではCodeSegment,DetaSegmentを基本単位として記述するプログラミングスタイルを取る. | 89 CbCではCodeSegment,DetaSegmentを基本単位として記述するプログラミングスタイルを取る. |
90 | 90 |
91 \subsection{CodeSegmentとDataSegment} | 91 \subsection{CodeSegmentとDataSegment} |
92 CbCではCの関数の代わりにCodeSegmentを導入する. | 92 CbCではCの関数の代わりにCodeSegmentを導入する. |
93 CodeSegmentはCの関数宣言の型名の代わりに\_\_codeと書くことで 宣言できる. | 93 CodeSegmentはCの関数宣言の型名の代わりに\_\_codeと書くことで 宣言できる. |
94 \_\_codeはCbCコンパイラの扱いはvoidと同じ型であるが,CbCプログラミングではCodeSegmentである事を示す識別子としての意味で利用する. | 94 \_\_codeはCbCコンパイラの扱いはvoidと同じ型であるが,CbCプログラミングではCodeSegmentである事を示す識別子としての意味で利用する. |
95 CodeSegment間の移動はgoto文によって記述する. | 95 CodeSegment間の移動はgoto文によって記述する. |
96 \lstinputlisting[label=cbcexample, caption=cbc\_example.cbc]{./src/cbc_example.cbc} | 96 \lstinputlisting[label=cbcexample, caption=cbc\_example.cbc]{./src/cbc_example.cbc} |
97 Code\ref{cbcexample}に示すCbCのコードではmain関数からcs1,cs2に遷移し,最終的にdataの値が2となる. | 97 Code\ref{cbcexample}に示すCbCのコードではmain関数からcs1,cs2に遷移し,最終的にdataの値が2となる. |
98 CodeSegment間の入出力の受け渡しは引数を利用する.この引数は小さなDataSegmentであると言える. | 98 CodeSegment間の入出力の受け渡しは引数を利用する.この引数は小さなDataSegmentであると言える. |
99 | 99 |
100 \subsection{軽量継続} | 100 \subsection{軽量継続} |
101 %TBD | 101 %TBD |
102 CbCでは次のCodeSegmentに移行する際,Cのgoto文を利用する. | 102 CbCでは次のCodeSegmentに移行する際,Cのgoto文を利用する. |
103 通常のCの関数呼び出しの場合,スタックポインタを操作しローカル変数などをスタックに保存する. | 103 通常のCの関数呼び出しの場合,スタックポインタを操作しローカル変数などをスタックに保存する. |
104 CbCの場合スタックフレームを操作せず,レジスタの値を変更せずそのまま次のCodeSegmentに遷移する事が可能である. | 104 CbCの場合スタックフレームを操作せず,レジスタの値を変更せずそのまま次のCodeSegmentに遷移する事が可能である. |
105 通常Sechemeのcall/ccなどの継続は現在の位置までの情報を環境として所持した状態で遷移する. | 105 通常Sechemeのcall/ccなどの継続は現在の位置までの情報を環境として所持した状態で遷移する. |
106 対してCbCは環境を持たず遷移する為,通常の継続と比較して軽量であることから軽量継続であると言える. | 106 対してCbCは環境を持たず遷移する為,通常の継続と比較して軽量であることから軽量継続であると言える. |
107 CbCは軽量継続を利用するためレジスタレベルでのきめ細やかな実装が可能となっている. | 107 CbCは軽量継続を利用するためレジスタレベルでのきめ細やかな実装が可能となっている. |
108 | 108 |
109 \subsection{現在の実装} | 109 \subsection{現在の実装} |
110 CbCは現在主要なCコンパイラであるgcc及びllvmをバックエンドとしたclang上の2種類の実装が存在する. | 110 CbCは現在主要なCコンパイラであるgcc及びllvmをバックエンドとしたclang上の2種類の実装が存在する. |
111 gccはバージョン9.0.0に,clangは7.0.0に対応している. | 111 gccはバージョン9.0.0に,clangは7.0.0に対応している. |
112 | 112 |
113 \subsection{CbCコンパイラのバグ} | 113 \subsection{CbCコンパイラのバグ} |
114 % 局所変数のポインタを握ったままgotoするとtail callにならない | 114 % 局所変数のポインタを握ったままgotoするとtail callにならない |
115 CbCコンパイラは現在も開発中であり幾つかのバグが発見されている. | 115 CbCコンパイラは現在も開発中であり幾つかのバグが発見されている. |
116 まずCodeSegment内で宣言した局所変数のポインタを別の変数などで確保した状態でgotoしてしまうとtail call最適化が切られる. | 116 まずCodeSegment内で宣言した局所変数のポインタを別の変数などで確保した状態でgotoしてしまうとtail call最適化が切られる. |
117 これはただの関数呼び出しになってしまう為,直接的な被害はないもののCbCとしての利点が損なわれてしまう. | 117 これはただの関数呼び出しになってしまう為,直接的な被害はないもののCbCとしての利点が損なわれてしまう. |
118 また本来は操作しないはずのスタック領域の操作が入ってしまうため,プログラマの意図と反したスタックポインタなのど操作が行われてしまいバグが発生する可能性が存在する. | 118 また本来は操作しないはずのスタック領域の操作が入ってしまうため,プログラマの意図と反したスタックポインタなのど操作が行われてしまいバグが発生する可能性が存在する. |
119 | 119 |
120 \subsection{CbCとCの互換性} | 120 \subsection{CbCとCの互換性} |
121 CbCコンパイラは内部的に与えられているソースコードがCbCであるかどうかを判断する. | 121 CbCコンパイラは内部的に与えられているソースコードがCbCであるかどうかを判断する. |
122 この際にCodeSegmentを利用していない場合は通常のCプログラムとして動作する. | 122 この際にCodeSegmentを利用していない場合は通常のCプログラムとして動作する. |
123 その為今回検証するMoarVMのビルドにおいてもCbCで書き換えたソースコードがあるMoarVMと,手を加えていないオリジナルのMoarVMの2種類を同一のCbCコンパイラでビルドする事が可能である. | 123 その為今回検証するMoarVMのビルドにおいてもCbCで書き換えたソースコードがあるMoarVMと,手を加えていないオリジナルのMoarVMの2種類を同一のCbCコンパイラでビルドする事が可能である. |
124 | 124 |
125 またCからCbCへの遷移時に,再びCの関数に戻るように実装したい場合がある. | 125 またCからCbCへの遷移時に,再びCの関数に戻るように実装したい場合がある. |
126 その際は環境付きgotoと呼ばれる手法を取る.これは\_CbC\_return及び\_CbC\_environmentという変数を渡す. | 126 その際は環境付きgotoと呼ばれる手法を取る.これは\_CbC\_return及び\_CbC\_environmentという変数を渡す. |
127 この変数は\_CbC\_returnが元の環境に戻る際に利用するCodeSegmentを指し,\_CbC\_environmentは復帰時に戻す元の環境である. | 127 この変数は\_CbC\_returnが元の環境に戻る際に利用するCodeSegmentを指し,\_CbC\_environmentは復帰時に戻す元の環境である. |
128 復帰する場合,呼び出した位置には帰らず,呼び出した関数の終了する位置に帰る. | 128 復帰する場合,呼び出した位置には帰らず,呼び出した関数の終了する位置に帰る. |
129 \lstinputlisting[label=cbcreturn, caption=環境付き継続の例]{./src/return.cbc} | 129 \lstinputlisting[label=cbcreturn, caption=環境付き継続の例]{./src/return.cbc} |
130 Code\ref{cbcreturn}に示す例ではc\_funcから環境付き継続でがcsに継続している. | 130 Code\ref{cbcreturn}に示す例ではc\_funcから環境付き継続でがcsに継続している. |
131 通常c\_funcの返り値は-1であるが,csから環境付き継続でmainに帰る為にcsから渡される1がtestの値となる. | 131 通常c\_funcの返り値は-1であるが,csから環境付き継続でmainに帰る為にcsから渡される1がtestの値となる. |
132 | 132 |
133 | 133 |
134 \subsection{言語処理系におけるCbCの応用} | 134 \subsection{言語処理系におけるCbCの応用} |
135 CbCを言語処理系,特にスクリプト言語に応用すると幾つかの箇所に置いて利点があると推測される. | 135 CbCを言語処理系,特にスクリプト言語に応用すると幾つかの箇所に置いて利点があると推測される. |
136 CbCにおけるCSはコンパイラの基本ブロックに相当する. | 136 CbCにおけるCSはコンパイラの基本ブロックに相当する. |
137 その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeSegmentの遷移として記述する事が可能である. | 137 その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeSegmentの遷移として記述する事が可能である. |
138 CbCは状態を単位として記述が可能であるため,命令コードなどにおける状態を利用するスクリプト言語の実装は応用例として適していると考えられる. | 138 CbCは状態を単位として記述が可能であるため,命令コードなどにおける状態を利用するスクリプト言語の実装は応用例として適していると考えられる. |
139 | 139 |
140 \section{Perl6の概要} | 140 \section{Perl6の概要} |
141 この章では現在までのPerl6の遍歴及びPerl6の言語的な特徴について記載する. | 141 この章では現在までのPerl6の遍歴及びPerl6の言語的な特徴について記載する. |
142 \subsection{Perl6の構想と初期の処理系} | 142 \subsection{Perl6の構想と初期の処理系} |
143 Perl6は2002年にLarryWallがPerlを置き換える言語として設計を開始した. | 143 Perl6は2002年にLarryWallがPerlを置き換える言語として設計を開始した. |
144 Perl5の言語的な問題点であるオブジェクト指向機能の強力なサポートなどを取り入れた言語として設計された. | 144 Perl5の言語的な問題点であるオブジェクト指向機能の強力なサポートなどを取り入れた言語として設計された. |
145 Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった.Perl6は設計と実装が分離しており様々な処理系が開発されきた. | 145 Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった.Perl6は設計と実装が分離しており様々な処理系が開発されきた. |
146 まず2005年に唐鳳によってHaskellで実装されたPugs\cite{pugs}が登場した. | 146 まず2005年に唐鳳によってHaskellで実装されたPugs\cite{pugs}が登場した. |
147 Pugsは最初に登場したPerl6実装であり,この実装を基にしてPerl6の仕様も修正された. | 147 Pugsは最初に登場したPerl6実装であり,この実装を基にしてPerl6の仕様も修正された. |
148 現在Pugsは歴史的な実装となっており,更新はされていない. | 148 現在Pugsは歴史的な実装となっており,更新はされていない. |
149 | 149 |
150 \subsection{Parrot} | 150 \subsection{Parrot} |
151 その後Pythonとの共同動作環境としてParrot\cite{parrot}が実装された. | 151 その後Pythonとの共同動作環境としてParrot\cite{parrot}が実装された. |
152 ParrotはPASMと呼ばれるバイトコードを解釈可能なレジスタマシンである. | 152 ParrotはPASMと呼ばれるバイトコードを解釈可能なレジスタマシンである. |
153 ParrotでのPerl6の実装はNQP(NotQuitPerl)と呼ばれるPerl6のサブセットでPerl6を記述するというアイディアの基実装された. | 153 ParrotでのPerl6の実装はNQP(NotQuitPerl)と呼ばれるPerl6のサブセットでPerl6を記述するというアイディアの基実装された. |
154 ParrotVMは2006年のversion8.1.0が最後のリリースである. | 154 ParrotVMは2006年のversion8.1.0が最後のリリースである. |
155 こちらもPugsと同様に現在のPerl6プロジェクトでは歴史的な実装とされている. | 155 こちらもPugsと同様に現在のPerl6プロジェクトでは歴史的な実装とされている. |
156 現在主に使用されている実装であるRakudoは2010年にRakudo-Starという一連のツール郡としてリリースされた. | 156 現在主に使用されている実装であるRakudoは2010年にRakudo-Starという一連のツール郡としてリリースされた. |
157 | 157 |
158 Perl6は言語仕様及び処理実装がPerl5と大幅に異なっており,言語的な互換性が存在しない. | 158 Perl6は言語仕様及び処理実装がPerl5と大幅に異なっており,言語的な互換性が存在しない. |
159 従って現在ではPerl6とPerl5は別言語としての開発方針になっている. | 159 従って現在ではPerl6とPerl5は別言語としての開発方針になっている. |
160 Perl6は現在有力な処理系であるRakudoから名前を取りRakuという別名がつけられている. | 160 Perl6は現在有力な処理系であるRakudoから名前を取りRakuという別名がつけられている. |
161 | 161 |
162 \subsection{Rakudo} | 162 \subsection{Rakudo} |
163 | 163 |
166 Rakudoは図\ref{fig:perl6construction}に示す構成になっている. | 166 Rakudoは図\ref{fig:perl6construction}に示す構成になっている. |
167 Rakudoにおけるコンパイラとは厳密には2種類存在する. | 167 Rakudoにおけるコンパイラとは厳密には2種類存在する. |
168 まず第1のものがPerl6,もしくはNQPをMoarVM,JVMのバイトコードに変換するNQPコンパイラである. | 168 まず第1のものがPerl6,もしくはNQPをMoarVM,JVMのバイトコードに変換するNQPコンパイラである. |
169 次にそのNQPが出力したバイトコードをネイティブコードに変換するVMの2種類である. | 169 次にそのNQPが出力したバイトコードをネイティブコードに変換するVMの2種類である. |
170 このVMは現在MoarVM,JavaVM,Javascriptを選択可能である. | 170 このVMは現在MoarVM,JavaVM,Javascriptを選択可能である. |
171 Rakudo及びNQP projectではこのNQPコンパイラの部分をフロントエンド,VMの部分をバックエンド\cite{rani1}と呼称している. | 171 Rakudo及びNQP projectではこのNQPコンパイラの部分をフロントエンド,VMの部分をバックエンド\cite{rani1}と呼称している. |
172 NQPで主に書かれ,MoarVMなどNQPが動作する環境で動くPerl6のことをRakudoと呼ぶ. | 172 NQPで主に書かれ,MoarVMなどNQPが動作する環境で動くPerl6のことをRakudoと呼ぶ. |
173 Perl6はNQP以外にものNQPを拡張したPerl6自身で書かれている箇所が存在し,これはNQPコンパイラ側でMoarVMが解釈可能な形へ変換を行う. | 173 Perl6はNQP以外にものNQPを拡張したPerl6自身で書かれている箇所が存在し,これはNQPコンパイラ側でMoarVMが解釈可能な形へ変換を行う. |
174 | 174 |
175 \begin{figure}[ht] | 175 \begin{figure}[ht] |
176 \begin{center} | 176 \begin{center} |
177 \includegraphics[width=70mm]{fig/perl6nqp.pdf} | 177 \includegraphics[width=70mm]{fig/perl6nqp.pdf} |
178 \end{center} | 178 \end{center} |
180 \label{fig:perl6construction} | 180 \label{fig:perl6construction} |
181 \end{figure} | 181 \end{figure} |
182 | 182 |
183 \subsection{NQP} | 183 \subsection{NQP} |
184 | 184 |
185 RakudoにおけるNQP\cite{nqp}は現在MoarVM,JVM上で動作し,MoarVMを一部利用することでNodeJSからも動作させる事が可能である. | 185 RakudoにおけるNQP\cite{nqp}は現在MoarVM,JVM上で動作し,MoarVMを一部利用することでNodeJSからも動作させる事が可能である. |
186 NQPはPerl6のサブセットであるため主な文法などはPerl6に準拠しているが幾つか異なる点が存在する. | 186 NQPはPerl6のサブセットであるため主な文法などはPerl6に準拠しているが幾つか異なる点が存在する. |
187 NQPは最終的にはNQP自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれたMoarvMByteCodeを必要とする. | 187 NQPは最終的にはNQP自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれたMoarvMByteCodeを必要とする. |
188 このMoarVM~yteCodeの状態をStage0と言い,ディレクトリ名として設定されている. | 188 このMoarVM~yteCodeの状態をStage0と言い,ディレクトリ名として設定されている. |
189 Perl6の一部はNQPを拡張したもので書かれている為,Rakudoを動作させる為にはMoarVMなどのVM,VMに対応させる様にビルドしたNQPがそれぞれ必要となる. | 189 Perl6の一部はNQPを拡張したもので書かれている為,Rakudoを動作させる為にはMoarVMなどのVM,VMに対応させる様にビルドしたNQPがそれぞれ必要となる. |
190 現在のNQPではMoarVM,JVMに対応するStage0はそれぞれMoarVMBytecode,jarファイルが用意されており,Javascriptではバイトコードの代わりにランタイム独自のModuleLoaderなどが設計されている. | 190 現在のNQPではMoarVM,JVMに対応するStage0はそれぞれMoarVMBytecode,jarファイルが用意されており,Javascriptではバイトコードの代わりにランタイム独自のModuleLoaderなどが設計されている. |
191 MoarVMのModuleLoaderはStage0あるMoarVMBytecodeで書かれた一連のファイルが該当する. | 191 MoarVMのModuleLoaderはStage0あるMoarVMBytecodeで書かれた一連のファイルが該当する. |
192 | 192 |
193 | 193 |
194 Stage0にあるファイルをmoarvmに与えることでnqpのインタプリタが実行される様になっている. | 194 Stage0にあるファイルをmoarvmに与えることでnqpのインタプリタが実行される様になっている. |
195 これはStage0の一連のファイルはmoarvm bytecodeなどで記述されたNQPコンパイラのモジュールである為である. | 195 これはStage0の一連のファイルはmoarvm bytecodeなどで記述されたNQPコンパイラのモジュールである為である. |
196 NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている.これらMoarVMBytecodeの拡張子は.moarvmである. | 196 NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている.これらMoarVMBytecodeの拡張子は.moarvmである. |
197 MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.moarvmを実行させることでnqpの対話型環境が起動する. | 197 MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.moarvmを実行させることでnqpの対話型環境が起動する. |
198 | 198 |
199 \begin{figure}[ht] | 199 \begin{figure}[ht] |
200 \begin{center} | 200 \begin{center} |
201 \includegraphics[width=70mm]{fig/stagenqp.pdf} | 201 \includegraphics[width=70mm]{fig/stagenqp.pdf} |
202 \end{center} | 202 \end{center} |
204 \label{fig:nqpbuild} | 204 \label{fig:nqpbuild} |
205 \end{figure} | 205 \end{figure} |
206 | 206 |
207 NQPのビルドフローは図\ref{fig:nqpbuild}に示す. | 207 NQPのビルドフローは図\ref{fig:nqpbuild}に示す. |
208 実際にperl6を動かすためにはself buildしたNQPコンパイラが必要となる.その為にstage0を利用してStage1をビルドしNQPコンパイラを作成する. | 208 実際にperl6を動かすためにはself buildしたNQPコンパイラが必要となる.その為にstage0を利用してStage1をビルドしNQPコンパイラを作成する. |
209 Stage1は中間的な出力であり,生成されたNQPファイルはStage2と同一であるが,MoarVMBytecodeが異なる. | 209 Stage1は中間的な出力であり,生成されたNQPファイルはStage2と同一であるが,MoarVMBytecodeが異なる. |
210 Perl6では完全なセルフコンパイルを実行したNQPが要求される為,Stage1を利用してもう一度ビルドを行いStage2を作成する. | 210 Perl6では完全なセルフコンパイルを実行したNQPが要求される為,Stage1を利用してもう一度ビルドを行いStage2を作成する. |
211 | 211 |
212 Perl6のテストスイートである「Roast\cite{roast}」やドキュメントなどによって設計が定まっているPerl6とは異なりNQP自身の設計は今後も変更になる可能性が開発者から公表されている. | 212 Perl6のテストスイートである「Roast\cite{roast}」やドキュメントなどによって設計が定まっているPerl6とは異なりNQP自身の設計は今後も変更になる可能性が開発者から公表されている. |
213 現在の公表されているNQPのオペコードはNQPのリポジトリ\cite{nqpopcode}に記述されているものである. | 213 現在の公表されているNQPのオペコードはNQPのリポジトリ\cite{nqpopcode}に記述されているものである. |
214 | 214 |
215 | 215 |
216 \subsection{Rakudo Perl6} | 216 \subsection{Rakudo Perl6} |
217 Rakudo実装上におけるPerl6はRakudo Perl6と呼ばれているGitリポジトリで管理されているプログラムのことである. | 217 Rakudo実装上におけるPerl6はRakudo Perl6と呼ばれているGitリポジトリで管理されているプログラムのことである. |
218 前述した通りRakudo Perl6はPerl6のサブセットであるNQPを用いて記述されている. | 218 前述した通りRakudo Perl6はPerl6のサブセットであるNQPを用いて記述されている. |
219 従ってyaccやlexと言ったPerl5の文字解析,構文解析に利用していたプログラムは利用せず,NQP側で構文定義などを行っている. | 219 従ってyaccやlexと言ったPerl5の文字解析,構文解析に利用していたプログラムは利用せず,NQP側で構文定義などを行っている. |
220 NQPはNQP自身でBootstrappingされている為,Rakudo Perl6のbuild時にはNQPの実行環境として要したVM,それに基づいてbuildしたNQPがそれぞれ必要となる. | 220 NQPはNQP自身でBootstrappingされている為,Rakudo Perl6のbuild時にはNQPの実行環境として要したVM,それに基づいてbuildしたNQPがそれぞれ必要となる. |
221 | 221 |
222 言語的な特徴としては独自にPerl6の文法を拡張可能なGrammer,Perl5と比較した場合のオブジェクト指向言語としての進化も見られる. | 222 言語的な特徴としては独自にPerl6の文法を拡張可能なGrammer,Perl5と比較した場合のオブジェクト指向言語としての進化も見られる. |
223 またPerl6は漸進的型付け言語である. | 223 またPerl6は漸進的型付け言語である. |
224 従来のPerlの様に変数に代入する対象の型や文脈に応じて型を変更する動的型言語としての側面を持ちつつ独自に定義した型を始めとする様々な型に静的に変数の型を設定する事が可能である. | 224 従来のPerlの様に変数に代入する対象の型や文脈に応じて型を変更する動的型言語としての側面を持ちつつ独自に定義した型を始めとする様々な型に静的に変数の型を設定する事が可能である. |
225 | 225 |
226 | 226 |
227 \subsection{現在のPerl6} | 227 \subsection{現在のPerl6} |
228 Perl6の言語仕様\cite{perl6design}とその時点での実装状況を纏めた公式ドキュメント\cite{perl6doc}は分離している. | 228 Perl6の言語仕様\cite{perl6design}とその時点での実装状況を纏めた公式ドキュメント\cite{perl6doc}は分離している. |
229 従来は言語仕様は自然言語の仕様書であったが,現在はテストスイートである「Roast\cite{roast}」そのものと定義されている. | 229 従来は言語仕様は自然言語の仕様書であったが,現在はテストスイートである「Roast\cite{roast}」そのものと定義されている. |
230 現在のPerl6の仕様を読む場合Roastを確認し,現在rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある. | 230 現在のPerl6の仕様を読む場合Roastを確認し,現在rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある. |
231 | 231 |
232 | 232 |
233 \section{CbCによるMoarVM} | 233 \section{CbCによるMoarVM} |
234 この章では改良を行ったPerl6処理系であるMoarVMについて述べる. | 234 この章では改良を行ったPerl6処理系であるMoarVMについて述べる. |
235 \subsection{方針} | 235 \subsection{方針} |
240 MoarVMにおける基本ブロックはインタプリタが実行するバイトコードごとの処理に該当する. | 240 MoarVMにおける基本ブロックはインタプリタが実行するバイトコードごとの処理に該当する. |
241 | 241 |
242 \subsection{MoarByteCodeのディスパッチ} | 242 \subsection{MoarByteCodeのディスパッチ} |
243 MoarVMのバイトコードインタプリタはsrc/core/interp.cで定義されている. | 243 MoarVMのバイトコードインタプリタはsrc/core/interp.cで定義されている. |
244 この中の関数MVM\_interp\_runで命令に応じた処理を実行する. | 244 この中の関数MVM\_interp\_runで命令に応じた処理を実行する. |
245 関数内では命令列が保存されているcur\_op,現在と次の命令を指し示すop,Threadの環境が保存されているThreadcontextなどの変数を利用する. | 245 関数内では命令列が保存されているcur\_op,現在と次の命令を指し示すop,Threadの環境が保存されているThreadcontextなどの変数を利用する. |
246 命令実行は大きく二種類の動作があり,Code\ref{orig_macro}に示すCのgotoが利用できる場合はMVM\_CGOTOフラグが立ちラベル遷移を利用する. | 246 命令実行は大きく二種類の動作があり,Code\ref{orig_macro}に示すCのgotoが利用できる場合はMVM\_CGOTOフラグが立ちラベル遷移を利用する. |
247 それ以外の場合は巨大なcase文として命令を実行する. | 247 それ以外の場合は巨大なcase文として命令を実行する. |
248 | 248 |
249 ラベル遷移を利用する場合はラベルテーブルにアクセスし,テーブルに登録されているアドレスを取得し,NEXTで遷移する. | 249 ラベル遷移を利用する場合はラベルテーブルにアクセスし,テーブルに登録されているアドレスを取得し,NEXTで遷移する. |
250 このラベルテーブルの中身はラベルが変換されたアドレスであるため,Cレベルでのデバッグ時にはアドレスと実際に呼ばれる箇所を確認する事に手間がかかる. | 250 このラベルテーブルの中身はラベルが変換されたアドレスであるため,Cレベルでのデバッグ時にはアドレスと実際に呼ばれる箇所を確認する事に手間がかかる. |
251 巨大なcase文として実行された場合,実行時間が遅いだけでなく,ラベル遷移と共存させて記述を行っている為Cのソースコードにおける可読性も低下する. | 251 巨大なcase文として実行された場合,実行時間が遅いだけでなく,ラベル遷移と共存させて記述を行っている為Cのソースコードにおける可読性も低下する. |
252 | 252 |
253 CbCMoarVMではこの問題を解決するために,それぞれの命令に対応するCodeSegmentを作成し,CodeSegment名前を要素として持つCbCのCodeSegmentのテーブルを作成した. | 253 CbCMoarVMではこの問題を解決するために,それぞれの命令に対応するCodeSegmentを作成し,CodeSegment名前を要素として持つCbCのCodeSegmentのテーブルを作成した. |
254 \lstinputlisting[label=orig_macro, caption=interp.cのマクロ部分]{./src/orig_macro.c} | 254 \lstinputlisting[label=orig_macro, caption=interp.cのマクロ部分]{./src/orig_macro.c} |
255 | 255 |
256 | 256 |
257 \subsection{命令実行箇所のCodeSegmentへの変換} | 257 \subsection{命令実行箇所のCodeSegmentへの変換} |
258 ラベルテーブルやcase文のswitch相当の命令実行箇所をCbCに変換し,CodeSegmentの遷移として利用する. | 258 ラベルテーブルやcase文のswitch相当の命令実行箇所をCbCに変換し,CodeSegmentの遷移として利用する. |
259 interp.cはCode\ref{dispatch_c}に示すスタイルで記述されている. | 259 interp.cはCode\ref{dispatch_c}に示すスタイルで記述されている. |
260 \lstinputlisting[label=dispatch_c, caption=オリジナル版MoarVMのバイトコードディスパッチ]{./src/dispatch.c} | 260 \lstinputlisting[label=dispatch_c, caption=オリジナル版MoarVMのバイトコードディスパッチ]{./src/dispatch.c} |
261 | 261 |
262 | 262 |
263 OP(.*)の.*に該当する箇所はバイトコードの名前である.通常このブロックにはLABELから遷移する為,バイトコードの名前はLABELSの配列の添字に変換されている. | 263 OP(.*)の.*に該当する箇所はバイトコードの名前である.通常このブロックにはLABELから遷移する為,バイトコードの名前はLABELSの配列の添字に変換されている. |
264 そのため対象となるCodeSegmentをLABLESの並びと対応させ,配列CODESに設定すればCodeSegmentの名前は問わない. | 264 そのため対象となるCodeSegmentをLABLESの並びと対応させ,配列CODESに設定すればCodeSegmentの名前は問わない. |
265 今回はCodeSegmentである事を示す為にsuffixとしてcbc\_をつける. | 265 今回はCodeSegmentである事を示す為にsuffixとしてcbc\_をつける. |
266 | 266 |
267 | 267 |
268 命令の実行処理でMoarVMのレジスタであるreg\_baseや命令列cur\_opなどの情報を利用しているが,これらはMVM\_interp\_run内のローカル変数として利用している. | 268 命令の実行処理でMoarVMのレジスタであるreg\_baseや命令列cur\_opなどの情報を利用しているが,これらはMVM\_interp\_run内のローカル変数として利用している. |
269 ラベルを利用しているオリジナル版では同一関数内であるためアクセス可能であるが,CodeSegment間の移動で命令を表現するCbCではアクセスできない. | 269 ラベルを利用しているオリジナル版では同一関数内であるためアクセス可能であるが,CodeSegment間の移動で命令を表現するCbCではアクセスできない. |
270 その為インタプリタの情報を集約した構造体interを定義し,この構造体へのポインタであるINTERP型の変数iをCodeSegmentの入出力として与える. | 270 その為インタプリタの情報を集約した構造体interを定義し,この構造体へのポインタであるINTERP型の変数iをCodeSegmentの入出力として与える. |
271 CodeSegment内ではINTERPを経由することでインタプリタの各種情報にアクセスする. | 271 CodeSegment内ではINTERPを経由することでインタプリタの各種情報にアクセスする. |
272 CodeSegment間の遷移ではレジスタの値の調整は行われない為,入力引数を使ってレジスタマッピングを管理できる. | 272 CodeSegment間の遷移ではレジスタの値の調整は行われない為,入力引数を使ってレジスタマッピングを管理できる. |
273 その為INTERPのメンバであるMoarVMのレジスタそのものをアーキテクチャのレジスタ上に乗せる事が可能である. | 273 その為INTERPのメンバであるMoarVMのレジスタそのものをアーキテクチャのレジスタ上に乗せる事が可能である. |
274 | 274 |
275 命令実行中のCodeSegmentの遷移を図\ref{fig:perl6cbcinter}に示す. | 275 命令実行中のCodeSegmentの遷移を図\ref{fig:perl6cbcinter}に示す. |
276 この中で実線で書かれている部分はCbCのgoto文で遷移し,波線の箇所は通常のCの関数呼び出しとなっている. | 276 この中で実線で書かれている部分はCbCのgoto文で遷移し,波線の箇所は通常のCの関数呼び出しとなっている. |
277 | 277 |
278 現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している. | 278 現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している. |
279 これは元のMoarVMのマクロNEXTが行う処理に該当する. | 279 これは元のMoarVMのマクロNEXTが行う処理に該当する. |
280 CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する. | 280 CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する. |
281 | 281 |
282 \lstinputlisting[label=cbc_dispatch_c, caption=CbCMoarVMのバイトコードディスパッチ]{./src/cbc-interp-next.cbc} | 282 \lstinputlisting[label=cbc_dispatch_c, caption=CbCMoarVMのバイトコードディスパッチ]{./src/cbc-interp-next.cbc} |
283 | 283 |
284 \lstinputlisting[label=cbc_codesegs_c, caption=CbCMoarVMのバイトコードディスパッチ]{./src/cbc_codesegs.cbc} | 284 \lstinputlisting[label=cbc_codesegs_c, caption=CbCMoarVMのバイトコードディスパッチ]{./src/cbc_codesegs.cbc} |
285 | 285 |
289 \end{center} | 289 \end{center} |
290 \caption{CbCにおけるMoarVMバイトコードインタプリタ内の状態遷移} | 290 \caption{CbCにおけるMoarVMバイトコードインタプリタ内の状態遷移} |
291 \label{fig:perl6cbcinter} | 291 \label{fig:perl6cbcinter} |
292 \end{figure} | 292 \end{figure} |
293 | 293 |
294 バイトコードの数は膨大である為,すべてを手作業で変換する事は望ましくない. | 294 バイトコードの数は膨大である為,すべてを手作業で変換する事は望ましくない. |
295 本研究ではPerlScriptを用いてinterp.cからCbCのCodeSegmentを自動生成するスクリプトを作成した. | 295 本研究ではPerlScriptを用いてinterp.cからCbCのCodeSegmentを自動生成するスクリプトを作成した. |
296 このスクリプトでは以下の修正手続きを実行する. | 296 このスクリプトでは以下の修正手続きを実行する. |
297 | 297 |
298 \begin{itemize} | 298 \begin{itemize} |
299 \item OP(.*)の.*部分をCodeSegmentの名前として,先頭にcbc\_をつけた上で設定する. | 299 \item OP(.*)の.*部分をCodeSegmentの名前として,先頭にcbc\_をつけた上で設定する. |
300 \item cur\_opなど構造体INTERのメンバ変数はポインタiから参照するように修正する | 300 \item cur\_opなど構造体INTERのメンバ変数はポインタiから参照するように修正する |
301 \item GC対策のためマクロMVMROOTを使い局所変数のポインタをスタックに積む箇所は,局所変数をstatic化する | 301 \item GC対策のためマクロMVMROOTを使い局所変数のポインタをスタックに積む箇所は,局所変数をstatic化する |
302 \item 末尾のgoto NEXTをgoto cbc\_next(i)に修正する | 302 \item 末尾のgoto NEXTをgoto cbc\_next(i)に修正する |
303 \item case文で下のcase文に落ちている箇所は,case文に対応するCodeSegmentに遷移する様にgoto文を付け加える | 303 \item case文で下のcase文に落ちている箇所は,case文に対応するCodeSegmentに遷移する様にgoto文を付け加える |
304 \end{itemize} | 304 \end{itemize} |
305 | 305 |
306 | 306 |
307 現在CbCで記述されたOSであるGearsOSにはInterfaceが導入されている. | 307 現在CbCで記述されたOSであるGearsOSにはInterfaceが導入されている. |
308 これはJavaのinterface,Haskellの型クラスに該当する概念であり,次のCodeSegmentにInterface経由で継続する事が可能である. | 308 これはJavaのinterface,Haskellの型クラスに該当する概念であり,次のCodeSegmentにInterface経由で継続する事が可能である. |
309 Interfaceは現在のMoarVMには実装されていない為,今後ThreadeCodeの実装を行うにあたり導入を検討している. | 309 Interfaceは現在のMoarVMには実装されていない為,今後ThreadeCodeの実装を行うにあたり導入を検討している. |
310 | 310 |
311 \subsection{Threaded Code} | 311 \subsection{Threaded Code} |
312 現在のMoarVMは次の命令をバイトコードからディスパッチし決定後,ラベルジャンプを利用し実行している. | 312 現在のMoarVMは次の命令をバイトコードからディスパッチし決定後,ラベルジャンプを利用し実行している. |
313 この処理ではディスパッチの箇所にコストが掛かってしまう. | 313 この処理ではディスパッチの箇所にコストが掛かってしまう. |
314 CbCをMoarVMに導入することで,バイトコード列を直接サブルーチンコールの列に置き換えてしまう事が可能である. | 314 CbCをMoarVMに導入することで,バイトコード列を直接サブルーチンコールの列に置き換えてしまう事が可能である. |
315 これはCbCが基本ブロックの単位と対応している為である. | 315 これはCbCが基本ブロックの単位と対応している為である. |
316 CbCでは現在ディスパッチを行うCodeSegmentであるcbc\_nextを利用しているが,Threaded Codeを実装するにあたり, | 316 CbCでは現在ディスパッチを行うCodeSegmentであるcbc\_nextを利用しているが,Threaded Codeを実装するにあたり, |
317 cbc\_nextと次のCodeSegmentに直接遷移するcbc\_fixt\_nextの実装を予定している. | 317 cbc\_nextと次のCodeSegmentに直接遷移するcbc\_fixt\_nextの実装を予定している. |
318 | 318 |
319 また段階的に現在8バイト列を1命令コードとして使用しているが,これを16バイトなどに拡張し2命令を同時に扱えるように実装する事なども検討している. | 319 また段階的に現在8バイト列を1命令コードとして使用しているが,これを16バイトなどに拡張し2命令を同時に扱えるように実装する事なども検討している. |
320 | 320 |
321 %CbCはCodeSegmentで末尾最適化(Tail call optimization)を行う. | 321 %CbCはCodeSegmentで末尾最適化(Tail call optimization)を行う. |
322 %これはCodeSegmentは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である. | 322 %これはCodeSegmentは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である. |
323 %現在のCbCコンパイラの実装ではCodeSegmentからCの関数に戻る場合は末尾最適化を切り,CodeSegment間の遷移では末尾最適化が行われる. | 323 %現在のCbCコンパイラの実装ではCodeSegmentからCの関数に戻る場合は末尾最適化を切り,CodeSegment間の遷移では末尾最適化が行われる. |
324 %末尾最適化を応用することでContinuation-passingスタイルのThreaded Codeの実装が可能となる.\cite{threadedcode} | 324 %末尾最適化を応用することでContinuation-passingスタイルのThreaded Codeの実装が可能となる.\cite{threadedcode} |
325 %またCodeSegment自体を直接次の遷移先として設定することも可能であるため,CbCならThrededCodeを実装するアプローチが複数検討出来る. | 325 %またCodeSegment自体を直接次の遷移先として設定することも可能であるため,CbCならThrededCodeを実装するアプローチが複数検討出来る. |
326 | 326 |
327 %現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している. | 327 %現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している. |
328 %これは元のMoarVMの命令ディスパッチで行われる現在のオペコードを示すcur\_opと命令列opの操作及び次のラベルに遷移するマクロに該当する. | 328 %これは元のMoarVMの命令ディスパッチで行われる現在のオペコードを示すcur\_opと命令列opの操作及び次のラベルに遷移するマクロに該当する. |
329 %CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する形を取っている. | 329 %CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する形を取っている. |
330 %この一連の処理がオーバーヘッドになる為,今後はcbc\_fixt\_nextというCodeSegmentを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である. | 330 %この一連の処理がオーバーヘッドになる為,今後はcbc\_fixt\_nextというCodeSegmentを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である. |
331 | 331 |
332 \subsubsection{perlcc} | 332 \subsubsection{perlcc} |
333 Perl5においてはperlccというモジュールが開発されている. | 333 Perl5においてはperlccというモジュールが開発されている. |
334 これはPerl5内部で利用しているPerlバイトコードを,PerlのC APIであるXS言語の様なCのソースファイルに埋め込み,それをCコンパイルでコンパイルするというものである. | 334 これはPerl5内部で利用しているPerlバイトコードを,PerlのC APIであるXS言語の様なCのソースファイルに埋め込み,それをCコンパイルでコンパイルするというものである. |
335 perlccを利用することでPerlインタプリタが無い状況でも可動するバイナリファイルを作成する事が可能である. | 335 perlccを利用することでPerlインタプリタが無い状況でも可動するバイナリファイルを作成する事が可能である. |
336 しかしPerlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず,現在ではPerlのコアモジュールから外されている. | 336 しかしPerlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず,現在ではPerlのコアモジュールから外されている. |
337 PerlccはPerlのバイトコードをCへの変換のみ行う為,Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない. | 337 PerlccはPerlのバイトコードをCへの変換のみ行う為,Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない. |
338 またPerlccで生成されたCのソースコードは難解であり,これをデバッグするのが困難でもある. | 338 またPerlccで生成されたCのソースコードは難解であり,これをデバッグするのが困難でもある. |
339 MoarVMでthreaded codeを実現出来た場合,その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である. | 339 MoarVMでthreaded codeを実現出来た場合,その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である. |
340 この場合,Perl6を通常動かした際とは異なりバイトコードインタプリタに到達する前の処理が無くなる為多少の高速化が望めると推測できる. | 340 この場合,Perl6を通常動かした際とは異なりバイトコードインタプリタに到達する前の処理が無くなる為多少の高速化が望めると推測できる. |
341 | 341 |
342 \subsection{Cのインライン展開} | 342 \subsection{Cのインライン展開} |
343 CbCのCodeSegmentはgoto文で遷移するため,次のCodeSegmentが一意に決定している場合Cコンパイラ側でインライン展開する事が可能である. | 343 CbCのCodeSegmentはgoto文で遷移するため,次のCodeSegmentが一意に決定している場合Cコンパイラ側でインライン展開する事が可能である. |
344 CodeSegmentがインライン展開される限界については別途研究する必要があるが,CbCを利用した場合その箇所でもコストを低く設計する事が可能である. | 344 CodeSegmentがインライン展開される限界については別途研究する必要があるが,CbCを利用した場合その箇所でもコストを低く設計する事が可能である. |
345 | 345 |
346 \section{MoarVMのデバッグ} | 346 \section{MoarVMのデバッグ} |
347 | 347 |
348 MoarVM自体のデバッグはMoarVMのリポジトリにテストコードが付随していない為単体では実行不可能である. | 348 MoarVM自体のデバッグはMoarVMのリポジトリにテストコードが付随していない為単体では実行不可能である. |
349 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても考案する. | 349 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても考案する. |
350 | 350 |
351 \subsection{MoarVMのBytecodeのデバッグ} | 351 \subsection{MoarVMのBytecodeのデバッグ} |
352 moarに対してmoarvm bytecodeをdumpオプションを付けて読み込ませるとmoarvmのbytecodeがアセンブラの様に出力される. | 352 moarに対してmoarvm bytecodeをdumpオプションを付けて読み込ませるとmoarvmのbytecodeがアセンブラの様に出力される. |
353 しかしこれはmoarvmが実行したbytecodeのトレースではなくmoarvm bytecodeを変換したものに過ぎない. | 353 しかしこれはmoarvmが実行したbytecodeのトレースではなくmoarvm bytecodeを変換したものに過ぎない. |
354 また,明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう. | 354 また,明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう. |
355 そのため今回のMoarVMBytecodeインタプリタの実装のデバッグにはこの方法は適さない. | 355 そのため今回のMoarVMBytecodeインタプリタの実装のデバッグにはこの方法は適さない. |
356 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある. | 356 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある. |
357 | 357 |
358 CbC側はCode\ref{cbc_b}に示す様にcbc\_nextにbreak pointを設定する. | 358 CbC側はCode\ref{cbc_b}に示す様にcbc\_nextにbreak pointを設定する. |
359 オリジナル側は次のオペコードの設定のマクロにダミーの関数を呼び出すように修正し,そこにbreak pointを設定する. | 359 オリジナル側は次のオペコードの設定のマクロにダミーの関数を呼び出すように修正し,そこにbreak pointを設定する. |
360 CbC側ではCodeSegmentの名前をデバッガ上で直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかをデバッガの外で探す必要がある. | 360 CbC側ではCodeSegmentの名前をデバッガ上で直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかをデバッガの外で探す必要がある. |
361 | 361 |
362 添字を確認するためにはCode\ref{orig_b}に示すようにオリジナルのMoarVMの場合cur\_opの値をMVMuint16のポインタでキャストし,これが指す値を出力する. | 362 添字を確認するためにはCode\ref{orig_b}に示すようにオリジナルのMoarVMの場合cur\_opの値をMVMuint16のポインタでキャストし,これが指す値を出力する. |
363 break pointを掛けているダミー関数ではcur\_opにアクセスする事が出来ない為,スタックフレームを一つupする必要がある. | 363 break pointを掛けているダミー関数ではcur\_opにアクセスする事が出来ない為,スタックフレームを一つupする必要がある. |
364 \lstinputlisting[label=cbc_b, caption=CbCMoarVMに対してのbreak point設定]{./src/cbc_breakpoint.txt} | 364 \lstinputlisting[label=cbc_b, caption=CbCMoarVMに対してのbreak point設定]{./src/cbc_breakpoint.txt} |
365 \lstinputlisting[label=orig_b, caption=オリジナル版MoarVMに対してのbreak point設定]{./src/origin_b_set.txt} | 365 \lstinputlisting[label=orig_b, caption=オリジナル版MoarVMに対してのbreak point設定]{./src/origin_b_set.txt} |
366 | 366 |
367 | 367 |
368 \subsection{MoarVMの並列デバッグ手法} | 368 \subsection{MoarVMの並列デバッグ手法} |
369 しかしMoarVMが実行する命令は膨大な数がある. | 369 しかしMoarVMが実行する命令は膨大な数がある. |
370 その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である. | 370 その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である. |
371 Perlなどのスクリプトを用いて自動的に解析したいため,ログを残す為にscriptコマンドを実行した状態でgdbを起動する. | 371 Perlなどのスクリプトを用いて自動的に解析したいため,ログを残す為にscriptコマンドを実行した状態でgdbを起動する. |
372 | 372 |
373 | 373 |
374 \lstinputlisting[label=debug_origmoar, caption=オリジナル版MoarVMのバイトコードのトレース]{./src/origin_breakpoint.txt} | 374 \lstinputlisting[label=debug_origmoar, caption=オリジナル版MoarVMのバイトコードのトレース]{./src/origin_breakpoint.txt} |
375 | 375 |
376 CbCとオリジナルのCODES,LABELの添字は対応している為,ログの解析を行う際はそれぞれの添字を抽出し違いが発生している箇所を探索する. | 376 CbCとオリジナルのCODES,LABELの添字は対応している為,ログの解析を行う際はそれぞれの添字を抽出し違いが発生している箇所を探索する. |
377 これらはscriptコマンドが作成したログを元に異なる箇所を発見するスクリプトを用意し自動化する. | 377 これらはscriptコマンドが作成したログを元に異なる箇所を発見するスクリプトを用意し自動化する. |
378 \lstinputlisting[label=logs2, caption=バイトコードの差分検知の一部分]{./src/logs2.txt} | 378 \lstinputlisting[label=logs2, caption=バイトコードの差分検知の一部分]{./src/logs2.txt} |
379 | 379 |
380 違いが生じている箇所が発見できた場合,その前後のCodeSegment及びディスパッチ部分にbreak pointをかけ,それぞれの変数の挙動を比較する. | 380 違いが生じている箇所が発見できた場合,その前後のCodeSegment及びディスパッチ部分にbreak pointをかけ,それぞれの変数の挙動を比較する. |
381 主にcbc\_return系の命令が実行されている場合は,その直前で命令を切り替えるcbc\_invoke系統の命令が呼ばれているが,この周辺で何かしらの違いが発生している可能性が高い. | 381 主にcbc\_return系の命令が実行されている場合は,その直前で命令を切り替えるcbc\_invoke系統の命令が呼ばれているが,この周辺で何かしらの違いが発生している可能性が高い. |
382 また主に次のCodeSegmentに遷移する際にCbCコンパイラのバグが生じている可能性もある為,アセンブラレベルの命令を確認しながらデバッグを進めることとなる. | 382 また主に次のCodeSegmentに遷移する際にCbCコンパイラのバグが生じている可能性もある為,アセンブラレベルの命令を確認しながらデバッグを進めることとなる. |
383 | 383 |
384 | 384 |
385 | 385 |
386 \subsection{CbCコンパイラによるバグ} | 386 \subsection{CbCコンパイラによるバグ} |
387 現在までのCbCは複数個の入出力をCodeSegmentに与えるユースケースで利用していた. | 387 現在までのCbCは複数個の入出力をCodeSegmentに与えるユースケースで利用していた. |
388 CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した. | 388 CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した. |
389 主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう. | 389 主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう. |
390 その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである. | 390 その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである. |
391 このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る. | 391 このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る. |
392 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている. | 392 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている. |
393 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない. | 393 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない. |
394 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている. | 394 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている. |
395 | 395 |
397 その為現在はgcc上に実装したcbcコンパイラを利用しgdbを利用しデバッグを行う. | 397 その為現在はgcc上に実装したcbcコンパイラを利用しgdbを利用しデバッグを行う. |
398 | 398 |
399 | 399 |
400 \section{CbCを用いる事についての利点と欠点} | 400 \section{CbCを用いる事についての利点と欠点} |
401 MoarVMの様な巨大なスクリプト言語処理系にCbCを適応した所現在までに複数の利点と欠点が発見された. | 401 MoarVMの様な巨大なスクリプト言語処理系にCbCを適応した所現在までに複数の利点と欠点が発見された. |
402 本章ではまず利点を述べ,次に現段階でのCbCを適応した場合の欠点について考察する. | 402 本章ではまず利点を述べ,次に現段階でのCbCを適応した場合の欠点について考察する. |
403 | 403 |
404 \subsection{利点} | 404 \subsection{利点} |
405 \subsection{コード分割} | 405 \subsection{コード分割} |
406 オリジナルのMoarVMでは命令コードに対応する箇所はラベルジャンプ,もしくはswitch文で実装されていた. | 406 オリジナルのMoarVMでは命令コードに対応する箇所はラベルジャンプ,もしくはswitch文で実装されていた. |
407 その為同じCファイルに命令コードの実行の定義が存在しなければならない. | 407 その為同じCファイルに命令コードの実行の定義が存在しなければならない. |
408 今後MoarVMに新たなバイトコードが導入されていく事を考えるとinterp.cが巨大になる可能性がある. | 408 今後MoarVMに新たなバイトコードが導入されていく事を考えるとinterp.cが巨大になる可能性がある. |
409 関数単位での処理の比重が偏る事に加え, | 409 関数単位での処理の比重が偏る事に加え, |
410 switch文中に書かれている処理は他の関数から呼ぶ事が出来ないため,余計な手間がかかる箇所が発生すると考えられる. | 410 switch文中に書かれている処理は他の関数から呼ぶ事が出来ないため,余計な手間がかかる箇所が発生すると考えられる. |
411 | 411 |
412 CbCMoarVMの場合,CodeSegmentとして基本ブロックを記述出来る為オリジナルのMoarVMの様にswtich文のブロック中に書く必要性が無くなる. | 412 CbCMoarVMの場合,CodeSegmentとして基本ブロックを記述出来る為オリジナルのMoarVMの様にswtich文のブロック中に書く必要性が無くなる. |
413 その為類似する命令系をコード分割し,モジュール化する事が可能である. | 413 その為類似する命令系をコード分割し,モジュール化する事が可能である. |
414 またCbCはgoto文で遷移する以外は通常のCの関数と同じ扱いをする事が可能である. | 414 またCbCはgoto文で遷移する以外は通常のCの関数と同じ扱いをする事が可能である. |
415 従ってCodeSegment内部の処理を別の箇所から使用する事も可能となる為再利用性も向上する. | 415 従ってCodeSegment内部の処理を別の箇所から使用する事も可能となる為再利用性も向上する. |
416 | 416 |
417 \subsection{ThreadeCode} | 417 \subsection{ThreadeCode} |
418 ThrededCodeを実装する場合,通常命令ディスパッチの箇所と,実際に実行される命令処理を大幅に変更しなければならない. | 418 ThrededCodeを実装する場合,通常命令ディスパッチの箇所と,実際に実行される命令処理を大幅に変更しなければならない. |
419 CbCを用いた実装の場合,命令処理はただのCodeSegmentの集合である. | 419 CbCを用いた実装の場合,命令処理はただのCodeSegmentの集合である. |
420 その為CodeSegmentをThrededCodeに対応した並びとして選択する事ができれば命令処理部分の修正をほぼせずにThrededCodeを実現する事が可能である. | 420 その為CodeSegmentをThrededCodeに対応した並びとして選択する事ができれば命令処理部分の修正をほぼせずにThrededCodeを実現する事が可能である. |
421 | 421 |
422 またCodeSegmentはバイトコードレベルと同じ扱いができるため,ThrededCodeそのものを分離して最適化をかける事が可能である. | 422 またCodeSegmentはバイトコードレベルと同じ扱いができるため,ThrededCodeそのものを分離して最適化をかける事が可能である. |
423 これもCodeSegmentが関数単位として分離できる事からの利点である. | 423 これもCodeSegmentが関数単位として分離できる事からの利点である. |
424 | 424 |
425 | 425 |
426 \subsubsection{MoarVMのデバッグ} | 426 \subsubsection{MoarVMのデバッグ} |
427 MoarVMのバイトコードインタプリタの箇所はオリジナルの実装ではラベルジャンプを用いて実装されている. | 427 MoarVMのバイトコードインタプリタの箇所はオリジナルの実装ではラベルジャンプを用いて実装されている. |
428 その為,直接ラベルにbreak pointをかける事が出来ない. | 428 その為,直接ラベルにbreak pointをかける事が出来ない. |
429 作業者がデバッガが読み込んでいるCソースコードの位置を把握し,行番号を指定してdebug pointを設定する必要があった. | 429 作業者がデバッガが読み込んでいるCソースコードの位置を把握し,行番号を指定してdebug pointを設定する必要があった. |
430 | 430 |
431 CbCMoarVMの場合,CodeSegment単位でバイトコードの処理単位を記述している為,通常の関数と同じく直接CodeSegmentにデバッグポイントをかける事が可能である. | 431 CbCMoarVMの場合,CodeSegment単位でバイトコードの処理単位を記述している為,通常の関数と同じく直接CodeSegmentにデバッグポイントをかける事が可能である. |
432 これはCプログラミングの関数に対してのデバッグで,状態ごとにbreak pointをかける事が出来ることを意味する. | 432 これはCプログラミングの関数に対してのデバッグで,状態ごとにbreak pointをかける事が出来ることを意味する. |
433 通常のC言語で言語処理系を実装した場合と比較して扱いやすくなっていると言える. | 433 通常のC言語で言語処理系を実装した場合と比較して扱いやすくなっていると言える. |
434 さらにラベルテーブルでの管理場合,次のバイトコード箇所は数値でしか確認できず,実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった. | 434 さらにラベルテーブルでの管理場合,次のバイトコード箇所は数値でしか確認できず,実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった. |
435 スクリプトなどを組めば効率化は出来るがデバッガ上で完結しない為手間がかかる. | 435 スクリプトなどを組めば効率化は出来るがデバッガ上で完結しない為手間がかかる. |
436 CbC実装ではCODESテーブル内は次のCodeSegmentの名前が入っている為,数値からCodeSegmentの名前をデバッガ上で確認する事が出来る. | 436 CbC実装ではCODESテーブル内は次のCodeSegmentの名前が入っている為,数値からCodeSegmentの名前をデバッガ上で確認する事が出来る. |
437 | 437 |
438 \subsection{JITコンパイルの応用} | 438 \subsection{JITコンパイルの応用} |
439 現在MoarVMはLuaJit\cite{luajit}を搭載しJITコンパイルを行っている. | 439 現在MoarVMはLuaJit\cite{luajit}を搭載しJITコンパイルを行っている. |
440 LuaJITそのものをCbCに適応させるわけではないが,CbCのABIにJITされたコードを合わせる事が可能であると推測できる. | 440 LuaJITそのものをCbCに適応させるわけではないが,CbCのABIにJITされたコードを合わせる事が可能であると推測できる. |
441 % \subsection{単純なループ処理の測定} | 441 % \subsection{単純なループ処理の測定} |
442 % 簡単な例題としてfor文を用いて100000回ループさせ,ある変数をインクリメントするというプログラムを作成する. | 442 % 簡単な例題としてfor文を用いて100000回ループさせ,ある変数をインクリメントするというプログラムを作成する. |
443 % 今回の評価対象としてPerl6は2018年4月にリリースされたMoarVM,NQP,Rakudoの実装を用いる. | 443 % 今回の評価対象としてPerl6は2018年4月にリリースされたMoarVM,NQP,Rakudoの実装を用いる. |
444 % Perl5は5.26.2を利用した. | 444 % Perl5は5.26.2を利用した. |
445 | 445 |
446 % \begin{table}[htb] | 446 % \begin{table}[htb] |
447 % \begin{tabular}{|c|c|c|} \hline | 447 % \begin{tabular}{|c|c|c|} \hline |
451 % 100000000 & 3.258 & 124.69 \\ \hline | 451 % 100000000 & 3.258 & 124.69 \\ \hline |
452 % \end{tabular} | 452 % \end{tabular} |
453 % \end{table} | 453 % \end{table} |
454 | 454 |
455 \subsection{欠点} | 455 \subsection{欠点} |
456 本来処理系は広く使われる為に著名なOSSなどを利用して開発するのが良いが,CbCプロジェクトの認知度が低いという現状がある. | 456 本来処理系は広く使われる為に著名なOSSなどを利用して開発するのが良いが,CbCプロジェクトの認知度が低いという現状がある. |
457 | 457 |
458 また,前章までに複数述べた通りCbCコンパイラが現在非常にバグを発生させやすい状態になっている. | 458 また,前章までに複数述べた通りCbCコンパイラが現在非常にバグを発生させやすい状態になっている. |
459 CbCコンパイラはgccとllvm/clangに実装している為,これらのアップデートに追従する必要がある. | 459 CbCコンパイラはgccとllvm/clangに実装している為,これらのアップデートに追従する必要がある. |
460 しかしコンパイラのバージョンに応じてCbCで利用するコンパイラ内のAPIが異なる場合が多く,APIの変更に伴う修正作業などを行う必要がある. | 460 しかしコンパイラのバージョンに応じてCbCで利用するコンパイラ内のAPIが異なる場合が多く,APIの変更に伴う修正作業などを行う必要がある. |
461 | 461 |
462 CbCMoarVMではCからCodeSegmentへ,CodeSegmentからCへの遷移などが複数回繰り返されているが,この処理中のCodeSegmentでのtail callの強制が非常に難関である. | 462 CbCMoarVMではCからCodeSegmentへ,CodeSegmentからCへの遷移などが複数回繰り返されているが,この処理中のCodeSegmentでのtail callの強制が非常に難関である. |
463 tail callの強制には関数定義の箇所や引数,スタック領域のサイズ修正などを行う必要がある. | 463 tail callの強制には関数定義の箇所や引数,スタック領域のサイズ修正などを行う必要がある. |
464 現在のバグではCodeSegment内部での不要なスタック操作命令を完全に排除しきれていない. | 464 現在のバグではCodeSegment内部での不要なスタック操作命令を完全に排除しきれていない. |
465 | 465 |
466 またCodeSegmentからCに帰る場合,環境付き継続を行う必要がある. | 466 またCodeSegmentからCに帰る場合,環境付き継続を行う必要がある. |
467 Cの関数の末尾でCodeSegmentを呼び出している場合など環境付き継続を使用しなくても良いケースは存在するが,頻繁にCとCbCを行き来する場合記述が冗長になる可能性はある. | 467 Cの関数の末尾でCodeSegmentを呼び出している場合など環境付き継続を使用しなくても良いケースは存在するが,頻繁にCとCbCを行き来する場合記述が冗長になる可能性はある. |
468 | 468 |
469 \section{今後の課題} | 469 \section{今後の課題} |
470 本論文ではCbCによってPerl6の処理系であるMoarVMインタプリタの一部改良とその手法を示した. | 470 本論文ではCbCによってPerl6の処理系であるMoarVMインタプリタの一部改良とその手法を示した. |
471 CbCのCodeSegment部分を用いることできめ細やかな記述が出来,デバッグし辛い箇所もbreakpointの設定などが容易になった. | 471 CbCのCodeSegment部分を用いることできめ細やかな記述が出来,デバッグし辛い箇所もbreakpointの設定などが容易になった. |
472 | 472 |
473 今後CbCでの開発をより深く行っていくにあたり,CbCコンパイラそのものの信頼性を向上させる必要がある. | 473 今後CbCでの開発をより深く行っていくにあたり,CbCコンパイラそのものの信頼性を向上させる必要がある. |
474 MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラにする為に改良を行う. | 474 MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラにする為に改良を行う. |
475 | 475 |
476 現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストは\%パスする. | 476 現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストは\%パスする. |
477 また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,moarvmでバイトコード化したものを入力した際も正常に動作している. | 477 また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,moarvmでバイトコード化したものを入力した際も正常に動作している. |
478 今後はさらに複雑な例題やPerl6の独自文法でも動くかどうかの実験を行う. | 478 今後はさらに複雑な例題やPerl6の独自文法でも動くかどうかの実験を行う. |
479 | 479 |
480 MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し,局所変数のポインタをスタックに登録する処理を行っている. | 480 MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し,局所変数のポインタをスタックに登録する処理を行っている. |
481 GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeSegmentの優位性が損なわれてしまう. | 481 GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeSegmentの優位性が損なわれてしまう. |
482 従ってMoarVMのGCの最適化を行う. | 482 従ってMoarVMのGCの最適化を行う. |
483 | 483 |
484 また高速化という面では,Perlの特徴である正規表現に着目し,正規表現の表現のみ高速で動く最適化の導入なども検討している. | 484 また高速化という面では,Perlの特徴である正規表現に着目し,正規表現の表現のみ高速で動く最適化の導入なども検討している. |
485 他にrakudoのコンパイラ系統からCbCのコードを直接生成させ,それをllvmでコンパイルすることによってLLVMの最適化フェーズを得て | 485 他にrakudoのコンパイラ系統からCbCのコードを直接生成させ,それをllvmでコンパイルすることによってLLVMの最適化フェーズを得て |
486 高速化することも可能であると推測できる. | 486 高速化することも可能であると推測できる. |
487 | 487 |
488 Perl6の開発は非常に活発に行われている為,CbCMoarVMの最新版の追従も課題となっている. | 488 Perl6の開発は非常に活発に行われている為,CbCMoarVMの最新版の追従も課題となっている. |
489 現在はinterp.cからPerlスクリプトを用いて自動でCbCのCodeSegmentを生成している. | 489 現在はinterp.cからPerlスクリプトを用いて自動でCbCのCodeSegmentを生成している. |
490 今後の開発領域の拡大と共により効率的にCbCコードへの自動変換も複数のCコードに対応する様に開発を行っていく. | 490 今後の開発領域の拡大と共により効率的にCbCコードへの自動変換も複数のCコードに対応する様に開発を行っていく. |
491 | 491 |
492 %å\subsection{MoarVMの処理流れ} | 492 %å\subsection{MoarVMの処理流れ} |
493 %MoarVMはC言語で実装されており,Perl5で記述されたConfigure.plを | 493 %MoarVMはC言語で実装されており,Perl5で記述されたConfigure.plを |