# HG changeset patch # User Takahiro SHIMIZU # Date 1547182781 -32400 # Node ID 38ab79fff39625dea6fc62377a06f6f3600072ea # Parent 01f148c3de989bd1a66c13f651df6e5adc4e6d21 update diff -r 01f148c3de98 -r 38ab79fff396 Slide/slide.html --- a/Slide/slide.html Fri Jan 11 11:47:04 2019 +0900 +++ b/Slide/slide.html Fri Jan 11 13:59:41 2019 +0900 @@ -178,6 +178,8 @@
  • コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である
    • + + @@ -259,7 +261,6 @@ OP_const_i32: MVM_exception_throw_adhoc(tc, "const_iX NYI"); OP_const_i64: - @@ -286,7 +287,6 @@ 
            reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2);
-
    -
    dalmore gdb --args ../../MoarVM_Original/
-     MoarVM/moar --libpath=src/vm/moar/stage0
-     gen/moar/stage1/nqp
+
    dalmore gdb --args ../../MoarVM_Original/MoarVM/moar --libpath=src/vm/moar/stage0  gen/moar/stage1/nqp
 (gdb) b dummy
 Function "dummy" not defined.
-Make breakpoint pending on future shared
-     library load? (y or [n]) y
+Make breakpoint pending on future shared library load? (y or [n]) y
 Breakpoint 1 (dummy) pending.
 (gdb) command 1
-Type commands for breakpoint(s) 1, one per
-     line.
+Type commands for breakpoint(s) 1, one per line.
 End with a line saying just "end".
 >up
 >p *(MVMuint16 *)(cur_op)
 >c
 >end
+
 
    
 
 
@@ -591,27 +631,20 @@
   
  • デバッガに, breakpointで停止した際のcur_opの値を表示する様に設定する．
    • 
 
 
-
    Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75608fe in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+
    Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75608fe in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10)
     at src/core/interp.c:119
-119 goto NEXT;
+119	                goto NEXT;
 $1 = 159
-Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75689da in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+
+Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75689da in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10)
     at src/core/interp.c:1169
-1169 goto NEXT;
+1169	                goto NEXT;
 $2 = 162
 
    
 
@@ -621,6 +654,32 @@
 
 
    
   
+
    CbCMoarVMのデバッグ
    
+
+
    Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$1 = (void (*)(INTERP)) 0x7ffff7566f53 <cbc_takeclosure>
+$2 = 162
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$3 = (void (*)(INTERP)) 0x7ffff7565f86 <cbc_checkarity>
+$4 = 140
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$5 = (void (*)(INTERP)) 0x7ffff7579d06 <cbc_paramnamesused>
+$6 = 558
+
+
+
    
+
+
+
+
    
+
+
    
+  
 
    MoarVMのデバッグ
    
 
 
      
@@ -665,39 +724,6 @@
 
 
      
   
-
      CbCMoarVMの利点
      
-
-
        
-  
      • バイトコードインタプリタの箇所をモジュール化する事が可能となり, CodeGearの再利用性や記述生が高まる
        • 
-  
      • デバッグ時にラベルではなくCodeGearにbreakpointを設定可能となり，デバッグが安易となる
        • 
-  
      • ThreadedCodeを実装する場合, CodeGearを組み合わせることにより実装する事が可能となる
        • 
-
      
-
-
-
-
      
-
-
      
-  
-
      CbCMoarVMの欠点
      
-
-
        
-  
      • CbCコンパイラがバグを発生させやすく, 意図しない挙動を示す事がある
-    
          
-      
        • CbCコンパイラ自体のバグも存在する
          • 
-    
        
-  
        • 
-  
      • MoarVMのオリジナルの更新頻度が高い為, 追従していく必要がある
        • 
-  
      • CodeGear側からCに戻る際に手順が複雑となる
        • 
-  
      • CodeGearを単位として用いる事で複雑なプログラミングが要求される.
        • 
-
      
-
-
-
-
      
