ささだです。

　久々にこちらにネタを。call threading （while (*pc) { (*pc)()
}）を実装してみました。

　今まで、VC は ラベルを値として利用することができないので
switch threading だったんで、call threading にするとどうなるか
なーと思っていたんですが、とりあえず fib ってみたら、 call
threading のほうが若干遅くなりました（x86 core duo）。

　関数呼び出しのコスト（fastcall）が思ったよりも遅かったから
か、それとも関数にインライン展開するほうが速いからか。

fib(34) on VC
switch: 3.7 sec
call  : 4.2 sec


　VMware 上での評価ですが、direct threading なものとの比較は、
やっぱり direct が全然速いです。

fib(34) on gcc (Linux on VMware)
direct: 3.1 sec
call  : 4.6 sec

　コンパイルの時間は若干 call のほうが速いです（1 関数が大きい
から）。

　オブジェクトファイルは call のほうが大きいですね。共有できる
部分もそれぞれVM命令ごとの関数に持っちゃってるからかな。

on VC
switch: 151K
call  : 190K



　一応、call は fastcall を指定してあります。しかし、typedef
時に設定する場所が gcc と VC で違って、きれいに書けないとい
う。FASTCALL_TYPEDEF を作るほうがよかったかも。


#if __GCC__
#define FASTCALL(x) x __attribute__ ((fastcall))
#define FASTCALL_KWD_GCC __attribute__ ((fastcall))
#define FASTCALL_KWD_VC

#elif defined(_MSC_VER)
#define FASTCALL(x) __fastcall x
#define FASTCALL_KWD_GCC
#define FASTCALL_KWD_VC __fastcall
#else

#define FASTCALL
#define FASTCALL_KWD_GCC
#define FASTCALL_KWD_VC
#endif

typedef rb_control_frame_t *
  (FASTCALL_KWD_VC *insn_func_type)(rb_thread_t *,
rb_control_frame_t *) FASTCALL_KWD_GCC;

#define INSN_ENTRY(insn) \
  static rb_control_frame_t * \
    FASTCALL(LABEL(insn)(rb_thread_t *th, rb_control_frame_t
*reg_cfp)) {


-- 
// SASADA Koichi at atdot dot net

--
ML: yarv-dev quickml.atdot.net
Info: http://www.atdot.net/~ko1/quickml