Continuation based Cの GCC 4.6 上の実装について

大城信康

琉球大学並列信頼研究室

目的と背景(1)

当研究室ではコードセグメント単位で記述するプログラミング言語Continuation based C (以下CbC)を開発している。

コードセグメントは並列実行の単位として使うことができ、プログラムの正しさを示す単位としても使用することができる。

Many Core での並列実行を高い性能と高い信頼性で実現することができると考えている。

目的と背景(2)

CbC のコンパイラは2001年に Micro-C 版、2008年には GCC-4.2 をベースとしたコンパイラが開発された。

GCC をベースとした CbC コンパイラは、修正・追加されていく最適化の機能を使用する為に、 GCC のアップデートに合わせ変更する必要がある。

本研究ではCbC コンパイラを GCC-4.6 へとアップデートを行った。

発表内容

CbC の紹介
GCC でのコンパイルの流れ

CbC の実装

Micro-C との性能比較
まとめ

Continuation based C

コードセグメント単位での記述と継続を基本としたプログラミング言語。

コードセグメント:CbCにおけるプログラムの基本単位

C の関数よりも細かい単位になる。
コードセグメントの末尾処理で別のコードセグメントへ継続(goto)することでCbCのプログラムは続いていく。
Cから関数コールとループ制御が取り除かれた形となる。

Continuation based C

継続(C言語):現在の処理を実行していく為の情報

続く命令のアドレス
命令に必要なデータ
スタックに積まれている値(環境)

CbC: 関数コールが無い -> 呼び出し元への復帰がない

CbCの継続:軽量継続(light-weight continuation)

Cの継続から環境を除外
続く命令とその命令に必要なデータのみ

Continuation Based C (軽量継続)

Cの関数呼び出し	CbCの継続

コードセグメントへの継続はcallではなくjmp命令で行われる

スタックに載るデータは1つのコードセグメントの必要なデータのみ。

Continuation based C

階乗を求めるCbCのプログラム
__code print_factorial(int prod) { printf("factorial = %d\n",prod); exit(0); } __code factorial0(int prod, int x) { if ( x >= 1) { goto factorial0(prod*x, x-1); }else{ goto print_factorial(prod); } }	__code factorial(int x) { goto factorial0(1, x); } int main(int argc, char **argv) { int i; i = atoi(argv[1]); goto factorial(i); return 0; }

階乗を求めるCbCのプログラム


__code print_factorial(int prod) {
  printf("factorial = %d\n",prod);
  exit(0); 
}

__code factorial0(int prod, int x) {
  if ( x >= 1) {
    goto factorial0(prod*x, x-1);
  }else{
    goto print_factorial(prod);
  } 
}


__code factorial(int x) {
  goto factorial0(1, x); 
}

int main(int argc, char **argv) {
  int i;
  i = atoi(argv[1]);
  goto factorial(i); 
  return 0;
}

__code キーワードによるコードセグメントの宣言
goto によるコードセグメントへの継続(Cの関数呼び出しと同等)

以上がCbCについての紹介となる。

GCC

本来はGnu Compiler Collectionのことを指すが、
ここで扱うのはGnu C Compiler(cc1)になる。

GCCではアセンブラ言語を出力するまでに読み込まれたソースコードは次の4つの中間言語へと変換される。

GCC

Generic Tree:ソースコードを構文木の形に直したもの
GIMPLE: Generic Treeの命令を簡単にした構文木
Tree SSA: GIMPLEの中で変数代入を一度しか行わせない形にした構文木
RTL: レジスタの割り当てといった低レベルの表現でアセンブラとほぼ同じ命令の表現ができる。

それぞれは次のようなデータを構文木にして持っている。

GCC

Generic(ソースコード)

GIMPLE

void factorial(int x)
{
  int prod,i;
  for(i=1,prod=1; i <= x; i++){
    prod = prod*i;
  }
  print_factorial(prod);
}

factorial (int x)
{
  int prod;
  int i;

  i = 1;
  prod = 1;
  goto <D.2846>;
  <D.2845>:
  prod = prod * i;
  i = i + 1;
  <D.2846>:
  if (i <= x) goto <D.2845>; else goto <D.2847>;
  <D.2847>:
  print_factorial (prod);
}