-
-
      
-  
 
      ThreadedCodeの実装
      
 
 
        
@@ -734,14 +760,11 @@
     $n < 2 ?? $n !! fib($n-1) + fib($n - 2);
 }
 
-my $N := 29;
+my $N := 30;
 
-my $t0 := nqp::time_n();
 my $z  := fib($N);
-my $t1 := nqp::time_n();
 
 say("fib($N) = " ~ fib($N));
-say("time    = " ~ ($t1-$t0));
 
 
    
 
@@ -753,6 +776,20 @@
 
    フィボナッチの例題
    
 
 
      
+  
    • オリジナル
+    
        
+      
      • 1.379 sec
        • 
+      
      • 1.350 sec
        • 
+      
      • 1.346 sec
        • 
+    
      
+  
      • 
+  
    • CbCMoarVM
+    
        
+      
      • 1.636 sec
        • 
+      
      • 1.804 sec
        • 
+      
      • 1.787 sec
        • 
+    
      
+  
      • 
   
    • フィボナッチの例題ではCbCMoarVMが劣る結果となった
      • 
 
    
 
@@ -769,7 +806,7 @@
     
      
       
    • 7.499 sec
      • 
       
    • 7.844 sec
      • 
-      
    • 6.074 sec
      • 
+      
    • 6.746 sec
      • 
     
    
   
   
  • CbCMoarVM
@@ -788,26 +825,34 @@
 
 
    
   
-
    まとめ
    
-
-
      
-  
    • 速度を計測した所, 現在はCbCMoarVMの方が僅かに劣る結果となった
      • 
-  
    • ただしフィボナッチを求める例題などで, ケースによってはCbCMoarVMの方が高速に動作する場合もある
      • 
-
    
-
-
-
-
    
-
-
    
-  
 
    基本ブロックとCodeGear
    
 
 
      
   
    • コンパイラなどでは, 関数あるいはループの先頭から, 別の関数呼び出し, あるいはジャンプするまでの間のコードを基本ブロックと呼ぶ
      • 
   
    • 基本ブロックは入力に影響を受けず, 基本ブロックが決定したタイミングである決定的な処理を行う
      • 
+  
    • 予め実行する基本ブロックが確定していれば, その部分のみ抜き出してコンパイルする事が可能である
      • 
+  
    • CbCのCodeGearは, この基本ブロックとみなす事が可能である
      • 
+  
    • その為, NQPの例題の様に, 予め実行する基本ブロックが確定すれば, その部分の処理が可能となる
      • 
+  
    • これを行うことで, CbCを用いてMoarVMのThreadedCode実装が可能となる
      • 
 
    
 
+
    __code cbc_const_i64(INTERP i,__code cbc_next(INTERP i)){
+    GET_REG(i->cur_op, 0,i).i64 = MVM_BC_get_I64(i->cur_op, 2);
+    i->cur_op += 10;
+    goto cbc_next(i);
+}
+
+goto cbc_const_i64_16(i,cbc_gt_i_01);
+
+__code cbc_gt_i_01(INTERP i){
+	goto cbc_gt_i(i,cbc_unless_i_01);
+}
+
+__code cbc_unless_i_01(INTERP i,cbc_osrpoint_01){
+	goto cbc_unless_i(i,cbc_osrpoint_01);
+}
+
    
+
 
 
 
    
diff -r 01f148c3de98 -r 38ab79fff396 Slide/slide.md
--- a/Slide/slide.md	Fri Jan 11 11:47:04 2019 +0900
+++ b/Slide/slide.md	Fri Jan 11 13:59:41 2019 +0900
@@ -57,6 +57,9 @@
 - コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である
 
 
+
+
+
 ## MoarVM
 
 - Perl6専用のVMであり, Cで記述されている
@@ -116,7 +119,6 @@
     OP_const_i32:
         MVM_exception_throw_adhoc(tc, "const_iX NYI");
     OP_const_i64:
