BEAM命令

この記事は英語の原文を日本語に翻訳したものです。原文: https://blog.stenmans.org/theBeamBook/#AP-Instructions

翻訳元: happi/theBeamBook 7998e22e78417dbe20e5136b9aee862a1ecaa404（コミット 7998e22）

本章では、BEAM汎用命令セットの大半の命令を詳しく見ていきます。 次節では、コード内のドキュメント（lib/compiler/src/genop.tabを参照）から生成した簡単な説明とともに、すべての命令を一覧にしています。

関数とラベル

label Lbl

汎用命令セットの命令番号1は、実のところ命令と呼べるようなものではありません。 コード中の現在位置に名前、というより番号を与えるだけの、モジュールローカルなラベルです。

各ラベルはジャンプの着地点になりうるため、ベーシックブロックの開始位置を示す場合があります。

func_info Module Function Arity

各関数のコードはfunc_info命令から始まります。 この命令はfunction clauseエラーを生成するために使われ、関数の実際のコードはfunc_info命令の直後にあるラベルから実行が始まります。

ガード付きの関数を考えてみましょう。

id(I) when is_integer(I) -> I.

この関数に対応するBeamコードはおおむね次のようになります。

{function, id, 1, 4}.
  {label,3}.
    {func_info,{atom,test1},{atom,id},1}.
  {label,4}.
    {test,is_integer,{f,3},[{x,0}]}.
    return.

ここでメタ情報{function, id, 1, 4}は、id/1関数の実行がラベル4から始まることを示しています。 ラベル4ではx0に対してis_integerを行い、失敗するとfunc_info命令を指すラベル3（f3）へジャンプしてfunction clause例外を生成します。 成功した場合はそのまま処理を続け、引数（x0）を返します。

テスト命令

型テスト

型テスト命令（is_* Lbl Argument）は、引数が指定した型かどうかを調べ、そうでなければラベルLblへジャンプします。 beamの逆アセンブラは、これらの命令をすべてtest命令として包んで表示します。例えば次のようになります。

    {test,is_integer,{f,3},[{x,0}]}.

現在の型テスト命令には、is_integer、is_float、is_number、is_atom、is_pid、is_reference、is_port、is_nil、is_binary、is_list、is_nonempty_list、is_function、is_function2、is_boolean、is_bitstr、is_tupleがあります。

さらに、アリティ3を取る型テスト命令が1つあります。test_arity Lbl Arg Arityです。 この命令は、引数（タプルであることを前提とします）のアリティがArityであるかどうかを調べます。 通常、この命令の直前にはis_tuple命令が置かれます。

比較

比較命令（is_* Lbl Arg1 Arg2）は、命令の指示に従って2つの引数を比較し、比較が成立しなければLblへジャンプします。

比較命令には、is_lt、is_ge、is_eq、is_ne、is_eq_exact、is_ne_exactがあります。

Erlangのすべての項は順序付けられているため、これらの命令はどんな2つの項でも比較できることを思い出してください。 たとえば、アトムselfがself()の返すpidより小さいかどうかを調べることもできます（実際に小さいです）。

数値については、比較がErlangのnumber型に基づいて行われることに注意してください（詳しくは型システムの章を参照してください）。 つまり、floatとintegerが混在する比較では、精度の低い方の数値がもう一方の型に変換されてから比較されます。 たとえば私の環境では、1と1.0は等しいと比較され、9999999999999999と1.0e16も同様です。 浮動小数点数の比較には常にリスクが伴うため避けるべきであり、結果は基盤となるハードウェアによって変わることがあります。

整数の1と浮動小数点数の1.0を確実に区別して比較したい場合は、is_eq_exactとis_ne_exactを使います。 これはErlangの演算子=:=と=/=に対応します。

関数呼び出し

本章では、さまざまな呼び出し命令が何を行うのかを概観します。 関数呼び出しの仕組みについての詳しい説明は、呼び出しの章を参照してください。

call Arity Label

同一モジュール内、ラベルLabelにあるアリティArityの関数を呼び出します。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 呼び出し後の現在のコードアドレスはCPに保存されます。

ローカル呼び出しでは、指定するラベルは常にそのコードが開始する関数の2番目のラベルです。 コンテキストスイッチが必要になった際にMFAを取得できるよう、そのラベルの直前の命令はfunc_infoであることが前提とされています。

call_only Arity Label

同一モジュール内、ラベルLabelにあるアリティArityの関数へ末尾再帰呼び出しを行います。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 CPは戻りアドレスで更新されません。

call_last Arity Label Deallocate