GCC

SSA

RTL(一部)

factorial (int x)
{
  int i;
  int prod;

<bb 2>:
  i_3 = 1;
  prod_4 = 1;
  goto <bb 4>;

<bb 3>:
  prod_6 = prod_1 * i_2;
  i_7 = i_2 + 1;

<bb 4>:
  # prod_1 = PHI <prod_4(2), prod_6(3)>
  # i_2 = PHI <i_3(2), i_7(3)>
  if (i_2 <= x_5(D))
    goto <bb 3>;
  else
    goto <bb 5>;

<bb 5>:
  print_factorial (prod_1);
  return;
}

(jump_insn 20 19 21 5 (set (pc)
        (if_then_else (le (reg:CCGC 17 flags)
                (const_int 0 [0]))
            (label_ref 17)
            (pc))) factorial.c:12 -1
     (nil)
 -> 17)

(note 21 20 22 6 [bb 6] NOTE_INSN_BASIC_BLOCK)

(insn 22 21 23 6 (set (reg:SI 62)
        (mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
                (const_int -4 [0xfffffffffffffffc])) [0 prod+0 S4 A32])) factorial.c:15 -1
     (nil))

(insn 23 22 24 6 (set (reg:SI 5 di)
        (reg:SI 62)) factorial.c:15 -1
     (nil))

(call_insn 24 23 25 6 (call (mem:QI (symbol_ref:DI ("print_factorial") [flags 0x403]  ) [0 S1 A8])
        (const_int 0 [0])) factorial.c:15 -1
     (nil)
    (expr_list:REG_DEP_TRUE (use (reg:SI 5 di))
        (nil)))

(code_label 25 24 26 7 2 "" [0 uses])