-
 ```
 
 ## MVM_interp_runのマクロ
@@ -136,7 +138,6 @@
 
 ```
         reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2);
-
 ```
 
 - `reg_base` はMoarVMの現在のフレームのレジスタ情報が保存されたポインタであり, MVM_interp_runではローカル変数として利用している
@@ -305,6 +306,25 @@
 00021      goto               label_1(00007)
 ```
 
+## NQPのバイトコードとCbC
+
+- NQPが生成したMoarVMバイトコードは確実に次に実行される命令がある箇所が複数存在する
+- 静的にCのソースファイルに, NQPが生成したバイトコードと対応するCbCのCodeGearの実行を書くことで決定的に命令を実行可能でえある．
+
+## CbCMoarVMの利点
+
+- バイトコードインタプリタの箇所をモジュール化する事が可能となり, CodeGearの再利用性や記述生が高まる
+- デバッグ時にラベルではなくCodeGearにbreakpointを設定可能となり，デバッグが安易となる
+
+## CbCMoarVMの欠点
+
+- CbCコンパイラがバグを発生させやすく, 意図しない挙動を示す事がある
+    - CbCコンパイラ自体のバグも存在する
+- MoarVMのオリジナルの更新頻度が高い為, 追従していく必要がある
+- CodeGear側からCに戻る際に手順が複雑となる
+- CodeGearを単位として用いる事で複雑なプログラミングが要求される.
+
+
 
 ## MoarVMのデバッグ手法
 
@@ -320,11 +340,9 @@
 
 ```
 (gdb) b cbc_next
-Breakpoint 2 at 0x7ffff7560288: file src/core
-     /cbc-interp.cbc, line 61.
+Breakpoint 2 at 0x7ffff7560288: file src/core/cbc-interp.cbc, line 61.
 (gdb) command 2
-Type commands for breakpoint(s) 2, one per
-     line.
+Type commands for breakpoint(s) 2, one per line.
 End with a line saying just "end".
 >p CODES[*(MVMuint16 *)i->cur_op]
 >p *(MVMuint16 *)i->cur_op
@@ -334,22 +352,19 @@
 - オリジナルの場合マクロである為, dummy関数をマクロに記述し, この関数にbreakpointを設定する
 
 ```
-dalmore gdb --args ../../MoarVM_Original/
-     MoarVM/moar --libpath=src/vm/moar/stage0
-     gen/moar/stage1/nqp
+dalmore gdb --args ../../MoarVM_Original/MoarVM/moar --libpath=src/vm/moar/stage0  gen/moar/stage1/nqp
 (gdb) b dummy
 Function "dummy" not defined.
-Make breakpoint pending on future shared
-     library load? (y or [n]) y
+Make breakpoint pending on future shared library load? (y or [n]) y
 Breakpoint 1 (dummy) pending.
 (gdb) command 1
-Type commands for breakpoint(s) 1, one per
-     line.
+Type commands for breakpoint(s) 1, one per line.
 End with a line saying just "end".
 >up
 >p *(MVMuint16 *)(cur_op)
 >c
 >end
+
 ```
 
 ## MoarVMのトレース
@@ -358,30 +373,43 @@
 - デバッガに, breakpointで停止した際のcur_opの値を表示する様に設定する．
 
 ```
-Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75608fe in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75608fe in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 , invoke_data=0x67ff10)
     at src/core/interp.c:119
-119 goto NEXT;
+119	                goto NEXT;
 $1 = 159
-Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75689da in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+
+Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75689da in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 , invoke_data=0x67ff10)
     at src/core/interp.c:1169
