1 Introduction
The following document describes the Erlang BEAM instruction set used for the BEAM threaded-code emulation. To make it self contained the document starts with a short introduction to the BEAM Virtual Machine clarifying different notions used later in the text.
このドキュメントの詳細はErlang BEAMのBEAMVMでつかわれている命令セットである。文章の後半に含まれているBEAM Virtual Machineのさまざまな記法をこの文章の最初にかかれています。
1.1 Historical Note
This document describes BEAM as it was in 1997. BEAM has grown and changed significantly between then and the time this note was added (2012). This information is mainly for historical interest.
このドキュメントは1997年にBEAMについてかかれたものである。BEAMは以前にくらべ大きなリ、おおきくかわったので、加筆された（2012）。この情報は歴史的に興味深い。
2 BEAM Virtual Machine
2.1 Data Areas
The data areas are the code area, containing loaded compiled Erlang code, and a stack and heap. データエリアはコードエリア、コンパイルロードされたErlangコードそして、スタックとヒープを含んでいる。
The stack contains call frames with local variables and return addresses. スタックはコールフレームと局所変数と呼び出し元のアドレスを含んでいる。
The heap contains terms created by the Erlang execution. The stack and the heap are allocated as one memory area and grow towards each other. ヒープはErlangの実行中に作成される。 スタックとヒープは割り当てられると一つのメモリエリアの中で互いの方向に成長する。
Having the heap and the stack allocated together makes testing for memory overflow very efficient as we compare two pointers (top-of-heap pointer and top-of-stack pointer) residing in hardware registers. ヒープと割り当てられたスタックを持つことは二つのハードウェアポインタ（ヒープとスタックのポインタ）をもつことにくらべ、メモリオーバフローを効果的に検査できる。
Each call frame on the stack starts with a return-address pointer, CP, followed by local variables which are accessed by integer offset from a pointer to the top of the stack. コールフレームは呼び出し元のアドレスへのポインタからはじまる。CPは局所変数のスタックポインタからオフセットアクセスにしたがう。
Frames are allocated only after a clause guard is evaluated and if the clause body contains local variables and function calls. フレームが割り当てられるのは、ガード条件が評価されたあと、さらに 関数呼び出しと局所変数を含んだこうの本体のみです。
Frames are allocated and discarded by the A_op and D_op instructions with explicitly given frame size N. フレームの割り当てと破壊は、A_op、D_op命令によって明示的にスタックサイズNを指定して行われる。
For garbage collection purposes the stack structure can be obtained by looking for stored return addresses. ガベージコレクション スタック構造が戻るべきアドレスを見つけられる事が可能である事を保証している。
A call frame can contain as well catch resumption addresses (see the Catch instruction) and next-instruction pointers (see the C instruction). コールフレームは例外キャッチ時の復帰アドレス（例外命令を参照）と次の命令へのポインタ（C命令を参照）を含む事ができる。
The Erlang BEAM system allows mixing threaded code emulation with compiling into C. Erlang BEAMシステムはエミュレーターコードとコンパイルされCを混ぜることを許容している。
When an Erlang function compiled to C is called, the next instruction pointer, I, is stored in the current local frame and the CP pointer is set to the emulator code which would restore the I pointer upon return from the called function. ErlangがCの関数をよんだ時、次の命令ポンタI、が 今のローカルフレームに保存されるれ、CPポインタがエミュレーターコードにセットされたものが、呼び出し元関数のIポインタに復帰される。
2.2 Data Objects
An Erlang term is represented by a 32-bit unsigned word containing a value and a tag. The tag (4-bit) resides in the least significant bits and distinguishes the type of the term Erlang termはタグと値を含む32bitの符号なしWORDとして表現されている。 タグ（4bit）は少なくとも符号bitと項のタイプを明確にするためにある。
The value part of an atom is an index into a global atom table where the atom is represented. 値の部分がアトムならグーバルなatomテーブルに索引にatomが表現されている。 The value part of a small integer is the integer itself. 値の部分が小さい整数ならその整数自身です。 The value part of a big number integer is a pointer to a heap object containing the integer sign and number of words building the integer value. 値の部分が大きい整数ならヒープの符号と整数を含むオブジェクトへのポインタを含みます。 The value part of a list is a pointer to two consecutive heap locations with two tagged objects (the head and tail of the list). 値の部分がリストならヒープの２つタグづけされたオブジェクトへの連続した２つのポインタで表現される(リストのヘッダとテイル)。
The value part of a tuple is a pointer to a heap object containing tuple size followed by the tuple elements. 値の部分がタプルならタプル要素とそののサイズを含むヒープのオブジェクトへのポインタで表現される。 The value part of a float is a pointer to a heap object containing a two-word float value. 値の部分がfloatなら２WORDのfloat値を含むヒープのオブジェクトへのポインタで表現される。 The value part of a process identifier is the process identifier itself. 値の部分がプロセス識別子ならその識別子自身で表現される。
The current BEAM implementation uses the following tags: 今のBEAMの実装ならつぎのようなタグを使用している:
#define SMALL 15 /* small integer */
#define BIG 11 /* big integer pointer */
#define FLOAT 9 /* float pointer */
#define ATOM 7 /* atom */
#define REFER 6 /* reference */
#define PORT 5 /* port */
#define PID 3 /* process identifier */
#define TUPLE 2 /* tuple pointer */
#define NIL (BIG + 16) /* empty list */
#define LIST 1 /* list pointer */
#define ARITYVAL 10 /* tuple arity */
#define MOVED 12 /* moved heap pointer */
#define CATCH THING /* resumption address */
#define THING 13 /* float value */
#define BINARY 14 /* binary pointer */
#define BLANK ARITYVAL /* blank local var */
#define IC SMALL /* next instr. pointer */
#define CP0 0 /* CP pointer */
#define CP4 4 /* CP pointer */
#define CP8 8 /* CP pointer */
#define CP12 12 /* CP pointer */
Since some data objects can reside only on heap or stack the same tag can be used for two different objects (CATCH and THING, BLANK and ARITYVAL). ゆえに、いくつかのデータオブジェクトは ヒープまたはスタックの同じタグを２つの異なったオブジェクトに使用できます。(CATCHとTHING, BLANKとARITYVAL) There are some other cases when the same tag can be reused. 他のいくつかの場合同じタグを再利用できる。 Since objects representing the big-number integers are tagged heap pointers, the BIG flag can be used as well to represent an empty list, NIL (since the NIL value part becomes a non valid heap pointer). ゆえに、大きな整数はタグ付きヒープポインタ、BIGフラグも空リストNILを表現できる。（ゆえにNILは正しいヒープポインタになれない）
The CP tags are reserved for the return-address pointer, CP. CPタグ戻り値アドレスのポインタCPのため予約語。 The pointer does not have to be tagged if on the current platform the pointer has always the two last bits set to 0. 今のプラットフォームではもし最後の２つのbitが０ならばタグを持つ必要はない。
2.3 Registers
The BEAM Virtual Machine uses the following registers: HTOP - top-of-heap pointer ヒープのトップへのポインタ
E - top-of-stack pointer スタックのトップへのポインタ
CP - return-address pointer (where to go when a function is ready executed) 戻り値アドレスのポインタ（）
I - next-instruction pointer つぎの実行命令へのポインタ
x(N) - argument registers (to pass function parameters), x(N) are also used to hold temporal variables 引数レジスタ（関数パラメタへわたす）またx(N)は一時変数に使われる
y(N) - local variables (y(N) are not real registers, they reside in a local frame and are accessed by integer offset from a top-of-stack pointer) 局所変数(y(N)は実際にはレジスタではない。局所フレームとスタックのトップポインタへのオフセットアクセス)
fcalls - number of reductions done (to check for suspension while doing function call) リダクション実行の数（関数呼び出しの間に検査は停止されている）
2.4 Function Calls
To call an Erlang function we pass parameters by loading argument registers, x(N), and update the return-address register, CP. Erlangの関数呼び出しは引数レジスタx(N)の読み込んでパラメタに渡ｓる。そして返り値アドレスレジスタCPを更新します。 On function return the return value is stored in x(0). 関数の返り値はx(0)に保存される。
2.5 Concurrency
Erlang processes are dynamically spawned and killed during the execution. Erlangプロセスは実行中に動的にspawnとkillをおこないます。 Each process has its own heap and stack area. それぞれののプロセスはヒープとスタックの領域をもっている。 For concurrency purposes the Erlang BEAM provides suspension and scheduling mechanisms. 並列のためErlangBeamはサスペンドとスケジューリングの機構を提供することを保証している。 A suspending process stores its current state in its suspension record and is added to a scheduler queue. サスペンド中のプロセスは現在の状態をサスペンドレコードとスケジュールキューに追加する。 To guarantee a fair scheduling a process is suspended after a fixed number of reductions and then the first process from the queue is resumed. プロセススケジューリングにおいてサスペンド後の固定値の監訳とキューの最初のプロセスがレジュームが公平であることを保証している。
To receive messages each process has its own local message queue. それぞれのプロセスはローカルメッセージキューをもっっておりメッセージを受信する。 Sending a message results in copying the message into the receiver heap and storing the message reference in the receiver message queue. 送信メッセージの結果はレシーバーヒープの中にコピーされ、レシーバーキューの中でメーッセージの参照がソートされる。
While waiting for messages to be received a process is swapped out, and is added to the scheduler queue only when a new message is received (i.e. the addition is done by a process sending the message), or a time-out occurs. メッセージを待っている間受信プロセスはスワップアウトされる。そして、スケジュールキューに追加され、新しいメッセージを受信するかタイムアウトする。 (つまり、プロセスの送信メッセージより追加される。)
3 BEAM Virtual Machine Instruction Set
The following chapter describes the Erlang BEAM instruction set used for the threaded-code emulation. 次の章はthreaded-code emulationでつかわれているErlang Beamの命令セットの詳細。
3.1 The Instructions Format
Byte-code Syntax (produced by the BEAM compiler and saved in module_name.beam file): byte-codeの文法（BEAMコンパイラに生成され、 module_name.beam ファイルに保存される）:
Opcode values less than 255 are coded as one byte, opcode values larger than 255 are coded as two bytes (255 and the rest). opcode値は255より小さく１ｂｙて、255よりおおきいコードはbyte Module, function, atom names and floating point numbers are coded as a list of ASCII values preceded by the length of the list. Module, function, atomの名前と不動点少数はASCIIのリストとしてリスト長より先にコード化される。 It means that operands in the byte-code syntax diagram can have different size due to their type: そのオペランドの意味は byte-code文法の図はタイプのサイズによって異なる:
8-bit long
- magic number マジックナンバー
- function arity 関数の引数
- type of arithmetic 算術型
- type of operand オペランド型
- type of bif bif型
- sign of bignumber value 符号付き巨大整数
16-bit long 16bitロング
- atom length atomの長さ
- float length floatの長さ
- code length コードの長さ
- register number レジスタの数
- frame size フレームサイズ
- heap requirement
24-bit long
- relative address 相対アドレス
32-bit long
- integer value 整数値
- code size コードサイズ
- tuple arity タプル数
- tuple index タプルインデックス
- string length stringの長さ
- bignum arity ビッグナンバーの長さ
- bignum value ビッグナンバーの値
other operands are 16-bit long. ほかのオペランドは16bit Threaded-code Syntax (produced by the BEAM loader while loading the compiled byte code): スレッドコードの文法（BEAMローダーよりコンパイル済みのバイトコードが読み込まれている間生成される）
| label address |
|---|
| operand1 |
| operand2 |
| ... |
The label address (four bytes) is an address of the corresponding emulator code. ラベルのアドレス(4byte)はエミュレータコードのアドレスと一致する。 After loading, atoms and small integers are ready created (index in atom table + TAG, integer value + TAG). After loading all operands are four-bytes long (one 32-bit word). ロード後、アトムと小さい整数は生成準備される(atomテーブル+タグのインデックス,整数は値+タグ)。 ロード後すべてのオペランドは４byte長(32bitWORD)。
When an operand is NIL or a temporal variable x(0), only one word is used. オペランドがNILまたは一時変数 x(0)の時、1WORD使われる。 When an operand is a temporal variable x(N) or a local variable y(N) the first word indicates type of the variable (X_arg or Y_arg) and the second its index N. オペランド一時変数 x(N)または局所変数 y(N)の時、最初のWORDは変数の型が(X_arg or Y_arg)と二番目がindex Nであることを指している。 For efficiency purposes in many instructions types of operands are implicitly coded as the instructions opcodes. 効率のためいくつかの命令のオペランドの型は暗黙的にコード化された命令オペコードとしている。 Each line in the threaded-code syntax diagram represents a 32-bit word. それぞれの行のスレッドコード文法の図は32bit WORDである。
When a threaded-code syntax corresponds to a byte-code syntax (only instruction opcode is changed to a label address and operands are build, &FuncBegin is added, or instruction offset is changed to instruction address for branch purposes), only the threaded-code syntax is given. スレッドコードがバイトコード文法と一致する時のみ（オペランド命令が変更されるのはラベルアドレスとオペランドに、オペランドの組み立てFuncBeginの追加もしくは命令のオフセットがブランチのため変更される時のみ）スレッドコード文法が与えられる
3.2 Format Instructions
IntCode
Provide some information to the threaded-code loader. いくつかの情報をスレッドコードローダは提供する。 Byte-code Syntax:
| IntCode_op |
|---|
| code size |
| module name |
| magic number |
Threaded-code Syntax: none (the instruction is removed by loader) スレッドコード文法： なし（ローダにより削除される）
code size is a total size (in 32-bit words)of the compiled module code after loading コードサイズのコンパイル後ロードされたものの総数（32bit WORD）です。
module name is an atom name corresponding to the name of the module モジュール名のアトムはモジュール名と一致する。
magic number is used to prevent loading of old format code (is checked against the loader magic number while loading) マジックナンバーは以前読まれていた古いフォーマット（）
3.3 Procedural Instructions
FuncBegin
Generate the BADMATCH error (there is a bad match in an Erlang clause/case/if/receive body). BADMATCHを生成する（これらは Erlangのclause/case/if/receive文のバッドマッチ）
Byte-code Syntax:
| FuncBegin_op |
|---|
| function name |
| function arity |
Threaded-code Syntax:
| lb_FuncBegin |
|---|
| module_name |
| function_name |
| function_arity |
module_name, function_name are ready created atoms. module_name, function_name はすでに生成されている。
Generate the current context information (the current module, function and arity), set the BADMATCH error, branch to error handling procedure. 現在のコンテキスト情報が生成され、BADMATCHエラーがセットされブランチがエラーハンドリング処理される。
The FuncBegin instruction starts each compiled Erlang function. FuncBeginはそれぞれのコンパイル済みのErlang関数を開始する。 To save space the context information provided is reused by other instructions. 保存されたコンテキスト情報のスペースは他の命令に再利用される。 When an Erlang function is called the first instruction after FuncBegin is executed. Erlang関数が呼ばれる時に最初にFuncBeginが実行される。
C/CO/ResC
C: Call a local Erlang function. C: 局所関数呼び出し A local function is the one which reside in the same module as the function caller. 局所関数は同じモジュールから呼ばれる。
CO: Call a local Erlang function. The continuation program pointer (CP register) is already set. CO: 局所関数呼び出し。継続ポインタ(CPレジスタ)がセットされている ResC: Call a resident Erlang function. A resident Erlang function is a local function which cannot be called from and return to other modules. ResC: Erlang関数呼び出し。Erlang関数は局所関数他のモジュールから呼んだりもどることは出来無い。
The instruction is used to optimize control handling when a threaded-code Erlang function cannot be mixed with other Erlang functions compiled into C code. この命令は最適化操作ハンドリングして使用される、スレッドコードのErlang関数はほかのCでコンパイルされたコードと一緒に混ぜて使用できない。
Byte-code Syntax:
| C/CO/ResC_op |
|---|
| function name |
| function arity |
Threaded-code Syntax:
| lb_C/CO/ResC |
|---|
| &function |
| function_arity |
| &FuncBegin |
&function is an address of the first instruction corresponding to the called function (more precisely the first instruction after corresponding FuncBegin). 関数のアドレスは最初の命令と呼ばれた関数に一致する(さらに確かな事は最初の命令のあとはFuncBeginと一致する)
function_arity is a number of function arguments. function_arity関数の引数の数。
&FuncBegin is an address of the current function FuncBegin instruction. FuncBeginのアドレスは今の関数のFuncBegin命令。
C: Store pointer to the next instruction in the current stack frame. C: 今のスタックフレームの次の命令へのポインタを保存。
Set the continuation program pointer at the emulator code restoring the next instruction pointer, increment number of reductions and check for suspension (if suspending, generate the current module, function and arity information using &FuncBegin), branch to called function. プログラムの継続ポインタのエミュレーターコードの設定は次の命令ポインタ、簡約と停止チェック(もし停止停止中なら今のモジュールの&FuncBeginで使用されている関数と引数の情報を生成する。)、呼びだし関数への分かれ道が保存されている。
CO: As above but the continuation program pointer is already set in the CP register (the instruction is used when the last function in the body is called and there is no stack frame to be discarded).
CO: 上記のように継続ポインタはすでにCPレジスタにセットされている(この命令が使用されるのは、よばれた関数最後にスタックフレームが破棄された時)。
ResC: Set the continuation program pointer at the next instruction, increment number of reductions and check for suspension (if suspending, generate the current module, function and arity information using &FuncBegin), branch to called function. ResC: 次の命令の継続ポインタ、簡約回数の加算と停止検査（もし停止停止中なら今のモジュールの&FuncBeginで使用されている関数と引数の情報を生成する。）、呼ばれた関数の分かれ道をセット。
CL
Discard the current stack frame. Call a local Erlang function. 現在のスタックフレームを破棄する。局所Erlang関数でよばれる。 Byte-code Syntax:
| CL_op |
|---|
| function name |
| function arity |
| frame size |
Threaded-code Syntax:
| lb_CL |
|---|
| &function |
| function_arity |
| frame_size |
| &FuncBegin |
frame_size is a size of the current stack frame to be discarded. frame_sizeは破棄される予定のスタックフレームです。
For info on other operands see C/CO. ほかのオペランド情報はC/COを参照。
Copy the continuation program pointer from the current stack frame into CP, discard the frame, increment number of reductions and check for suspension, branch to called function. 継続ポインタを今のスタックフレームの中のCPからコピー、フレームの破棄、簡約数の加算と停止検査、呼び出し関数の分岐。
TrC/TrCO
TrC: A traced version of the C instruction. TrC: Cインストラクションのトレースバージョン
TrCO: A traced version of the CO instruction. TrCO: COインストラクションのトレースバージョン
Byte-code Syntax:
| TrC/TrCO_op |
|---|
| function name |
| function arity |
Threaded-code Syntax:
| lb_TrC/TrCO |
|---|
| &function |
| function_arity |
| &FuncBegin |
| function_name |
function_name is an atom corresponding to the called function name; used to generate some information for tracing purposes.
For info on other operands see C/CO. ほかのオペランドの情報はC/COを参照。
The same semantics as C/CO but some trace information (the called function module, name, arity) is sent to a tracing Erlang process. C/COと同じセマンティックしかし、いくつかのトレース情報(呼ばれた関数のモジュール、名前、引数)はErangプロセスの追跡に送る。
CEx/TrCEx
Call an external Erlang function. TrCEx is a traced version of the CEx instruction. 外部関数呼び出し。TrCExはトレース版のCExインストラクション。
Byte-code Syntax:
| CEx/TrCEx_op |
|---|
| module name |
| function name |
| function arity |
Threaded-code Syntax:
| lb_CEx/TrCEx |
|---|
| module_name |
| function_name |
| function_arity |
| &FuncBegin |
module_name, function_name, function_arity define the external function to be called. module_name, function_name, function_arityは外部関数呼び出しを定義する。
&FuncBegin is an address of the current function FuncBegin instruction. &FuncBeginは今の関数のFuncBeginインストラクションのアドレス。
CEx: Set the continuation program pointer at the next instruction, increment number of reductions and check for suspension (if suspending, generate the current module, function and arity information using &FuncBegin), check if the called function is loaded, if yes branch to the called function (the address is taken from the export-function table), if not call an error handler. CEx: つぎのインストラクションの継続ポインタ、簡約数の加算と停止検査、(if suspending, generate the current module, function and arity information using &FuncBegin)呼ばれた関数がロードされているかのチェック、呼び出し関数の分岐、(アドレスは外部関数テーブルからとられる)
TrCEx: The same semantics as CEx but some trace information (the called function: module, name, arity) is sent to a tracing Erlang process. TrCEx: CExおなじセマンティック、しかしトーレス情報をErlangプロセスへおくる。
CExL/TrCExL
Discard the current stack frame. 今のスタックフレームの破棄。 Call an external Erlang function. 外部Erlang関数を呼ぶ。 TrCExL is a traced version of the CExL instruction. TrCExL
Byte-code Syntax:
| CExL/TrCExL_op |
|---|
| module name |
| function name |
| function arity |
| frame size |
Threaded-code Syntax:
| lb_CExL/TrCExL |
|---|
| module_name |
| function_name |
| function_arity |
| &FuncBegin |
| frame_size |
frame_size is a size of the current stack frame to be discarded. frame_sizeは破壊される今のスタックのサイズ
For info on other operands see CEx/TrCEx. ほかのオペランドの情報はCEx/TrCEx参照
CExL: Copy the continuation program pointer from the current stack frame into CP, discard the frame, increment number of reductions and check for suspension, check if the called external function is loaded, branch to the function. CExL: 継続ポインタ今のスタックをCPにコピー,フレーム破棄、簡約数の加算と停止検査、外部関数がロードさてるなら、関数を分岐する。
TrCExL: The same semantics as CExL but some trace information (the called function: module, name, arity) is sent to a tracing Erlang process. TrCExL: CExLと同じセマンティックしかしトレース情報（呼ばれた関数:モジュール、名前、引数）をErlangプロセスへ送る
R/ResR
R: Return from an Erlang function call. R: Erlangの関数呼び出しから戻る。
ResR: Return from a resident Erlang function call. ResR: Erlang呼び出し戻る。
Threaded-code Syntax:
| lb_R/ResR |
|---|
R: Restore the next instruction pointer from the current stack frame. Return control to the function caller. R: 今のスタックフレームから次のインストラクションポインタを復帰する。制御が呼び出し関数へもどる。
ResR: Go to instruction which address is stored in the CP register. ResR: CPレジスタに保存されているアドレスのインストラクションを実行。
TrR
A traced return from an Erlang function call. Erlang関数呼び出しからのリターンをトレース。
Threaded-code Syntax:
| lb_TrR |
|---|
| &FuncBegin |
The same semantics as R but some trace information (the function we return to: module, name, arity) is sent to a tracing Erlang process. Rと同じセマンティックしかしトレース情報（呼ばれた関数:モジュール、名前、引数）をErlangプロセスへ送る
ERR_ACT
Generate the FUNCTION_CLAUSE error (there are no Erlang clauses matching a given function call). FUNCTION_CLAUSEエラーを生成（）
Threaded-code Syntax:
| lb_ERR_ACT |
|---|
| &FuncBegin |
Generate the current context information using the &FuncBegin pointer, set the FUNCTION_CLAUSE error, branch to error handling procedure. &FuncBeginポインタを使った情報を今のコンテキストに生成、FUNCTION_CLAUSEエラーを設定、エラー処理に分岐する。
A
Allocate a new stack frame. 新しいスタックフレームをアロケート Threaded-code Syntax:
| lb_A |
|---|
| frame_size |
| n |
n is a number of live temporal variables x(0), ..., x(n-1) (for garbage collection purposes). nは一時変数x(0), ..., x(n-1)の値の数(ガベージコレクションに保証されている)
Check for required stack space, call garbage collection if necessary. 要求されたスタックスペースを検査、必要ならガベージコレクションを呼ぶ。
Allocate a new stack frame (of frame_size). Update the stack-top pointer E. 新しいスタックフレーム(のframe_size)をアロケートする。stack-top ポインタ Eを更新する。 Copy the continuation program pointer CP into the new frame. 継続ポインタCPを新しいフレームの中へコピーする。
I
Initialize a local variable (located in the current stack frame). 局所変数を初期化(今のスタックフレームに位置する)。 Threaded-code Syntax:
| lb_I |
|---|
| n |
n is an index of a local variable y(n) which must be explicitly initialized. nは初期化されていなければならいy(n)のインデックス。 Initialize a local variable y(n). 初期化された局所変数y(n)。
D
Discard the current stack frame. 今のスタックフレームを破棄する。 Threaded-code Syntax:
| lb_D |
|---|
| frame_size |
Copy the continuation program pointer from the current stack frame into CP, discard the frame. 継続ポインタを今のスタックフレームからCPにコピー、フレームを破棄。
Update the stack-top pointer E. stack-top pointerを更新。
TH
Check for required heap space. 要求されたヒープスペースを検査 Threaded-code Syntax:
| lb_TH |
|---|
| m |
| n |
m is a size of required heap space (in words). mは要求さたヒープサイズ(wordの)。
n is a number of live temporal variables x(0), ..., x(n-1) (for garbage collection purposes). nはテンポラリ変数 x(0), ..., x(n-1)の数(ガベージコレクション保証)。
Check for required heap space, call garbage collection if necessary. 要求されたヒープスペースを検査、必要ならガベージコレクションを呼ぶ。
3.4 Put Instructions
The put instructions are used to build new Erlang data objects. All objects are build on an Erlang process heap. In all cases the heap space requirements have been already checked. put インストラクションは新しいErangデータオブジェクトをつかう。全てのオブジェクトはErlangnoプロセスヒープ上に作られる. 全てのケースでヒープスペースはは既に検査が要求されている。
PL
Having head and tail build a new list. ヘッドとテイルを持つ新リストを作成
Threaded-code Syntax:
| lb_PL |
|---|
| type |
| head |
| type |
| tail |
| type |
| list |
type indicates sort of the following operand: X_arg - a temporal variable, Y_arg - a local variable, C_arg - a constant (atom, NIL, or a small integer). タイプは次のオペランドの種類を指している: X_arg - aの一時変数、Y_arg - aの局所変数、C_arg - aの定数。
Depending on its type, an operand can be an index (for X_arg and Y_arg) or ready created Erlang data object (for C_arg). タイプに依存する。オペランドはインデックス出来る。またはErlangデータオブジェクトの作成準備( C_argのため)
Having head and tail build a new list. Set list to the new created data object. Update the heap-top pointer, HTOP. ヘッドとテイルを持つ新リストを作成。新たに作成されたデータオブジェクトをリストに設定。 heap-top ポインタ、Htopを更新。
PL_
Having head and tail build a new list. PL_ is a specialized version of the PL instruction.
ヘッドとテイルを持つ新リストを作成。PL_は PLインストラクションの特殊バージョン。
Threaded-code Syntax:
| lb_PL_ |
|---|
| list |
| head |
| tail |
PL_ has the same semantics as the PL instruction.
PL_ はPLインストラクションと同じセマンティック。
The only difference is that types of all operands are coded implicitly as instruction opcode. 唯一の違いは全てのオペランドは、全てのオペランドを明示的にインストラクションオペランドをコード化しない。
For example PL_xyx means that the first and the third operands are temporal variables while the second operand is a local variable. たとえばPL_xyxは 最初と三番目のオペランドは一時変数だが、 二番目のオペランドは局所変数。
The decision which types are coded as specialized instructions has been based on their frequency in existing large industrial applications. typesの特殊コード化は大きな工業アプリケーションの頻度にもとづいて決定されています。
PS
Having a given string convert it to a corresponding list. Build the list. ストリングに対応するリストに対応する変更を与えています。リストを作成します。
Threaded-code Syntax:
| lb_PS |
|---|
| string_length |
| string_elements0 |
| ... |
| string_elementsN |
| type |
| list |
string_length is the length of the included string (number of string elements). string_lengthは含まれた文字列の長さです(数は文字列の要素数)。
string_elements is a 32-bit word consisting of four string elements (each 8-bit long). Depending on string_length the last string_elements can be shorter. string_elementsは４つの文字列の要素(それぞれ８ビット長)の３２ビットワードから成立しています。
type indicates sort of the following operand. タイプは次のオペランドの種類をさしています。
Having a string of a given length, build a new list consisting of the string elements. 文字列は新しいリストに長さをあたえます。新しいリストはストリングの要素からなっています。
Set list to the new created data object. リストは新しく作られたデータオブジェクトが設定されています。
Update the heap-top pointer, HTOP. heap-top pointer, HTOPを更新します。
PInt_
The PInt_ instruction followed by a number of PIntVal instructions is used to build a big number integer.
PInt_インストラクションは ビッグナンバー整数を作る時に使われるPIntValインストラクションの数に従っています。
Threaded-code Syntax:
| lb_PInt_ |
|---|
| pointer |
| arity |
| sign |
pointer is a pointer to the being created big number integer. ポインタは作成したビッグナンバー整数になります。
arity gives a number of following words with the big number value. 引数は ビッグナンバーの値のワードから数ｗ与えられます。
sign is the big number sign. signは数の符号です。
Create an initiall structure for a big number integer. 作成時にビッグナンバー整数の構造の初期化
The instruction is followed by an arity number of PIntVal instructions. インストラクションはPIntValインストラクションの引数の数によります。
Set pointer to the new created data object. Update the heap-top pointer.
The type of pointer is implicitly coded as instruction opcode. ポインタのタイプは非明示的コード化されたインストラクションオペコード。
PIntVal
Build a big number value. ビッグナンバーの値をつくる。
Threaded-code Syntax:
| lb_PIntVal |
|---|
| value |
value is a word being part of a big number integer value. valueはビッグナンバー整数値のバーツになります。
Put a value word on a process heap. プロセスヒープ上のワード値をおく。
The instruction must be preceded by the PInt_ instruction or other PIntVal instructions.
インストラクションは PInt_ インストラクションまたはほかのPIntValインストラクションの前になければならない。
Update the heap-top pointer. heap-topのポインタを更新する。
PFlt_
Build a double floating point number. 倍精度浮動小数点数ポインタの値を作る。
Threaded-code Syntax:
| lb_PFlt_ |
|---|
| pointer |
| value0 |
| value1 |
value0 and value1 build the double float value. value0 と value1は倍精度浮動小数点数の値
Put value0 and value1 on a process heap. value0 と value1はプロセスヒープ上に置かれる。
Set pointer to the new created data object. ポインタは新しく作られたデータオブジェクトを設定数する。
Update the heap-top pointer. heap-topのポインタを更新する。
The type of pointer is implicitly coded as instruction opcode. ポインタのタイプは非明示的にコード化されたオペコードに依存する。
PT0_
The PT0_ instruction followed by a number of PTEl_ instructions build a tuple. PT0_インストラクションはPTEl_が作るタプルの数による。 Threaded-code Syntax:
| lb_PT0_ |
|---|
| tuple |
| arity |
tuple is a pointer to the being created tuple data object. tupleはタプルデータオブジェクトのポインタ。
arity gives a number of following tuple elements. artyはタプル要素の数からあたえられる
Create an initial structure for a tuple data object. 初期化されたタプルデータオブジェクトを作る。
The instruction is followed by an arity number of PTEl_ instructions. インストラクションPTEl_インストラクションの引数の数に従います。
Set the tuple pointer to the new created object. 新しく作られたタプルポインタが設定されます。
Update the heap-top pointer. heap-topポインタを更新する。
The type of tuple is implicitly coded as instruction opcode. タプル型は非明示的にインストラクションオプコードをコード化する
PTEl_
Build a tuple element. Threaded-code Syntax:
| lb_PTEl_ |
|---|
| element |
element is a tuple element to be put on heap. elementはタプルの要素をヒープに置く。
Put a tuple element on a process heap. タプルの要素をプロセスのヒープに置く。
The instruction must be preceded by the PT0_ instruction or other PTEl_ instructions. インストラクションは必ずPT0_ またはPTEl_より先にある必要がある。
Update the heap-top pointer. heap-topポインタを更新する。
The type of element is implicitly coded as instruction opcode. タプル型は非明示的にインストラクションオプコードをコード化する
3.5 Get Instructions
The get instructions are used to match against Erlang function arguments, function return values, and Erlang variables. getインストラクションはErlang関数の引数にマッチさせるのに使われる、
The type of object matched has been already checked. マッチしたオブジェクトのタイプはすでに検査されている。
GL2_
Having a given list get its head and tail. リストはヘッダとテイルを持っている。
Threaded-code Syntax:
| lb_GL2_ |
|---|
| list |
| head |
| tail |
list is a pointer to existing list. listはリストのポインタ。
head and tail are pointers to respectively head and tail. ヘッダとテイルは それぞれのヘッダとテイルのポインタ。
Having a given list set the head pointer to its head and tail to its tail. リストにヘッダはヘッダテイルはテイルはテイルにセットされる。
Types of all operands are coded implicitly as instruction opcode. 全てのオペランドのタイプは非明示的にインストラクションオペコードがコード化される。
GTp_
Having a given tuple check its arity.
The instruction is followed by a number of the GTEl instructions. インストラクションはGTElインストラクションの数に従います
Threaded-code Syntax:
| lb_GTp_ |
|---|
| &FuncBegin |
| tuple |
| arity |
&FuncBegin is an address of the current function FuncBegin instruction. &FuncBeginは今の関数のFuncBeginインストラクションのアドレス。
tuple is a pointer to existing tuple. tupleはタプルのポインタ。
arity is the required arity. arityは要求された引数。
The instruction occurs only in a clause/case/if/receive body. インストラクションはbodyのclause/case/if/receiveのみ発生する。
Having a given tuple check its arity. タプルのarityのはチェックされている。
If not equal the required one (arity), generate the current context information (using &FuncBegin), set the BADMATCH error, and branch to error handling procedure. もし要求されたものの一つ(arity)が等しくないなら、今のコンテキスト情報を生成、(using &FuncBegin)にBADMATCHエラーを設定して、エラーハンドリング処理へ分岐する。
Type of tuple is coded implicitly as instruction opcode. タプルの型は非明示的にインストラクションオペコードにコード化される。
GTp_head_
Having a given tuple check its arity. 引数
GTp_head_ is a specialized version of the GTp_ instruction. GTp_head_はGTp_インストラクションの特別バージョンのです。
Threaded-code Syntax:
| lb_GTp_head_ |
|---|
| address |
| tuple |
| arity |
address is a branch address in a case of failure. addressは失敗した場合の分岐アドレス。
tuple is a pointer to existing tuple. tupleはタプルのポインタ。
arity is the required arity. arityは要求された引数。
The instruction occurs only in a clause/case/if/receive head. インストラクションはheadがclause/case/if/receiveの場合のみ発生。
Having a given tuple check its arity.
If not equal the required one, branch to the next clause/option using address. もし要求された一つが等しくないなら、次のclause/optionにアドレスを使って分岐。
Type of tuple is coded implicitly as instruction opcode. タプルの型は非明示的にインストラクションオペコードにコード化される。
GTEl_
Having a given tuple get its element. Threaded-code Syntax:
| lb_GTEl_ |
|---|
| tuple |
| element |
| index |
tuple is a pointer to existing tuple. tupleはタプルのポインタ。
element is a tuple element with required index. elementはタプル要素の要求されたindex。
Get a tuple element with required index. タプルのエレメンのは要求されたindexを取得。
The instruction must be preceded by the GTp_ or GTp_head_ instruction. インストラクションは GTp_ またはGTp_head_ インストラクションの先になければなりません。
Types of tuple and element are coded implicitly as instruction opcode. タプルの型は非明示的にインストラクションオペコードにコード化される。
3.6 Test Instructions
The test instructions are used to test types of Erlang data objects. testインストラクションはテストに使用されるErlangデータオブジェクトの型。
_
Check if a given Erlang data object has required data type. 与えられたErlangデータオブジェクトが要求されたデータタイプか検査。
The instruction usually precedes other get instructions インストラクションは普通他のgetインストラクションに先立っている succeeds if a data object is: もしデータオブジェクトがあるなら です: TNil - an empty list TNil - 空リスト TT - a tuple TT - タプル TNonEmpL - a non-empty list TNonEmpL - 空ではないリスト
Threaded-code Syntax:
| lb__ |
|---|
| &FuncBegin |
| object |
&FuncBegin is an address of the current function FuncBegin instruction. &FuncBegin は今の関数FuncBeginインストラクションのアドレス。
object is an existing Erlang data object. オペコードはErlangデータオブジェクトのオブジェクト。
The instruction occurs only in a clause/case/if/receive body. インストラクションはbodyがclause/case/if/receiveのみ発生。
Having a given data object check its type. データオブジェクトオブジェクト
In a case of failure, generate the current context information (using &FuncBegin), set the BADMATCH error, and branch to error handling procedure. 失敗した場合、今のコンテキスト情報を生成、(using &FuncBegin)にBADMATCHエラーを設定して、エラーハンドリング処理へ分岐する。
Type of object (X_arg, Y_arg, C_arg) is coded implicitly as instruction opcode. オブジェクトの型は(X_arg, Y_arg, C_arg)非明示的にコード化されたインストラクションオペコード。