Mercurial > hg > Papers > 2019 > anatofuz-thesis
changeset 93:9c5bf7231557
update
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 19 Feb 2019 14:49:04 +0900 |
parents | 007079c53a83 |
children | 19df48819b8d |
files | presen/slide.html presen/slide.md presen/slide.pdf.html |
diffstat | 3 files changed, 120 insertions(+), 117 deletions(-) [+] |
line wrap: on
line diff
--- a/presen/slide.html Tue Feb 19 14:36:26 2019 +0900 +++ b/presen/slide.html Tue Feb 19 14:49:04 2019 +0900 @@ -191,8 +191,20 @@ <h2 id="rakudo">Rakudo</h2> <ul> <li>Rakudoとは現在のPerl6の主力な実装である.</li> - <li>実行環境のVM, Perl6のサブセットであるNQP(NotQuitPerl), NQPで記述されたPerl6(Rakudo)という構成になっている.</li> - <li>コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である</li> + <li>Rakudoは次の構成になっている + <ul> + <li>実行環境のVM</li> + <li>Perl6のサブセットであるNQP(NotQuitPerl)</li> + <li>NQPで記述されたPerl6(Rakudo)</li> + </ul> + </li> + <li>コンパイラも複数存在する + <ul> + <li>NQPで記述されたNQPコンパイラ</li> + <li>NQPで記述されたPerl6コンパイラ</li> + <li>MoarVMバイトコードを解釈するMoarVM</li> + </ul> + </li> </ul> @@ -232,17 +244,34 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="moarvmのバイトコードインタプリタ">MoarVMのバイトコードインタプリタ</h2> +<ul> + <li>バイトコードは連続したメモリに確保されている</li> + <li>その為次の処理を繰り返す必要がある + <ul> + <li>16ビットごとで読み込み</li> + <li>読み込んだビットから、命令に対応する処理を呼び出し</li> + <li>その処理を実行する</li> + </ul> + </li> + <li>この処理をバイトコードディスパッチと呼び、 実行する部分をバイトコードインタプリタと呼ぶ</li> +</ul> + + + +</div> + +<div class='slide'> + <!-- _S9SLIDE_ --> +<h2 id="moarvmのバイトコードインタプリタ-1">MoarVMのバイトコードインタプリタ</h2> <ul> - <li> - MoarVMはバイトコードインタプリタを <code>src/core/interp.c</code> で定義しており, この中の関数 <code>MVM_interp_run</code> でバイトコードに応じた処理を実行する - </li> - <li>マクロDISPATCHで, ラベルgotoかcase文に, バイトコードに対応した処理を行う + <li>MoarVMは関数 <code>MVM_interp_run</code> でバイトコードに応じた処理を実行する</li> + <li>マクロDISPATCHで, ラベルgotoかcase文に変換が行われる <ul> + <li>バイトコードは数値として見る事が出来る為、 case文に対応する事が出来る</li> <li>この中の <code>OP</code> で宣言されたブロックがそれぞれバイトコードに対応する処理となっている.</li> </ul> </li> - <li>この中では <code>GET_REG</code> などのマクロを用いてMoarVMのレジスタにアクセスする.</li> <li><code>cur_op</code>は次のバイトコード列が登録されており, マクロ <code>NEXT</code> で決められた方法で次のバイトコードに対応した処理に遷移する.</li> </ul> @@ -268,7 +297,7 @@ </code></pre> <ul> - <li>マクロ <code>DISPATCH</code> 及び <code>OP</code> は次の様に定義している</li> + <li>マクロ <code>OP</code> 及び <code>NEXT</code> は次の様に定義している</li> </ul> <pre><code> #define OP(name) OP_ ## name @@ -292,36 +321,6 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="mvm_interp_runのマクロ">MVM_interp_runのマクロ</h2> - -<ul> - <li>MVM_interp_runではマクロを利用してMoarVMの環境などにアクセスしている</li> - <li>頻出するマクロに <code>GET_REG</code> があり, 次のような使い方をする</li> -</ul> - -<pre><code> OP(const_i64): - GET_REG(cur_op, 0).i64 = MVM_BC_get_I64(cur_op, 2); - cur_op += 10; -</code></pre> - -<ul> - <li><code>GET_REG</code>はバイトコードに埋められた数値を利用して, レジスタ情報を取得/設定などをする</li> - <li><code>GET_REG</code>は次の様に展開される</li> -</ul> - -<pre><code> reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2); -</code></pre> - -<ul> - <li><code>reg_base</code> はMoarVMの現在のフレームのレジスタ情報が保存されたポインタであり, MVM_interp_runではローカル変数として利用している</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> <h2 id="mvm_interp_runで使用されているマクロ-1">MVM_interp_runで使用されているマクロ</h2> <ul> @@ -350,7 +349,9 @@ <h2 id="mvm_interp_runのラベルテーブル">MVM_interp_runのラベルテーブル</h2> <ul> - <li>ラベル遷移を利用する場合は配列<code>LABELS</code>にアクセスし, ラベル情報を取得する</li> + <li>利用するCコンパイラが、ラベルgotoをサポートしている場合に実行される</li> + <li>配列<code>LABELS</code>にアクセスし, ラベル情報を取得する</li> + <li>ラベル情報を取得出来ると、 そのラベルに対してラベルgotoを利用する</li> </ul> <pre><code>static const void * const LABELS[] = { @@ -379,12 +380,13 @@ <h2 id="mvm_interp_run">MVM_interp_run</h2> <ul> - <li>Cの実装の場合, switch文に展開される可能性がある為, 命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない + <li>Cの実装の場合, switch文に展開される可能性がある <ul> - <li>その為, 1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない</li> + <li>命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない</li> + <li>1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない</li> </ul> </li> - <li>Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある.</li> + <li>高速化手法の、 Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある.</li> <li>デバッグ時には今どの命令を実行しているか, ラベルテーブルを利用して参照せざるを得ず, 手間がかかる.</li> </ul> @@ -397,6 +399,8 @@ <h2 id="cbcmoarvmのバイトコードディスパッチ">CbCMoarVMのバイトコードディスパッチ</h2> <ul> + <li>CbCのCodeGearは関数よりも小さな単位である</li> + <li>その為、 従来は関数化出来なかった単位をCodeGearに変換する事が出来る</li> <li>CbCをMoarVMに適応すると, ラベルなどで制御していた命令に対応する処理をCodeGearで記述する事が可能である</li> <li>オリジナルでは, マクロ <code>NEXT</code> が担当していた, 次のバイトコードへの移動は, NEXT相当のCodeGear <code>cbc_next</code>で処理を行う</li> <li>CodeGearの入出力として, MoarVMなどの情報をまとめた構造体を利用する</li>
--- a/presen/slide.md Tue Feb 19 14:36:26 2019 +0900 +++ b/presen/slide.md Tue Feb 19 14:49:04 2019 +0900 @@ -60,8 +60,14 @@ ## Rakudo - Rakudoとは現在のPerl6の主力な実装である. -- 実行環境のVM, Perl6のサブセットであるNQP(NotQuitPerl), NQPで記述されたPerl6(Rakudo)という構成になっている. -- コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である +- Rakudoは次の構成になっている + - 実行環境のVM + - Perl6のサブセットであるNQP(NotQuitPerl) + - NQPで記述されたPerl6(Rakudo) +- コンパイラも複数存在する + - NQPで記述されたNQPコンパイラ + - NQPで記述されたPerl6コンパイラ + - MoarVMバイトコードを解釈するMoarVM ## MoarVM @@ -75,20 +81,25 @@ - MoarVMは16ビットのバイナリを命令バイトコードとして利用している - 命令にはその後に16ビットごとにオペランド(引数)を取るものがある - ``` add_i loc_3_int, loc_0_int, loc_1_int set loc_2_obj, loc_3_obj ``` +## MoarVMのバイトコードインタプリタ +- バイトコードは連続したメモリに確保されている +- その為次の処理を繰り返す必要がある + - 16ビットごとで読み込み + - 読み込んだビットから、命令に対応する処理を呼び出し + - その処理を実行する +- この処理をバイトコードディスパッチと呼び、 実行する部分をバイトコードインタプリタと呼ぶ ## MoarVMのバイトコードインタプリタ -- MoarVMはバイトコードインタプリタを `src/core/interp.c` で定義しており, この中の関数 `MVM_interp_run` でバイトコードに応じた処理を実行する - -- マクロDISPATCHで, ラベルgotoかcase文に, バイトコードに対応した処理を行う +- MoarVMは関数 `MVM_interp_run` でバイトコードに応じた処理を実行する +- マクロDISPATCHで, ラベルgotoかcase文に変換が行われる + - バイトコードは数値として見る事が出来る為、 case文に対応する事が出来る - この中の `OP` で宣言されたブロックがそれぞれバイトコードに対応する処理となっている. -- この中では `GET_REG` などのマクロを用いてMoarVMのレジスタにアクセスする. - `cur_op`は次のバイトコード列が登録されており, マクロ `NEXT` で決められた方法で次のバイトコードに対応した処理に遷移する. ``` @@ -108,7 +119,7 @@ OP(const_i64): ``` -- マクロ `DISPATCH` 及び `OP` は次の様に定義している +- マクロ `OP` 及び `NEXT` は次の様に定義している ``` #define OP(name) OP_ ## name @@ -126,27 +137,6 @@ OP_const_i64: ``` -## MVM_interp_runのマクロ - -- MVM_interp_runではマクロを利用してMoarVMの環境などにアクセスしている -- 頻出するマクロに `GET_REG` があり, 次のような使い方をする - -``` - OP(const_i64): - GET_REG(cur_op, 0).i64 = MVM_BC_get_I64(cur_op, 2); - cur_op += 10; -``` - - -- `GET_REG`はバイトコードに埋められた数値を利用して, レジスタ情報を取得/設定などをする -- `GET_REG`は次の様に展開される - -``` - reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2); -``` - -- `reg_base` はMoarVMの現在のフレームのレジスタ情報が保存されたポインタであり, MVM_interp_runではローカル変数として利用している - ## MVM_interp_runで使用されているマクロ - 次のバイトコード命令に遷移するマクロ `NEXT` は, ラベルgotoが使用可能な場合次の様に記述されている @@ -167,7 +157,9 @@ ## MVM_interp_runのラベルテーブル -- ラベル遷移を利用する場合は配列`LABELS`にアクセスし, ラベル情報を取得する +- 利用するCコンパイラが、ラベルgotoをサポートしている場合に実行される +- 配列`LABELS`にアクセスし, ラベル情報を取得する +- ラベル情報を取得出来ると、 そのラベルに対してラベルgotoを利用する ``` static const void * const LABELS[] = { @@ -190,15 +182,18 @@ ## MVM_interp_run -- Cの実装の場合, switch文に展開される可能性がある為, 命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない - - その為, 1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない -- Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある. +- Cの実装の場合, switch文に展開される可能性がある + - 命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない + - 1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない +- 高速化手法の、 Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある. - デバッグ時には今どの命令を実行しているか, ラベルテーブルを利用して参照せざるを得ず, 手間がかかる. ## CbCMoarVMのバイトコードディスパッチ +- CbCのCodeGearは関数よりも小さな単位である +- その為、 従来は関数化出来なかった単位をCodeGearに変換する事が出来る - CbCをMoarVMに適応すると, ラベルなどで制御していた命令に対応する処理をCodeGearで記述する事が可能である - オリジナルでは, マクロ `NEXT` が担当していた, 次のバイトコードへの移動は, NEXT相当のCodeGear `cbc_next`で処理を行う - CodeGearの入出力として, MoarVMなどの情報をまとめた構造体を利用する
--- a/presen/slide.pdf.html Tue Feb 19 14:36:26 2019 +0900 +++ b/presen/slide.pdf.html Tue Feb 19 14:49:04 2019 +0900 @@ -175,8 +175,20 @@ <h2 id="rakudo">Rakudo</h2> <ul> <li>Rakudoとは現在のPerl6の主力な実装である.</li> - <li>実行環境のVM, Perl6のサブセットであるNQP(NotQuitPerl), NQPで記述されたPerl6(Rakudo)という構成になっている.</li> - <li>コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である</li> + <li>Rakudoは次の構成になっている + <ul> + <li>実行環境のVM</li> + <li>Perl6のサブセットであるNQP(NotQuitPerl)</li> + <li>NQPで記述されたPerl6(Rakudo)</li> + </ul> + </li> + <li>コンパイラも複数存在する + <ul> + <li>NQPで記述されたNQPコンパイラ</li> + <li>NQPで記述されたPerl6コンパイラ</li> + <li>MoarVMバイトコードを解釈するMoarVM</li> + </ul> + </li> </ul> @@ -216,17 +228,34 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="moarvmのバイトコードインタプリタ">MoarVMのバイトコードインタプリタ</h2> +<ul> + <li>バイトコードは連続したメモリに確保されている</li> + <li>その為次の処理を繰り返す必要がある + <ul> + <li>16ビットごとで読み込み</li> + <li>読み込んだビットから、命令に対応する処理を呼び出し</li> + <li>その処理を実行する</li> + </ul> + </li> + <li>この処理をバイトコードディスパッチと呼び、 実行する部分をバイトコードインタプリタと呼ぶ</li> +</ul> + + + +</div> + +<div class='slide'> + <!-- _S9SLIDE_ --> +<h2 id="moarvmのバイトコードインタプリタ-1">MoarVMのバイトコードインタプリタ</h2> <ul> - <li> - <p>MoarVMはバイトコードインタプリタを <code>src/core/interp.c</code> で定義しており, この中の関数 <code>MVM_interp_run</code> でバイトコードに応じた処理を実行する</p> - </li> - <li>マクロDISPATCHで, ラベルgotoかcase文に, バイトコードに対応した処理を行う + <li>MoarVMは関数 <code>MVM_interp_run</code> でバイトコードに応じた処理を実行する</li> + <li>マクロDISPATCHで, ラベルgotoかcase文に変換が行われる <ul> + <li>バイトコードは数値として見る事が出来る為、 case文に対応する事が出来る</li> <li>この中の <code>OP</code> で宣言されたブロックがそれぞれバイトコードに対応する処理となっている.</li> </ul> </li> - <li>この中では <code>GET_REG</code> などのマクロを用いてMoarVMのレジスタにアクセスする.</li> <li><code>cur_op</code>は次のバイトコード列が登録されており, マクロ <code>NEXT</code> で決められた方法で次のバイトコードに対応した処理に遷移する.</li> </ul> @@ -252,7 +281,7 @@ </code></pre> <ul> - <li>マクロ <code>DISPATCH</code> 及び <code>OP</code> は次の様に定義している</li> + <li>マクロ <code>OP</code> 及び <code>NEXT</code> は次の様に定義している</li> </ul> <pre><code> #define OP(name) OP_ ## name @@ -276,36 +305,6 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="mvm_interp_runのマクロ">MVM_interp_runのマクロ</h2> - -<ul> - <li>MVM_interp_runではマクロを利用してMoarVMの環境などにアクセスしている</li> - <li>頻出するマクロに <code>GET_REG</code> があり, 次のような使い方をする</li> -</ul> - -<pre><code> OP(const_i64): - GET_REG(cur_op, 0).i64 = MVM_BC_get_I64(cur_op, 2); - cur_op += 10; -</code></pre> - -<ul> - <li><code>GET_REG</code>はバイトコードに埋められた数値を利用して, レジスタ情報を取得/設定などをする</li> - <li><code>GET_REG</code>は次の様に展開される</li> -</ul> - -<pre><code> reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2); -</code></pre> - -<ul> - <li><code>reg_base</code> はMoarVMの現在のフレームのレジスタ情報が保存されたポインタであり, MVM_interp_runではローカル変数として利用している</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> <h2 id="mvm_interp_runで使用されているマクロ-1">MVM_interp_runで使用されているマクロ</h2> <ul> @@ -334,7 +333,9 @@ <h2 id="mvm_interp_runのラベルテーブル">MVM_interp_runのラベルテーブル</h2> <ul> - <li>ラベル遷移を利用する場合は配列<code>LABELS</code>にアクセスし, ラベル情報を取得する</li> + <li>利用するCコンパイラが、ラベルgotoをサポートしている場合に実行される</li> + <li>配列<code>LABELS</code>にアクセスし, ラベル情報を取得する</li> + <li>ラベル情報を取得出来ると、 そのラベルに対してラベルgotoを利用する</li> </ul> <pre><code>static const void * const LABELS[] = { @@ -363,12 +364,13 @@ <h2 id="mvm_interp_run">MVM_interp_run</h2> <ul> - <li>Cの実装の場合, switch文に展開される可能性がある為, 命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない + <li>Cの実装の場合, switch文に展開される可能性がある <ul> - <li>その為, 1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない</li> + <li>命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない</li> + <li>1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない</li> </ul> </li> - <li>Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある.</li> + <li>高速化手法の、 Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある.</li> <li>デバッグ時には今どの命令を実行しているか, ラベルテーブルを利用して参照せざるを得ず, 手間がかかる.</li> </ul> @@ -381,6 +383,8 @@ <h2 id="cbcmoarvmのバイトコードディスパッチ">CbCMoarVMのバイトコードディスパッチ</h2> <ul> + <li>CbCのCodeGearは関数よりも小さな単位である</li> + <li>その為、 従来は関数化出来なかった単位をCodeGearに変換する事が出来る</li> <li>CbCをMoarVMに適応すると, ラベルなどで制御していた命令に対応する処理をCodeGearで記述する事が可能である</li> <li>オリジナルでは, マクロ <code>NEXT</code> が担当していた, 次のバイトコードへの移動は, NEXT相当のCodeGear <code>cbc_next</code>で処理を行う</li> <li>CodeGearの入出力として, MoarVMなどの情報をまとめた構造体を利用する</li>