-1169 goto NEXT;
+1169	                goto NEXT;
 $2 = 162
 ```
 
+## CbCMoarVMのデバッグ
+
+```
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$1 = (void (*)(INTERP)) 0x7ffff7566f53 
+$2 = 162
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$3 = (void (*)(INTERP)) 0x7ffff7565f86 
+$4 = 140
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$5 = (void (*)(INTERP)) 0x7ffff7579d06 
+$6 = 558
+
+
+```
 
 ## MoarVMのデバッグ
 
@@ -413,20 +441,6 @@
      /mnt/dalmore-home/one/src/Perl6/Optimize/llvm/build_perl6/share/nqp/lib/nqp.moarvm "$@"
 ```
 
-## CbCMoarVMの利点
-
-- バイトコードインタプリタの箇所をモジュール化する事が可能となり, CodeGearの再利用性や記述生が高まる
-- デバッグ時にラベルではなくCodeGearにbreakpointを設定可能となり，デバッグが安易となる
-- ThreadedCodeを実装する場合, CodeGearを組み合わせることにより実装する事が可能となる
-
-## CbCMoarVMの欠点
-
-- CbCコンパイラがバグを発生させやすく, 意図しない挙動を示す事がある
-    - CbCコンパイラ自体のバグも存在する
-- MoarVMのオリジナルの更新頻度が高い為, 追従していく必要がある
-- CodeGear側からCに戻る際に手順が複雑となる
-- CodeGearを単位として用いる事で複雑なプログラミングが要求される.
-
 ## ThreadedCodeの実装
 
 - MoarVM内のオペコードに対応する処理が分離出来たことにより, オペコードに該当するCodeGearを書き連ねることによってThreadedCodeが実装可能となる
@@ -456,18 +470,23 @@
     $n < 2 ?? $n !! fib($n-1) + fib($n - 2);
 }
 
-my $N := 29;
+my $N := 30;
 
-my $t0 := nqp::time_n();
 my $z  := fib($N);
-my $t1 := nqp::time_n();
 
 say("fib($N) = " ~ fib($N));