(note 26 25 0 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

GCC

CbCの実装においてはGeneric Tree生成部分とRTLへの変換部分に修正が加えられている。

Generic Tree生成部分について詳しく触れてみる。

GCC:Generic Tree

Generic Treeではソースコードの内容が FUNCTION_TYPE, CALL_EXPR, MODIFY_EXPR 等と言った形で表される。

	値の代入:MODIFY_EXPR	関数呼び出し:CALL_EXPR
命令	b = a * 10	func(a,10)
Generic Tree

Generic Treeでの表現

GCC:Generic Tree

それぞれの命令はSTATEMENT_LISTでまとめて保持される。

ソースコード	Generic Treeでの表現
int main() { int a, b; a = 3; b = func(a, 10); return b; }

CbCの実装においてこのGeneric Treeの生成を意識していくことになる。

CbCの実装

シンタックスの追加
末尾除去:Tail Call Elimination(TCE)
レジスタによる引数渡し(fastcall属性の付与)
環境付き継続
__rectype の実装

CbCの実装:シンタックスの追加

__code キーワードでのコードセグメントの宣言

__code 用idとkeywordを作成。
戻り値が無い為、コードセグメントは void 型の関数で作成される木と同じ木が作られる。

const struct c_common_resword c_common_reswords[] =
{
 { "_Bool",            RID_BOOL,      D_CONLY },
     :
 { "__code",         RID_CbC_CODE,   0 },

case RID_CbC_CODE:     
      :
 specs->typespec_word = cts_CbC_code;

case cts_CbC_code: 
       :
     specs->type = void_type_node; 
     break;

CbCの実装:シンタックスの追加

goto によるコードセグメントへの継続

通常の goto に加え、コードセグメントへ継続する処理を追加。
コードセグメントへのgotoの後に、returnの処理を自動で追加。

追加したgotoシンタックスの実際のソースは次のようになる。

CbCの実装:シンタックスの追加

gotoシンタックスの追加

 case RID_GOTO:
   c_parser_consume_token (parser);
   if ( c_parser_next_token_is (parser, CPP_NAME)
	&& c_parser_peek_2nd_token (parser)->type == CPP_SEMICOLON )
     {
       stmt = c_finish_goto_label (loc,
				   c_parser_peek_token (parser)->value);
       c_parser_consume_token (parser);
     }
   else if (c_parser_next_token_is (parser, CPP_MULT))
     {
       tree val;

       c_parser_consume_token (parser);
       val = c_parser_expression (parser).value;
       mark_exp_read (val);
       stmt = c_finish_goto_ptr (loc, val);
     }
   else
     expr = c_parser_expr_no_commas (parser, NULL);
   if (TREE_CODE(expr.value) == CALL_EXPR )
     {
       location_t loc = c_parser_peek_token (parser)->location;
       cbc_replace_arguments (loc, expr.value);
       TREE_TYPE(expr.value) = void_type_node;
       CbC_IS_CbC_GOTO (expr.value) = 1;
       CALL_EXPR_TAILCALL (expr.value) = 1;
       add_stmt(expr.value);
       stmt = c_finish_return(loc, NULL_TREE, NULL_TREE);
     }

cbc_replace_arguments関数は引数のデータを一時的な変数へ避難させる。

CALL_EXPR_TAILCALLマクロでtail callフラグを立てる。

最後にc_finish_return関数によりreturn文を生成している。

CbCの実装:シンタックスの追加

gotoシンタックスの追加

tail callフラグを立てることで、関数呼び出しに末尾除去(末尾最適化)をかけることができる。
最後のリターン文生成も、末尾除去にかける為に必要な処理。

実際のコード	GCC 内で処理されるコード
__code test() { : goto factorial0(1, x); }	void test() { : factorial0(1, x); return; }

CbCの実装:TCE(末尾除去)

末尾除去:Tail Call Elimination(TCE)

関数呼び出しをcallではなくjmp命令で行う最適化。

以下のソースの場合関数g から関数f へjmp命令で処理が移る。


void f(int a, int b) {
  printf("f: a=%d b=%d\n",a,b);
  return ;
}
void g(int a, int b){
  printf("g: a=%d b=%d\n",a,b);
  f(a,b);
  return;
}

int main() {
  g(3,4);
  return 0;
}

CbCの実装:TCE(末尾除去)の動作

スタック:呼び出し元関数と同じ範囲を使うことになる。

func_bの引数はfunc_aのスタックに上書する
func_bの為にスタックポインタは伸ばされない

CbCにおけるコードセグメントへの継続はこのTCEを用いて実装されている。

TCEにかかるには条件が幾つかある。

CbCの実装:TCE(末尾除去)

TCEにかかる条件

caller側とcallee側の戻値の型の一致している。
関数呼び出しがリターン直前に行われている。
呼出先関数の引数に用いられるスタックサイズが呼出元のそれより少ない。
引数の並びのコピーに上書きがない。

CbCの実装:TCE(末尾除去)

条件を回避する為以下の実装にする。

型はvoid型で統一する。
gotoの直後にreturnを置く。
スタックサイズは固定にする。
引数は一旦、一時変数にコピーする。

CbCの実装:TCE(末尾除去)

TCEの条件はexpand_call関数で調べられる。

expand_call関数

Treeで表された関数からRTLを生成する関数
スタックの領域確保、引数の格納、関数へのcall命令の発行が行わる。
try_taill_call(変数名)フラグがあり、TCEの条件に合わなければこのフラグが落とされる。

具体的な実装内容

try_tail_callフラグを落とすif文の条件をかわすようにする。
try_tail_callフラグを立たせる処理の追加。

CbCの実装:TCE(末尾除去)

try_tail_callフラグが落とされる部分

  if (currently_expanding_call++ != 0
      || ((!fndecl || !CbC_IS_CODE_SEGMENT (TREE_TYPE (fndecl))) 
         && !flag_optimize_sibling_calls)
      || args_size.var
      || dbg_cnt (tail_call) == false)
    try_tail_call = 0;

!CbC_IS_CODE_SEGMENT (TREE_TYPE (fndecl)により条件を回避

CbCの実装:TCE(末尾除去)

try_tail_callフラグが落とされる部分

  if (
#ifdef HAVE_sibcall_epilogue
      !HAVE_sibcall_epilogue
#else
      1
#endif
      || !try_tail_call
      || structure_value_addr != NULL_RTX
#ifdef REG_PARM_STACK_SPACE
      || (OUTGOING_REG_PARM_STACK_SPACE (funtype)
          != OUTGOING_REG_PARM_STACK_SPACE (TREE_TYPE (current_function_decl)))
      || (reg_parm_stack_space != REG_PARM_STACK_SPACE (fndecl))
#endif
      || !targetm.function_ok_for_sibcall (fndecl, exp)
      || (flags & (ECF_RETURNS_TWICE | ECF_NORETURN))
      || TYPE_VOLATILE (TREE_TYPE (TREE_TYPE (addr)))
      || (fndecl && decl_function_context (fndecl) == current_function_decl)
      || args_size.constant > (crtl->args.size
                               - crtl->args.pretend_args_size)
      || (targetm.calls.return_pops_args (fndecl, funtype, args_size.constant)
          != targetm.calls.return_pops_args (current_function_decl,
                                             TREE_TYPE (current_function_decl),
                                             crtl->args.size))
      || !lang_hooks.decls.ok_for_sibcall (fndecl))
    try_tail_call = 0;

引数のスタックサイズ、関数の型のチェックが行われる。

CbCの実装:TCE(末尾除去)

try_tail_callフラグが落とされる部分

  /* Check if caller and callee disagree in promotion of function                                                                                                                      
     return value.  */
#ifndef noCbC
  if (try_tail_call && (!fndecl || !CbC_IS_CODE_SEGMENT (TREE_TYPE (fndecl))))
#else
    if (try_tail_call)
#endif
    {
      enum machine_mode caller_mode, caller_promoted_mode;
      enum machine_mode callee_mode, callee_promoted_mode;
      int caller_unsignedp, callee_unsignedp;
      tree caller_res = DECL_RESULT (current_function_decl);

      caller_unsignedp = TYPE_UNSIGNED (TREE_TYPE (caller_res));
      caller_mode = DECL_MODE (caller_res);
      callee_unsignedp = TYPE_UNSIGNED (TREE_TYPE (funtype));
      callee_mode = TYPE_MODE (TREE_TYPE (funtype));
      caller_promoted_mode
        = promote_function_mode (TREE_TYPE (caller_res), caller_mode,
                                 &caller_unsignedp,
                                 TREE_TYPE (current_function_decl), 1);
      callee_promoted_mode
        = promote_function_mode (TREE_TYPE (funtype), callee_mode,
                                 &callee_unsignedp,
                                 funtype, 1);
      if (caller_mode != VOIDmode
          && (caller_promoted_mode != callee_promoted_mode
              || ((caller_mode != caller_promoted_mode
                   || callee_mode != callee_promoted_mode)
                  && (caller_unsignedp != callee_unsignedp
                      || GET_MODE_BITSIZE (caller_mode)
                         < GET_MODE_BITSIZE (callee_mode)))))
        try_tail_call = 0;
    }

関数の型のチェックが行われる。

CbCの実装:TCE(末尾除去)

try_tail_callフラグ矯正付与のソースコード

#ifndef noCbC
  if (fndecl && CbC_IS_CODE_SEGMENT (TREE_TYPE (fndecl))
      && CbC_IS_CODE_SEGMENT (TREE_TYPE (current_function_decl))
      && try_tail_call == 0)
    {
      location_t loc = EXPR_LOCATION (exp);
      char *name_callee = IDENTIFIER_POINTER(DECL_NAME(fndecl));
      warning_at (loc, 0, "transition to code segment \"%s\" with CbC goto, but tail call optimization was cut.",
                        name_callee);
      try_tail_call = 1;
    }
#endif

try_tail_callフラグが落とされた場合warningを出してフラグを立たせる。
(最適化の矯正付与)

CbCの実装:TCE(末尾除去)の実装について

以前はexpand_call関数を元にしたexpand_cbc_goto関数を作り条件を回避させていた。
だがその方法だとexpand_call関数の修正にも合わせていく必要もあり管理も面倒であった。
しかしtry_tail_callフラグを落とさせない方法にすることでexpand_cbc_goto関数はいらなくなり、管理が容易くなった。

CbCの実装

CbCの基本機能を実現する為の実装は以上の2つになる。

シンタックスの追加
末尾除去によるコードセグメントへjmp命令での処理の移り

ここからはCbCの機能の拡張になる。

CbCの実装:引数渡し

GCC版コンパイラー開発当初、コンパイルしたCbCのプログラムはMicro-C版に速度面で勝てなかった。

Micro-Cでは関数呼び出しの際にできるだけレジスタを使うようにしていた。

そこで、GCC版CbCコンパイラの引数渡しもできるだけレジスタで行うことに。

CbCの実装:引数渡し(fastcall)

fastcall

i386 において関数呼び出しの際、引数渡しをできるだけレジスタを用いるGCCの拡張機能。
関数に『__attribute__ ((fastcall))』をつけることで使えるようになる。

__codeで宣言された関数は自動でfastcall属性が付与されるように以下のコードを追加。

if(!TARGET_64BIT) {
  attrs = build_tree_list (get_identifier("fastcall"), NULL_TREE); 
  declspecs_add_attrs(specs, attrs);
 }

Intel64 ではレジスタが増えている為、fastcallは標準でつくようになっている。

CbCの実装:引数渡し

fastcall属性の付与によりMicro-C版に速度で勝るようになった。

引数渡しに使われるレジスタの数(gcc)
arch	int(整数型)	float(浮動小数点型)	double(浮動小数点型)
i386	2	0 (stackを使用)	0 (stackを使用)
x86_64	6	8	8

CbCの実装:環境付き継続

CbCにおけるCとの互換性を保つための機能。コードセグメントを呼び出したCの関数に戻ることができる。
__returnキーワードを引数に渡すことで使うことができる。

以下の使い方の場合は1を返す。

__code c1(__code ret(int,void *),void *env) {
 goto ret(1,env);
}
int main() {
 goto c1(__return, __environment);
}

__environmentキーワードは関数の環境を保持する。

CbCの実装:環境付き継続

生成しているコード

生成する為のコード


//goto c1(__return, __environment);
goto c1(({
	  __label__ _cbc_exit0;
	  static int retval;
	  void _cbc_internal_return(int retval_, void *_envp) {
	    retval = retval_;
	    goto _cbc_exit0; 
          }
	  if (0) { 
            _cbc_exit0:
	    return retval; 
          }
	  _cbc_internal_return;
	}), __environment);

retval変数の型は継続を行った関数と同じ戻値の型となる。

CbCの実装:環境付き継続

生成されるTree

生成する為のコード


    case RID_CbC_RET:
{
  tree value, stmt, label, tlab, decl;
  c_parser_consume_token (parser);

  stmt = c_begin_stmt_expr ();
  cbc_return_f = c_parser_peek_token (parser)->value;
  location_t location = c_parser_peek_token (parser)->location;

  /* create label. (__label__ _cbc_exit0;) */
  label = get_identifier ("_cbc_exit0");
  tlab = declare_label (label);
  C_DECLARED_LABEL_FLAG (tlab) = 1;
  add_stmt (build_stmt (location, DECL_EXPR, tlab));

  /* declare retval.  (int retval;) */
  tree decl_cond =
    build_decl (location, VAR_DECL, get_identifier ("retval"),
		TREE_TYPE (TREE_TYPE (current_function_decl)));
  TREE_STATIC (decl_cond) = 1;
  TREE_USED (decl_cond) = 1;

  /* Use thread-local */
  DECL_TLS_MODEL (decl_cond) = decl_default_tls_model (decl_cond);
  DECL_NONLOCAL (decl_cond) = 1;
  add_stmt (build_stmt(location, DECL_EXPR,  pushdecl (decl_cond)));

  /* define nested function.  */
  decl =
    cbc_finish_nested_function (location, label, decl_cond);
  TREE_USED(decl) = 1;

  /* define if-ed goto label and return statement. */
  cbc_finish_labeled_goto (location, label, decl_cond);

  /* get pointer to nested function.  */
  value = build_addr (decl , current_function_decl);
  TREE_USED (current_function_decl) = 1;
  SET_EXPR_LOCATION (value, location);
  add_stmt (value);

  TREE_SIDE_EFFECTS (stmt) = 1;
  expr.value = c_finish_stmt_expr (location, stmt);
  expr.original_code = ERROR_MARK;
}

環境付き継続:実装の問題

リターンするretval変数が重要になってくる。
retval変数のデータをどうやって確保するか。

次の方法が考えられる。

クロージャでの確保
staticでの確保
static thread local storage(tls)を用いての確保

環境付き継続:実装の問題

クロージャでの実装

クロージャにしてスタックに値を確保する。

問題点

しかしCbCではスタックの値は破棄されていく。
その為スタックに値を確保するのは好ましくない。

環境付き継続:実装の問題

staticでの実装

静的に値を確保することでスタック破棄の影響を受けない。

問題点

マルチスレッドのプログラムに対応できない。
値を返し切る前に別スレッドによって値が書き換えられる可能性がある。

環境付き継続:実装の問題

static tlsでの実装

スレッド毎に静的に値を確保する。

現在はこの方法で実装を行なっている。

しかし、最適化にかけると正しい値が返ってこない。
(恐らくTreeの生成の部分が間違っている。)

環境付き継続:その他の実装方法

setjmpでの実装

setjmpを行うTreeを生成するのが少し手間になる。
int型の戻値しか得られない。

戻値を入れるレジスタを明示的に指定する。

まだ実装を試していない。

CbCの機能の拡張:__rectype の実装

通常、関数の引数に関数ポインタを渡した際は以下の様に使われる。

void factorial(int n, int result, void(*print)()){
   :
   (*print)(n,result,print,exit1, envp);
}

以下の様に引数に()をつけて受けてることをやめたい。

void factorial(int n, int result, void *print){
   :
   void(*print)(n,result,print,exit1, envp);
}

CbCの機能の拡張:__rectype の実装

そこで、__rectype という予約後を作り、以下の宣言を行えるようにした。

__code factorial(int n, int result, __rectype *print) {
   :
   goto (*print)(n,result,print,exit1, envp);
}

CbCの機能の拡張:selftype

selftypeの実装

以下の宣言が行えるようにしたい。

typedef sturct node {
 selftype *left;
 selftype *right;
 int num;
}*NODE

selftype は struct node を指す。

上記の構文は実装を行う予定である。

Micro-Cとの比較

Micro-C,GCC-4.4とGCC-4.6のCbCコンパイラでコンパイルしたプログラムの実行の速度

GCC版の最適化無しの場合、引数を全て一時変数に代入するという処理が入る。その為に明らかに遅くなっていることが分かる。

だがGCCの最適化有りの場合はMicro-C版よりも早い。

まとめ

今回GCC版CbCコンパイラのアップデートを行った。
TCEにかかる判定の部分と環境付き継続の実装の修正を行った。
おかげで、以前より楽な管理ができる実装にすることができた。
後は環境付き継続の最適化の問題の修正とselftypeの実装を行う。
全ての実装を終えたらGCC版CbCコンパイラの実装はアップデートを行なっていくだけとなる。

今後の予定

CbCを用いたプログラムの作成

CbCによるタスクマネージャの作成

llvmへのCbCの実装

プログラミングシンポジウム: 2012/ 1/ 7

並列信頼研

Continuation based Cの GCC 4.6 上の実装について

琉球大学 並列信頼研究室

目的と背景(1)

目的と背景(2)

発表内容

Continuation based C

コードセグメント単位での記述と継続を基本としたプログラミング言語。

Continuation based C

Continuation Based C (軽量継続)

Continuation based C

GCC

GCC

GCC

GCC

GCC

GCC:Generic Tree

GCC:Generic Tree

CbCの実装

CbCの実装:シンタックスの追加

CbCの実装:シンタックスの追加

CbCの実装:シンタックスの追加

gotoシンタックスの追加

CbCの実装:シンタックスの追加

gotoシンタックスの追加

CbCの実装:TCE(末尾除去)

末尾除去:Tail Call Elimination(TCE)

CbCの実装:TCE(末尾除去)の動作

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)

CbCの実装:TCE(末尾除去)の実装について

CbCの実装

CbCの実装:引数渡し

CbCの実装:引数渡し(fastcall)

fastcall

CbCの実装:引数渡し

CbCの実装:環境付き継続

CbCの実装:環境付き継続

CbCの実装:環境付き継続

環境付き継続:実装の問題

環境付き継続:実装の問題

環境付き継続:実装の問題

環境付き継続:実装の問題

環境付き継続:その他の実装方法

CbCの機能の拡張:__rectype の実装

CbCの機能の拡張:__rectype の実装

CbCの機能の拡張:selftype

selftypeの実装

Micro-Cとの比較

まとめ

今後の予定

琉球大学並列信頼研究室