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>