スタックをDeallocateワード分解放したうえで、同一モジュール内、ラベルLabelにあるアリティArityの関数へ末尾再帰呼び出しを行います。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 CPは戻りアドレスで更新されません。

call_ext Arity Destination

Destinationで指定される、アリティArityの関数へ外部呼び出しを行います。 アセンブリ上でDestinationは通常{extfunc, Module, Function, Arity}のように書かれ、これはモジュールのimportsセクションに追加されます。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 CPは戻りアドレスで更新されます。

call_ext_only Arity Destination

Destinationで指定される、アリティArityの関数へ末尾再帰的な外部呼び出しを行います。 アセンブリ上でDestinationは通常{extfunc, Module, Function, Arity}のように書かれます。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 CPは戻りアドレスで更新されません。

call_ext_last Arity Destination Deallocate

スタックをDeallocateワード分解放したうえで、Destinationで指定される、アリティArityの関数へ末尾再帰的な外部呼び出しを行います。 アセンブリ上でDestinationは通常{extfunc, Module, Function, Arity}のように書かれます。 まずリダクションカウントを減らし、必要であればコンテキストスイッチを行います。 CPは戻りアドレスで更新されません。

bif0 Bif Reg, bif[1,2] Lbl Bif [Arg,…​] Reg

与えられた引数でbifBifを呼び出し、結果をRegに格納します。 bifが失敗した場合はLblへジャンプします。 アリティ0のbifは失敗しえないため、bif0には失敗時のラベルがありません。

gc_bif[1-3] Lbl Live Bif [Arg, …​] Reg

与えられた引数でbifBifを呼び出し、結果をRegに格納します。 bifが失敗した場合はLblへジャンプします。 引数はx(Live)、x(Live+1)、x(Live+2)に格納されます。

call_fun Arity

call_fun命令は、引数が先頭のArity個の引数レジスタに置かれ、fun（クロージャへのポインタ）が最後の引数の次のレジスタx[Arity+1]に置かれていることを前提とします。

つまり、アリティ0の呼び出しではクロージャはx[0]に置かれます。 アリティ1の呼び出しではx[0]に引数が、x[1]にクロージャが入ります。以下同様です。

apply Arity

X registersに格納されたArity個の引数で関数呼び出しをapplyします。 モジュールを表すアトムはx[Arity]に、関数を表すアトムはx[Arity+1]に格納されます。 モジュールはタプルで表現されることもあります。

apply_last Arity Dealloc

CPをポップし、要素を解放してからCPを再びプッシュするという手順で、スタック上のDealloc個の要素を解放します。 続いて、新しい場所へジャンプすることで、X registersに格納されたArity個の引数を使って末尾再帰呼び出しを行います。 モジュールと関数を表すアトムは、それぞれx[Arity]とx[Arity+1]に格納されます。 モジュールはタプルで表現されることもあります。

スタックとヒープの管理

BeamにおけるErlangプロセスのスタックとヒープは同じメモリ領域を共有しています（詳しい説明はプロセスの章とメモリの章を参照してください）。 スタックはアドレスの低い方向へ、ヒープはアドレスの高い方向へ伸びていきます。 スタックかヒープのどちらかで利用可能な量を超える空間が必要になると、Beamはガベージコレクションを行います。

• リーフ関数：他の関数を一切呼び出さない関数のことです。
• 非リーフ関数：他の関数を呼び出す可能性がある関数のことです。

これらの命令は、非リーフ関数が現在のスタックフレームを構築・解体するためにも使われます。 つまり、関数に入るときに継続ポインタ（CP）がスタックに保存され、抜けるときにスタックから読み戻されます。

リーフ関数の骨格は次のようになります。

{function, Name, Arity, StartLabel}.
  {label,L1}.
    {func_info,{atom,Module},{atom,Name},Arity}.
  {label,L2}.
    ...
    return.

非リーフ関数の骨格は次のようになります。

{function, Name, Arity, StartLabel}.
  {label,L1}.
    {func_info,{atom,Module},{atom,Name},Arity}.
  {label,L2}.
    {allocate,Need,Live}.

    ...
    call ...
    ...

    {deallocate,Need}.
    return.

allocate StackNeed Live

継続ポインタ（CP）を保存し、スタック上にStackNeedワード分の領域を追加で確保します。 確保の途中でメモリが尽きた場合はGCを呼び出し、先頭のLive個のxレジスタがルートセットの一部を構成します。 たとえばLiveが2であれば、GCはレジスタX0とX1を保存し、残りは未使用として解放されます。

スタック上に確保する際は、スタックポインタ（E）が減少します。

