Documentation Source Text

registers.  For instructions that operate on b-tree cursors,
the P1 operand is usually the cursor number.
For jump instructions, P2 is usually the jump destination.
P4 may be a 32-bit signed integer, a 64-bit signed integer, a
64-bit floating point value, a string literal, a Blob literal,
a pointer to a collating sequence comparison function, or a
pointer to the implementation of an application-defined SQL
function, or various other things.  P5 is an unsigned character
normally used as a flag.  Bits of the P5 flag can sometimes affect
the opcode in subtle ways.  For example, if the 
SQLITE_NULLEQ (0x80) bit of the P5 operand
is set on the OP_Eq opcode, then the NULL values compare
equal to one another.  Otherwise NULL values compare different
from one another.
}
</tcl>

<p>Some opcodes use all five operands.  Some opcodes use
................................................................................
Most opcodes refer to at least one register.

<p>The number of registers in a single prepared statement is fixed
at compile-time.  The content of all registers is cleared when
a prepared statement is [sqlite3_reset()|reset] or
[sqlite3_finalize()|finalized].





<h2>B-Tree Cursors</h2>

<tcl>
LinkOpcodeNames {
<p>A prepared statement can have
zero or more open cursors.  Each cursor is identified by a
small integer, which is usually the P1 parameter to the opcode
................................................................................
advance the cursor to the next entry in the table
(ex: OP_Next or OP_Prev), and so forth.
All cursors are automatically
closed when the prepared statement is [sqlite3_reset()|reset] or
[sqlite3_finalize()|finalized].
}
</tcl>






































<h1>Viewing The Bytecode</h1>

<p>Every SQL statement that SQLite interprets results in a program
for the virtual machine.  But if the SQL statement begins with
the keyword [EXPLAIN] the virtual machine will not execute the
program.  Instead, the instructions of the program will be returned,

registers.  For instructions that operate on b-tree cursors,
the P1 operand is usually the cursor number.
For jump instructions, P2 is usually the jump destination.
P4 may be a 32-bit signed integer, a 64-bit signed integer, a
64-bit floating point value, a string literal, a Blob literal,
a pointer to a collating sequence comparison function, or a
pointer to the implementation of an application-defined SQL
function, or various other things.  P5 is an 16-bit unsigned integer
normally used to hold flags.  Bits of the P5 flag can sometimes affect
the opcode in subtle ways.  For example, if the 
SQLITE_NULLEQ (0x0080) bit of the P5 operand
is set on the OP_Eq opcode, then the NULL values compare
equal to one another.  Otherwise NULL values compare different
from one another.
}
</tcl>

<p>Some opcodes use all five operands.  Some opcodes use
................................................................................
Most opcodes refer to at least one register.

<p>The number of registers in a single prepared statement is fixed
at compile-time.  The content of all registers is cleared when
a prepared statement is [sqlite3_reset()|reset] or
[sqlite3_finalize()|finalized].

<p>The internal Mem object stores the value for a single register.
The abstract [sqlite3_value] object that is exposed in the API is really
just a Mem object or register.

<h2>B-Tree Cursors</h2>

<tcl>
LinkOpcodeNames {
<p>A prepared statement can have
zero or more open cursors.  Each cursor is identified by a
small integer, which is usually the P1 parameter to the opcode
................................................................................
advance the cursor to the next entry in the table
(ex: OP_Next or OP_Prev), and so forth.
All cursors are automatically
closed when the prepared statement is [sqlite3_reset()|reset] or
[sqlite3_finalize()|finalized].
}
</tcl>

<h2>Subroutines, Coroutines, and Subprograms</h2>

<p>The bytecode engine has no stack on which to store the return address
of a subroutine.  Return addresses must be stored in registers.
Hence, bytecode subroutines are not reentrant.

<tcl>
LinkOpcodeNames {
<p>The OP_Gosub opcode stores the current program counter into
register P1 then jumps to address P2.  The OP_Return opcode jumps
to address P1+1.  Hence, every subroutine is associated with two integers:
the address of the entry point in the subroutine and the register number
that is used to hold the return address.

<p>The OP_Yield opcode swaps the value of the program counter with
the integer value in register P1.  This opcode is used to implement
coroutines.  Coroutines are often used to implement subqueries from
which content is pulled on an as-needed basis.
}
</tcl>

<p>[CREATE TRIGGER|Triggers] need to be reentrant.

<tcl>
LinkOpcodeNames {
Since bytecode
subroutines are not reentrant a different mechanism must be used to
implmeent triggers.  Each trigger is implemented using a separate bytecode
pragram with its own opcodes, program counter, and register set.  The
OP_Program opcode invokes the trigger subprogram.  The OP_Program instruction
allocates and initializes a fresh register set for each invocation of the
subprogram, so subprograms can be reentrant and recursive.  The
OP_Param opcode is used by subprograms to access content in registers
of the calling bytecode program.
}
</tcl>

<h1>Viewing The Bytecode</h1>

<p>Every SQL statement that SQLite interprets results in a program
for the virtual machine.  But if the SQL statement begins with
the keyword [EXPLAIN] the virtual machine will not execute the
program.  Instead, the instructions of the program will be returned,