-say("time    = " ~ ($t1-$t0));
 
 ```
 ## フィボナッチの例題
 
+- オリジナル
+    - 1.379 sec
+    - 1.350 sec
+    - 1.346 sec
+- CbCMoarVM
+    - 1.636 sec
+    - 1.804 sec
+    - 1.787 sec
 - フィボナッチの例題ではCbCMoarVMが劣る結果となった
 
 
@@ -476,7 +495,7 @@
 - オリジナル
     - 7.499 sec
     - 7.844 sec
-    - 6.074 sec
+    - 6.746 sec
 - CbCMoarVM
     - 6.135 sec
     - 6.362 sec
@@ -484,15 +503,33 @@
 
 - 単純ループではCbCMoarVMの方が高速に動作する場合もある
 
-## まとめ
-
-- 速度を計測した所, 現在はCbCMoarVMの方が僅かに劣る結果となった
-- ただしフィボナッチを求める例題などで, ケースによってはCbCMoarVMの方が高速に動作する場合もある
 
 ## 基本ブロックとCodeGear
 
 - コンパイラなどでは, 関数あるいはループの先頭から, 別の関数呼び出し, あるいはジャンプするまでの間のコードを基本ブロックと呼ぶ
 - 基本ブロックは入力に影響を受けず, 基本ブロックが決定したタイミングである決定的な処理を行う
+- 予め実行する基本ブロックが確定していれば, その部分のみ抜き出してコンパイルする事が可能である
+- CbCのCodeGearは, この基本ブロックとみなす事が可能である
+- その為, NQPの例題の様に, 予め実行する基本ブロックが確定すれば, その部分の処理が可能となる
+- これを行うことで, CbCを用いてMoarVMのThreadedCode実装が可能となる
+
+```
+__code cbc_const_i64(INTERP i,__code cbc_next(INTERP i)){
+    GET_REG(i->cur_op, 0,i).i64 = MVM_BC_get_I64(i->cur_op, 2);
+    i->cur_op += 10;
+    goto cbc_next(i);
+}
+
+goto cbc_const_i64_16(i,cbc_gt_i_01);
+
+__code cbc_gt_i_01(INTERP i){
+	goto cbc_gt_i(i,cbc_unless_i_01);
+}
+
+__code cbc_unless_i_01(INTERP i,cbc_osrpoint_01){
+	goto cbc_unless_i(i,cbc_osrpoint_01);
+}
+```
 
 
 ## まとめと今後の課題
diff -r 01f148c3de98 -r 38ab79fff396 Slide/slide.pdf.html
--- a/Slide/slide.pdf.html	Fri Jan 11 11:47:04 2019 +0900
+++ b/Slide/slide.pdf.html	Fri Jan 11 13:59:41 2019 +0900
@@ -162,6 +162,8 @@
   
  • コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である
    • 
 
 
+
    
+
 
 
 
@@ -243,7 +245,6 @@
     OP_const_i32:
         MVM_exception_throw_adhoc(tc, "const_iX NYI");
     OP_const_i64:
-
    @@ -270,7 +271,6 @@ 
            reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2);
-
    -
    dalmore gdb --args ../../MoarVM_Original/
-     MoarVM/moar --libpath=src/vm/moar/stage0
-     gen/moar/stage1/nqp
+
    dalmore gdb --args ../../MoarVM_Original/MoarVM/moar --libpath=src/vm/moar/stage0  gen/moar/stage1/nqp
 (gdb) b dummy
 Function "dummy" not defined.
-Make breakpoint pending on future shared
-     library load? (y or [n]) y
+Make breakpoint pending on future shared library load? (y or [n]) y
 Breakpoint 1 (dummy) pending.
 (gdb) command 1
-Type commands for breakpoint(s) 1, one per
-     line.
+Type commands for breakpoint(s) 1, one per line.
 End with a line saying just "end".
 >up
 >p *(MVMuint16 *)(cur_op)
 >c
 >end
+
 
    
 
 
@@ -575,27 +615,20 @@
   
  • デバッガに, breakpointで停止した際のcur_opの値を表示する様に設定する．
    • 
 
 
-
    Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75608fe in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+
    Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75608fe in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10)
     at src/core/interp.c:119
-119 goto NEXT;
+119	                goto NEXT;
 $1 = 159
-Breakpoint 1, dummy () at src/core/interp.c
-     :46
-46 }
-#1 0x00007ffff75689da in MVM_interp_run (tc=0
-     x604a20,
-    initial_invoke=0x7ffff76c7168 <
-        toplevel_initial_invoke>, invoke_data
-        =0x67ff10)
+
+Breakpoint 1, dummy () at src/core/interp.c:46
+46	}
+#1  0x00007ffff75689da in MVM_interp_run (tc=0x604a20,
+    initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10)
     at src/core/interp.c:1169
-1169 goto NEXT;
+1169	                goto NEXT;
 $2 = 162
 
    
 
@@ -605,6 +638,32 @@
 
 
    
   
+
    CbCMoarVMのデバッグ
    
+
+
    Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$1 = (void (*)(INTERP)) 0x7ffff7566f53 <cbc_takeclosure>
+$2 = 162
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$3 = (void (*)(INTERP)) 0x7ffff7565f86 <cbc_checkarity>
+$4 = 140
+
+Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61
+61	    goto NEXT(i);
+$5 = (void (*)(INTERP)) 0x7ffff7579d06 <cbc_paramnamesused>
+$6 = 558
+
+
+
    
+
+
+
+
    
+
+
    
+  
 
    MoarVMのデバッグ
    
 
 
      
@@ -649,39 +708,6 @@
 
 
      
   
-
      CbCMoarVMの利点
      
-
-
        
-  
      • バイトコードインタプリタの箇所をモジュール化する事が可能となり, CodeGearの再利用性や記述生が高まる
        • 
-  
      • デバッグ時にラベルではなくCodeGearにbreakpointを設定可能となり，デバッグが安易となる
        • 
-  
      • ThreadedCodeを実装する場合, CodeGearを組み合わせることにより実装する事が可能となる
        • 
-
      
-
-
-
-
      
-
-
      
-  
-
      CbCMoarVMの欠点
      
-
-
        
-  
      • CbCコンパイラがバグを発生させやすく, 意図しない挙動を示す事がある
-    
          
-      
        • CbCコンパイラ自体のバグも存在する
          • 
-    
        
-  
        • 
-  
      • MoarVMのオリジナルの更新頻度が高い為, 追従していく必要がある
        • 
-  
      • CodeGear側からCに戻る際に手順が複雑となる
        • 
-  
      • CodeGearを単位として用いる事で複雑なプログラミングが要求される.
        • 
-
      
-
-
-
-
      
-
-
      
-  
 
      ThreadedCodeの実装
      
 
 
        
@@ -718,14 +744,11 @@
     $n < 2 ?? $n !! fib($n-1) + fib($n - 2);
 }
 
-my $N := 29;
+my $N := 30;
 
-my $t0 := nqp::time_n();
 my $z  := fib($N);
-my $t1 := nqp::time_n();
 
 say("fib($N) = " ~ fib($N));
-say("time    = " ~ ($t1-$t0));
 
 
    
 
@@ -737,6 +760,20 @@
 
    フィボナッチの例題
    
 
 
      
+  
    • オリジナル
+    
        
+      
      • 1.379 sec
        • 
+      
      • 1.350 sec
        • 
+      
      • 1.346 sec
        • 
+    
      
+  
      • 
+  
    • CbCMoarVM
+    
        
+      
      • 1.636 sec
        • 
+      
      • 1.804 sec
        • 
+      
      • 1.787 sec
        • 
+    
      
+  
      • 
   
    • フィボナッチの例題ではCbCMoarVMが劣る結果となった
      • 
 
    
 
@@ -753,7 +790,7 @@
     
      
       
    • 7.499 sec
      • 
       
    • 7.844 sec
      • 
-      
    • 6.074 sec
      • 
+      
    • 6.746 sec
      • 
     
    
   
   
  • CbCMoarVM
@@ -772,26 +809,34 @@
 
 
    
   
-
    まとめ
    
-
-
      
-  
    • 速度を計測した所, 現在はCbCMoarVMの方が僅かに劣る結果となった
      • 
-  
    • ただしフィボナッチを求める例題などで, ケースによってはCbCMoarVMの方が高速に動作する場合もある
      • 
-
    
-
-
-
-
    
-
-
    
-  
 
    基本ブロックとCodeGear
    
 
 
      
   
    • コンパイラなどでは, 関数あるいはループの先頭から, 別の関数呼び出し, あるいはジャンプするまでの間のコードを基本ブロックと呼ぶ
      • 
   
    • 基本ブロックは入力に影響を受けず, 基本ブロックが決定したタイミングである決定的な処理を行う
      • 
+  
    • 予め実行する基本ブロックが確定していれば, その部分のみ抜き出してコンパイルする事が可能である
      • 
+  
    • CbCのCodeGearは, この基本ブロックとみなす事が可能である
      • 
+  
    • その為, NQPの例題の様に, 予め実行する基本ブロックが確定すれば, その部分の処理が可能となる
      • 
+  
    • これを行うことで, CbCを用いてMoarVMのThreadedCode実装が可能となる
      • 
 
    
 
+
    __code cbc_const_i64(INTERP i,__code cbc_next(INTERP i)){
+    GET_REG(i->cur_op, 0,i).i64 = MVM_BC_get_I64(i->cur_op, 2);
+    i->cur_op += 10;
+    goto cbc_next(i);
+}
+
+goto cbc_const_i64_16(i,cbc_gt_i_01);
+
+__code cbc_gt_i_01(INTERP i){
+	goto cbc_gt_i(i,cbc_unless_i_01);
+}
+
+__code cbc_unless_i_01(INTERP i,cbc_osrpoint_01){
+	goto cbc_unless_i(i,cbc_osrpoint_01);
+}
+
    
+