allocateの実行例（Allocate 1 0）

       Before           After
         | xxx |            | xxx |
    E -> | xxx |            | xxx |
         |     |            | ??? | caller save slot
           ...         E -> | CP  |
           ...                ...
 HTOP -> |     |    HTOP -> |     |
         | xxx |            | xxx |

allocate_heap StackNeed HeapNeed Live

継続ポインタ（CP）を保存し、スタック上にStackNeedワード分の領域を追加で確保します。 さらに、ヒープ上にもHeapNeedワード分の空きがあることを保証します。 確保の途中でメモリが尽きた場合は、保持すべきXレジスタの数をLiveとしてGCを呼び出します。

allocate_zero StackNeed Live

この命令はallocateと同様に動作しますが、確保したスタックスロットをNILでクリアする点が異なります。

allocate_zeroの実行例（allocate_zero 1 0）

       Before           After
         | xxx |            | xxx |
    E -> | xxx |            | xxx |
         |     |            | NIL | caller save slot
           ...         E -> | CP  |
           ...                ...
 HTOP -> |     |    HTOP -> |     |
         | xxx |            | xxx |

allocate_heap_zero StackNeed HeapNeed Live

allocate_heap_zero命令はallocate_heap命令と同様に動作しますが、確保したスタックスロットをNILでクリアする点が異なります。

test_heap HeapNeed Live

test_heap命令は、ヒープ上にHeapNeedワード分の空きがあることを保証します。 確保の途中でメモリが尽きた場合は、保持すべきXレジスタの数をLiveとしてGCを呼び出します。

init N

init命令は、CPポインタより上のNワード分のスタックにNILを書き込んでクリアします。

deallocate N

deallocate命令はallocateの逆の操作を行います。 CP（継続ポインタ）を復元し、N+1ワード分のスタックを解放します。

return

return命令は、継続ポインタ（CP）に入っているアドレスへジャンプします。 CPの値はC言語における0にあたる値に設定されます。

trim N Remaining

CPを一時変数へポップし、スタックのNワード分を解放してから、CPをスタックの先頭に戻します。 （引数Remainingは、私が知るかぎり使われていません。）

trimの実行例（Trim 2）

       Before           After
         | ??? |            | ??? |
         | xxx |       E -> | CP  |
         | xxx |            | ... |
    E -> | CP  |            | ... |
         |     |            | ... |
           ...                ...
 HTOP -> |     |    HTOP -> |     |
         | xxx |            | xxx |

データの移動、抽出、書き換え

move Source Destination

移動元Source（リテラルまたはレジスタ）の値を、移動先レジスタDestinationへ移動します。

get_list Source Head Tail

リストセルを分解する操作です。 Sourceで指定されたリスト（consセル）のheadとtail（car部とcdr部）を取り出し、レジスタHeadとTailに格納します。

get_tuple_element Source Element Destination

配列の添字読み出し操作です。 Sourceタプルの位置Elementにある要素を取り出し、レジスタDestinationに格納します。

set_tuple_element NewElement Tuple Position

配列の添字を使った破壊的更新操作です。 TupleのPositionにある要素を、新しい値NewElementで更新します。

項の構築

put_list Head Tail Destination

ヒープ上に新しいリスト（cons）セルを構築し（2ワード）、そのアドレスをレジスタDestinationに格納します。 リストセルの第1要素にはHeadの値が、第2要素にはTailの値が設定されます。

put_tuple Size Destination

ヒープ上に空のタプルを構築し（Size+1ワード）、そのアドレスをレジスタDestinationに格納します。 この時点では要素は設定されません。 put_tuple命令の後には必ず複数のput命令が続き、要素を1つずつ破壊的に設定していきます。

put Value

直前のput_tuple命令で作られたタプルの次の要素へ、Valueを破壊的に格納します。 書き込みアドレスはVM内部で保持・インクリメントされます。 新しいタプルの内容を設定するには、複数のput命令が使われます。

make_fun2 LambdaIndex

モジュールのLambdaテーブル上のインデックスによって定義される関数オブジェクトを生成します。 Lambdaテーブルは、エントリポイント（ラベルまたはexportエントリ）、アリティ、そしてfrozen変数をいくつ取るかを定義します。 frozen変数の値は現在の実行コンテキスト（Xレジスタ）からコピーされ、関数オブジェクトに格納されます。

個々のBEAM命令の詳細な一覧は本翻訳の対象外です。 原文オンライン版（https://blog.stenmans.org/theBeamBook/#AP-Instructions）を参照してください。

個別の命令

引数の型は次のとおりです。

すべてのBEAM命令の一覧