2 @c This is part of the GNU Guile Reference Manual.
3 @c Copyright (C) 2008,2009,2010,2011,2013
4 @c Free Software Foundation, Inc.
5 @c See the file guile.texi for copying conditions.
7 @node A Virtual Machine for Guile
8 @section A Virtual Machine for Guile
10 Guile has both an interpreter and a compiler. To a user, the difference
11 is transparent---interpreted and compiled procedures can call each other
14 The difference is that the compiler creates and interprets bytecode
15 for a custom virtual machine, instead of interpreting the
16 S-expressions directly. Loading and running compiled code is faster
17 than loading and running source code.
19 The virtual machine that does the bytecode interpretation is a part of
20 Guile itself. This section describes the nature of Guile's virtual
27 * Variables and the VM::
36 For a long time, Guile only had an interpreter. Guile's interpreter
37 operated directly on the S-expression representation of Scheme source
40 But while the interpreter was highly optimized and hand-tuned, it still
41 performs many needless computations during the course of evaluating an
42 expression. For example, application of a function to arguments
43 needlessly consed up the arguments in a list. Evaluation of an
44 expression always had to figure out what the car of the expression is --
45 a procedure, a memoized form, or something else. All values have to be
46 allocated on the heap. Et cetera.
48 The solution to this problem was to compile the higher-level language,
49 Scheme, into a lower-level language for which all of the checks and
50 dispatching have already been done---the code is instead stripped to
51 the bare minimum needed to ``do the job''.
53 The question becomes then, what low-level language to choose? There
54 are many options. We could compile to native code directly, but that
55 poses portability problems for Guile, as it is a highly cross-platform
58 So we want the performance gains that compilation provides, but we
59 also want to maintain the portability benefits of a single code path.
60 The obvious solution is to compile to a virtual machine that is
61 present on all Guile installations.
63 The easiest (and most fun) way to depend on a virtual machine is to
64 implement the virtual machine within Guile itself. This way the
65 virtual machine provides what Scheme needs (tail calls, multiple
66 values, @code{call/cc}) and can provide optimized inline instructions
67 for Guile (@code{cons}, @code{struct-ref}, etc.).
69 So this is what Guile does. The rest of this section describes that VM
70 that Guile implements, and the compiled procedures that run on it.
72 Before moving on, though, we should note that though we spoke of the
73 interpreter in the past tense, Guile still has an interpreter. The
74 difference is that before, it was Guile's main evaluator, and so was
75 implemented in highly optimized C; now, it is actually implemented in
76 Scheme, and compiled down to VM bytecode, just like any other program.
77 (There is still a C interpreter around, used to bootstrap the compiler,
78 but it is not normally used at runtime.)
80 The upside of implementing the interpreter in Scheme is that we preserve
81 tail calls and multiple-value handling between interpreted and compiled
82 code. The downside is that the interpreter in Guile 2.2 is still slower
83 than the interpreter in 1.8. We hope the that the compiler's speed makes
84 up for the loss. In any case, once we have native compilation for
85 Scheme code, we expect the new self-hosted interpreter to beat the old
86 hand-tuned C implementation.
88 Also note that this decision to implement a bytecode compiler does not
89 preclude native compilation. We can compile from bytecode to native
90 code at runtime, or even do ahead of time compilation. More
91 possibilities are discussed in @ref{Extending the Compiler}.
94 @subsection VM Concepts
96 Compiled code is run by a virtual machine (VM). Each thread has its own
97 VM. The virtual machine executes the sequence of instructions in a
100 Each VM instruction starts by indicating which operation it is, and then
101 follows by encoding its source and destination operands. Each procedure
102 declares that it has some number of local variables, including the
103 function arguments. These local variables form the available operands
104 of the procedure, and are accessed by index.
106 The local variables for a procedure are stored on a stack. Calling a
107 procedure typically enlarges the stack, and returning from a procedure
108 shrinks it. Stack memory is exclusive to the virtual machine that owns
111 In addition to their stacks, virtual machines also have access to the
112 global memory (modules, global bindings, etc) that is shared among other
113 parts of Guile, including other VMs.
115 The registers that a VM has are as follows:
118 @item ip - Instruction pointer
119 @item sp - Stack pointer
120 @item fp - Frame pointer
123 In other architectures, the instruction pointer is sometimes called the
124 ``program counter'' (pc). This set of registers is pretty typical for
125 virtual machines; their exact meanings in the context of Guile's VM are
126 described in the next section.
129 @subsection Stack Layout
131 The stack of Guile's virtual machine is composed of @dfn{frames}. Each
132 frame corresponds to the application of one compiled procedure, and
133 contains storage space for arguments, local variables, and some
134 bookkeeping information (such as what to do after the frame is
137 While the compiler is free to do whatever it wants to, as long as the
138 semantics of a computation are preserved, in practice every time you
139 call a function, a new frame is created. (The notable exception of
140 course is the tail call case, @pxref{Tail Calls}.)
142 The structure of the top stack frame is as follows:
145 /------------------\ <- top of stack
149 | Local 0 | <- fp = SCM_FRAME_LOCALS_ADDRESS (fp)
152 | Dynamic link | <- fp - 2 = SCM_FRAME_LOWER_ADDRESS (fp)
154 | | <- fp - 3 = SCM_FRAME_PREVIOUS_SP (fp)
157 In the above drawing, the stack grows upward. Usually the procedure
158 being applied is in local 0, followed by the arguments from local 1.
159 After that are enough slots to store the various lexically-bound and
160 temporary values that are needed in the function's application.
162 The @dfn{return address} is the @code{ip} that was in effect before this
163 program was applied. When we return from this activation frame, we will
164 jump back to this @code{ip}. Likewise, the @dfn{dynamic link} is the
165 @code{fp} in effect before this program was applied.
167 To prepare for a non-tail application, Guile's VM will emit code that
168 shuffles the function to apply and its arguments into appropriate stack
169 slots, with two free slots below them. The call then initializes those
170 free slots with the current @code{ip} and @code{fp}, and updates
171 @code{ip} to point to the function entry, and @code{fp} to point to the
174 In this way, the dynamic link links the current frame to the previous
175 frame. Computing a stack trace involves traversing these frames.
177 @node Variables and the VM
178 @subsection Variables and the VM
180 Consider the following Scheme code as an example:
184 (lambda (b) (list foo a b)))
187 Within the lambda expression, @code{foo} is a top-level variable,
188 @code{a} is a lexically captured variable, and @code{b} is a local
191 Another way to refer to @code{a} and @code{b} is to say that @code{a} is
192 a ``free'' variable, since it is not defined within the lambda, and
193 @code{b} is a ``bound'' variable. These are the terms used in the
194 @dfn{lambda calculus}, a mathematical notation for describing functions.
195 The lambda calculus is useful because it is a language in which to
196 reason precisely about functions and variables. It is especially good
197 at describing scope relations, and it is for that reason that we mention
200 Guile allocates all variables on the stack. When a lexically enclosed
201 procedure with free variables---a @dfn{closure}---is created, it copies
202 those variables into its free variable vector. References to free
203 variables are then redirected through the free variable vector.
205 If a variable is ever @code{set!}, however, it will need to be
206 heap-allocated instead of stack-allocated, so that different closures
207 that capture the same variable can see the same value. Also, this
208 allows continuations to capture a reference to the variable, instead
209 of to its value at one point in time. For these reasons, @code{set!}
210 variables are allocated in ``boxes''---actually, in variable cells.
211 @xref{Variables}, for more information. References to @code{set!}
212 variables are indirected through the boxes.
214 Thus perhaps counterintuitively, what would seem ``closer to the
215 metal'', viz @code{set!}, actually forces an extra memory allocation
218 Going back to our example, @code{b} may be allocated on the stack, as
221 @code{a} may also be allocated on the stack, as it too is never
222 mutated. Within the enclosed lambda, its value will be copied into
223 (and referenced from) the free variables vector.
225 @code{foo} is a top-level variable, because @code{foo} is not
226 lexically bound in this example.
229 @subsection Compiled Procedures are VM Programs
231 By default, when you enter in expressions at Guile's REPL, they are
232 first compiled to bytecode. Then that bytecode is executed to produce a
233 value. If the expression evaluates to a procedure, the result of this
234 process is a compiled procedure.
236 A compiled procedure is a compound object consisting of its bytecode and
237 a reference to any captured lexical variables. In addition, when a
238 procedure is compiled, it has associated metadata written to side
239 tables, for instance a line number mapping, or its docstring. You can
240 pick apart these pieces with the accessors in @code{(system vm
241 program)}. @xref{Compiled Procedures}, for a full API reference.
243 A procedure may reference data that was statically allocated when the
244 procedure was compiled. For example, a pair of immediate objects
245 (@pxref{Immediate objects}) can be allocated directly in the memory
246 segment that contains the compiled bytecode, and accessed directly by
249 Another use for statically allocated data is to serve as a cache for a
250 bytecode. Top-level variable lookups are handled in this way. If the
251 @code{toplevel-box} instruction finds that it does not have a cached
252 variable for a top-level reference, it accesses other static data to
253 resolve the reference, and fills in the cache slot. Thereafter all
254 access to the variable goes through the cache cell. The variable's
255 value may change in the future, but the variable itself will not.
257 We can see how these concepts tie together by disassembling the
258 @code{foo} function we defined earlier to see what is going on:
261 scheme@@(guile-user)> (define (foo a) (lambda (b) (list foo a b)))
262 scheme@@(guile-user)> ,x foo
263 Disassembly of #<procedure foo (a)> at #x203be34:
265 0 (assert-nargs-ee/locals 2 1) ;; 1 arg, 1 local at (unknown file):1:0
266 1 (make-closure 2 6 1) ;; anonymous procedure at #x203be50 (1 free var)
267 4 (free-set! 2 1 0) ;; free var 0
270 ----------------------------------------
271 Disassembly of anonymous procedure at #x203be50:
273 0 (assert-nargs-ee/locals 2 3) ;; 1 arg, 3 locals at (unknown file):1:0
274 1 (toplevel-box 2 73 57 71 #t) ;; `foo'
276 7 (make-short-immediate 3 772) ;; ()
278 9 (free-ref 4 0 0) ;; free var 0
284 First there's some prelude, where @code{foo} checks that it was called
285 with only 1 argument. Then at @code{ip} 1, we allocate a new closure
286 and store it in slot 2. The `6' in the @code{(make-closure 2 6 1)} is a
287 relative offset from the instruction pointer of the code for the
290 A closure is code with data. We already have the code part initialized;
291 what remains is to set the data. @code{Ip} 4 initializes free variable
292 0 in the new closure with the value from local variable 1, which
293 corresponds to the first argument of @code{foo}: `a'. Finally we return
296 The second stanza disassembles the code for the closure. After the
297 prelude, we load the variable for the toplevel variable @code{foo} into
298 local variable 2. This lookup occurs lazily, the first time the
299 variable is actually referenced, and the location of the lookup is
300 cached so that future references are very cheap. @xref{Top-Level
301 Environment Instructions}, for more details. The @code{box-ref}
302 dereferences the variable cell, replacing the contents of local 2.
304 What follows is a sequence of conses to build up the result list.
305 @code{Ip} 7 makes the tail of the list. @code{Ip} 8 conses on the value
306 in local 1, corresponding to the first argument to the closure: `b'.
307 @code{Ip} 9 loads free variable 0 of local 0 -- the procedure being
308 called -- into slot 4, then @code{ip} 11 conses it onto the list.
309 Finally we cons local 2, containing the @code{foo} toplevel, onto the
310 front of the list, and we return it.
312 @node Instruction Set
313 @subsection Instruction Set
315 There are currently about 130 instructions in Guile's virtual machine.
316 These instructions represent atomic units of a program's execution.
317 Ideally, they perform one task without conditional branches, then
318 dispatch to the next instruction in the stream.
320 Instructions themselves are composed of 1 or more 32-bit units. The low
321 8 bits of the first word indicate the opcode, and the rest of
322 instruction describe the operands. There are a number of different ways
323 operands can be encoded.
327 An unsigned @var{n}-bit integer. Usually indicates the index of a local
328 variable, but some instructions interpret these operands as immediate
331 An offset from the current @code{ip}, in 32-bit units, as a signed
332 24-bit value. Indicates a bytecode address, for a relative jump.
335 An immediate Scheme value (@pxref{Immediate objects}), encoded directly
339 An immediate Scheme value, encoded as a pair of 32-bit words.
340 @code{a32} and @code{b32} values always go together on the same opcode,
341 and indicate the high and low bits, respectively. Normally only used on
344 A statically allocated non-immediate. The address of the non-immediate
345 is encoded as a signed 32-bit integer, and indicates a relative offset
346 in 32-bit units. Think of it as @code{SCM x = ip + offset}.
348 Indirect scheme value, like @code{n32} but indirected. Think of it as
349 @code{SCM *x = ip + offset}.
352 An ip-relative address, as a signed 32-bit integer. Could indicate a
353 bytecode address, as in @code{make-closure}, or a non-immediate address,
354 as with @code{static-patch!}.
356 @code{l32} and @code{lo32} are the same from the perspective of the
357 virtual machine. The difference is that an assembler might want to
358 allow an @code{lo32} address to be specified as a label and then some
359 number of words offset from that label, for example when patching a
360 field of a statically allocated object.
362 A boolean value: 1 for true, otherwise 0.
364 An ignored sequence of @var{n} bits.
367 An instruction is specified by giving its name, then describing its
368 operands. The operands are packed by 32-bit words, with earlier
369 operands occupying the lower bits.
371 For example, consider the following instruction specification:
373 @deftypefn Instruction {} free-set! u12:@var{dst} u12:@var{src} x8:@var{_} u24:@var{idx}
374 Set free variable @var{idx} from the closure @var{dst} to @var{src}.
377 The first word in the instruction will start with the 8-bit value
378 corresponding to the @var{free-set!} opcode in the low bits, followed by
379 @var{dst} and @var{src} as 12-bit values. The second word starts with 8
380 dead bits, followed by the index as a 24-bit immediate value.
382 Sometimes the compiler can figure out that it is compiling a special
383 case that can be run more efficiently. So, for example, while Guile
384 offers a generic test-and-branch instruction, it also offers specific
385 instructions for special cases, so that the following cases all have
386 their own test-and-branch instructions:
390 (if (not pred) then else)
391 (if (null? l) then else)
392 (if (not (null? l)) then else)
395 In addition, some Scheme primitives have their own inline
396 implementations. For example, in the previous section we saw
399 Guile's instruction set is a @emph{complete} instruction set, in that it
400 provides the instructions that are suited to the problem, and is not
401 concerned with making a minimal, orthogonal set of instructions. More
402 instructions may be added over time.
405 * Lexical Environment Instructions::
406 * Top-Level Environment Instructions::
407 * Procedure Call and Return Instructions::
408 * Function Prologue Instructions::
409 * Trampoline Instructions::
410 * Branch Instructions::
411 * Constant Instructions::
412 * Dynamic Environment Instructions::
413 * Miscellaneous Instructions::
414 * Inlined Scheme Instructions::
415 * Inlined Mathematical Instructions::
416 * Inlined Bytevector Instructions::
420 @node Lexical Environment Instructions
421 @subsubsection Lexical Environment Instructions
423 These instructions access and mutate the lexical environment of a
424 compiled procedure---its free and bound variables. @xref{Stack Layout},
425 for more information on the format of stack frames.
427 @deftypefn Instruction {} mov u12:@var{dst} u12:@var{src}
428 @deftypefnx Instruction {} long-mov u24:@var{dst} x8:@var{_} u24:@var{src}
429 Copy a value from one local slot to another.
431 As discussed previously, procedure arguments and local variables are
432 allocated to local slots. Guile's compiler tries to avoid shuffling
433 variables around to different slots, which often makes @code{mov}
434 instructions redundant. However there are some cases in which shuffling
435 is necessary, and in those cases, @code{mov} is the thing to use.
438 @deftypefn Instruction {} make-closure u24:@var{dst} l32:@var{offset} x8:@var{_} u24:@var{nfree}
439 Make a new closure, and write it to @var{dst}. The code for the closure
440 will be found at @var{offset} words from the current @code{ip}.
441 @var{offset} is a signed 32-bit integer. Space for @var{nfree} free
442 variables will be allocated.
444 The size of a closure is currently two words, plus one word per free
448 @deftypefn Instruction {} free-ref u12:@var{dst} u12:@var{src} x8:@var{_} u24:@var{idx}
449 Load free variable @var{idx} from the closure @var{src} into local slot
453 @deftypefn Instruction {} free-set! u12:@var{dst} u12:@var{src} x8:@var{_} u24:@var{idx}
454 Set free variable @var{idx} from the closure @var{dst} to @var{src}.
456 This instruction is usually used when initializing a closure's free
457 variables, but not to mutate free variables, as variables that are
461 Recall that variables that are assigned are usually allocated in boxes,
462 so that continuations and closures can capture their identity and not
463 their value at one point in time. Variables are also used in the
464 implementation of top-level bindings; see the next section for more
467 @deftypefn Instruction {} box u12:@var{dst} u12:@var{src}
468 Create a new variable holding @var{src}, and place it in @var{dst}.
471 @deftypefn Instruction {} box-ref u12:@var{dst} u12:@var{src}
472 Unpack the variable at @var{src} into @var{dst}, asserting that the
473 variable is actually bound.
476 @deftypefn Instruction {} box-set! u12:@var{dst} u12:@var{src}
477 Set the contents of the variable at @var{dst} to @var{set}.
481 @node Top-Level Environment Instructions
482 @subsubsection Top-Level Environment Instructions
484 These instructions access values in the top-level environment: bindings
485 that were not lexically apparent at the time that the code in question
488 The location in which a toplevel binding is stored can be looked up once
489 and cached for later. The binding itself may change over time, but its
490 location will stay constant.
492 @deftypefn Instruction {} current-module u24:@var{dst}
493 Store the current module in @var{dst}.
496 @deftypefn Instruction {} resolve u24:@var{dst} b1:@var{bound?} x7:@var{_} u24:@var{sym}
497 Resolve @var{sym} in the current module, and place the resulting
498 variable in @var{dst}. An error will be signalled if no variable is
499 found. If @var{bound?} is true, an error will be signalled if the
503 @deftypefn Instruction {} define! u12:@var{sym} u12:@var{val}
504 Look up a binding for @var{sym} in the current module, creating it if
505 necessary. Set its value to @var{val}.
508 @deftypefn Instruction {} toplevel-box u24:@var{dst} s32:@var{var-offset} s32:@var{mod-offset} n32:@var{sym-offset} b1:@var{bound?} x31:@var{_}
509 Load a value. The value will be fetched from memory, @var{var-offset}
510 32-bit words away from the current instruction pointer.
511 @var{var-offset} is a signed value. Up to here, @code{toplevel-box} is
512 like @code{static-ref}.
514 Then, if the loaded value is a variable, it is placed in @var{dst}, and
515 control flow continues.
517 Otherwise, we have to resolve the variable. In that case we load the
518 module from @var{mod-offset}, just as we loaded the variable. Usually
519 the module gets set when the closure is created. @var{sym-offset}
520 specifies the name, as an offset to a symbol.
522 We use the module and the symbol to resolve the variable, placing it in
523 @var{dst}, and caching the resolved variable so that we will hit the
524 cache next time. If @var{bound?} is true, an error will be signalled if
525 the variable is unbound.
528 @deftypefn Instruction {} module-box u24:@var{dst} s32:@var{var-offset} n32:@var{mod-offset} n32:@var{sym-offset} b1:@var{bound?} x31:@var{_}
529 Like @code{toplevel-box}, except @var{mod-offset} points at a module
530 identifier instead of the module itself. A module identifier is a
531 module name, as a list, prefixed by a boolean. If the prefix is true,
532 then the variable is resolved relative to the module's public interface
533 instead of its private interface.
537 @node Procedure Call and Return Instructions
538 @subsubsection Procedure Call and Return Instructions
540 As described earlier (@pxref{Stack Layout}), Guile's calling convention
541 is that arguments are passed and values returned on the stack.
543 For calls, both in tail position and in non-tail position, we require
544 that the procedure and the arguments already be shuffled into place
545 befor the call instruction. ``Into place'' for a tail call means that
546 the procedure should be in slot 0, and the arguments should follow. For
547 a non-tail call, if the procedure is in slot @var{n}, the arguments
548 should follow from slot @var{n}+1, and there should be two free slots at
549 @var{n}-1 and @var{n}-2 in which to save the @code{ip} and @code{fp}.
551 Returning values is similar. Multiple-value returns should have values
552 already shuffled down to start from slot 1 before emitting
553 @code{return-values}. There is a short-cut in the single-value case, in
554 that @code{return} handles the trivial shuffling itself. We start from
555 slot 1 instead of slot 0 to make tail calls to @code{values} trivial.
557 In both calls and returns, the @code{sp} is used to indicate to the
558 callee or caller the number of arguments or return values, respectively.
559 After receiving return values, it is the caller's responsibility to
560 @dfn{restore the frame} by resetting the @code{sp} to its former value.
562 @deftypefn Instruction {} call u24:@var{proc} x8:@var{_} u24:@var{nlocals}
563 Call a procedure. @var{proc} is the local corresponding to a procedure.
564 The two values below @var{proc} will be overwritten by the saved call
565 frame data. The new frame will have space for @var{nlocals} locals: one
566 for the procedure, and the rest for the arguments which should already
569 When the call returns, execution proceeds with the next instruction.
570 There may be any number of values on the return stack; the precise
571 number can be had by subtracting the address of @var{proc} from the
575 @deftypefn Instruction {} tail-call u24:@var{nlocals}
576 Tail-call a procedure. Requires that the procedure and all of the
577 arguments have already been shuffled into position. Will reset the
578 frame to @var{nlocals}.
581 @deftypefn Instruction {} tail-call/shuffle u24:@var{from}
582 Tail-call a procedure. The procedure should already be set to slot 0.
583 The rest of the args are taken from the frame, starting at @var{from},
584 shuffled down to start at slot 0. This is part of the implementation of
585 the @code{call-with-values} builtin.
588 @deftypefn Instruction {} receive u12:@var{dst} u12:@var{proc} x8:@var{_} u24:@var{nlocals}
589 Receive a single return value from a call whose procedure was in
590 @var{proc}, asserting that the call actually returned at least one
591 value. Afterwards, resets the frame to @var{nlocals} locals.
594 @deftypefn Instruction {} receive-values u24:@var{proc} b1:@var{allow-extra?} x7:@var{_} u24:@var{nvalues}
595 Receive a return of multiple values from a call whose procedure was in
596 @var{proc}. If fewer than @var{nvalues} values were returned, signal an
597 error. Unless @var{allow-extra?} is true, require that the number of
598 return values equals @var{nvalues} exactly. After @code{receive-values}
599 has run, the values can be copied down via @code{mov}, or used in place.
602 @deftypefn Instruction {} return u24:@var{src}
606 @deftypefn Instruction {} return-values x24:@var{_}
607 Return a number of values from a call frame. This opcode corresponds to
608 an application of @code{values} in tail position. As with tail calls,
609 we expect that the values have already been shuffled down to a
610 contiguous array starting at slot 1. We also expect the frame has
614 @deftypefn Instruction {} call/cc x24:@var{_}
615 Capture the current continuation, and tail-apply the procedure in local
616 slot 1 to it. This instruction is part of the implementation of
617 @code{call/cc}, and is not generated by the compiler.
621 @node Function Prologue Instructions
622 @subsubsection Function Prologue Instructions
624 A function call in Guile is very cheap: the VM simply hands control to
625 the procedure. The procedure itself is responsible for asserting that it
626 has been passed an appropriate number of arguments. This strategy allows
627 arbitrarily complex argument parsing idioms to be developed, without
628 harming the common case.
630 For example, only calls to keyword-argument procedures ``pay'' for the
631 cost of parsing keyword arguments. (At the time of this writing, calling
632 procedures with keyword arguments is typically two to four times as
633 costly as calling procedures with a fixed set of arguments.)
635 @deftypefn Instruction {} assert-nargs-ee u24:@var{expected}
636 @deftypefnx Instruction {} assert-nargs-ge u24:@var{expected}
637 @deftypefnx Instruction {} assert-nargs-le u24:@var{expected}
638 If the number of actual arguments is not @code{==}, @code{>=}, or
639 @code{<=} @var{expected}, respectively, signal an error.
641 The number of arguments is determined by subtracting the frame pointer
642 from the stack pointer (@code{sp + 1 - fp}). @xref{Stack Layout}, for
643 more details on stack frames. Note that @var{expected} includes the
647 @deftypefn Instruction {} br-if-nargs-ne u24:@var{expected} x8:@var{_} l24:@var{offset}
648 @deftypefnx Instruction {} br-if-nargs-lt u24:@var{expected} x8:@var{_} l24:@var{offset}
649 @deftypefnx Instruction {} br-if-nargs-gt u24:@var{expected} x8:@var{_} l24:@var{offset}
650 If the number of actual arguments is not equal, less than, or greater
651 than @var{expected}, respectively, add @var{offset}, a signed 24-bit
652 number, to the current instruction pointer. Note that @var{expected}
653 includes the procedure itself.
655 These instructions are used to implement multiple arities, as in
656 @code{case-lambda}. @xref{Case-lambda}, for more information.
659 @deftypefn Instruction {} alloc-frame u24:@var{nlocals}
660 Ensure that there is space on the stack for @var{nlocals} local
661 variables, setting them all to @code{SCM_UNDEFINED}, except those values
662 that are already on the stack.
665 @deftypefn Instruction {} reset-frame u24:@var{nlocals}
666 Like @code{alloc-frame}, but doesn't check that the stack is big enough,
667 and doesn't initialize values to @code{SCM_UNDEFINED}. Used to reset
668 the frame size to something less than the size that was previously set
672 @deftypefn Instruction {} assert-nargs-ee/locals u12:@var{expected} u12:@var{nlocals}
673 Equivalent to a sequence of @code{assert-nargs-ee} and
674 @code{reserve-locals}. The number of locals reserved is @var{expected}
678 @deftypefn Instruction {} br-if-npos-gt u24:@var{nreq} x8:@var{_} u24:@var{npos} x8:@var{_} l24:@var{offset}
679 Find the first positional argument after @var{nreq}. If it is greater
680 than @var{npos}, jump to @var{offset}.
682 This instruction is only emitted for functions with multiple clauses,
683 and an earlier clause has keywords and no rest arguments.
684 @xref{Case-lambda}, for more on how @code{case-lambda} chooses the
688 @deftypefn Instruction {} bind-kwargs u24:@var{nreq} u8:@var{flags} u24:@var{nreq-and-opt} x8:@var{_} u24:@var{ntotal} n32:@var{kw-offset}
689 @var{flags} is a bitfield, whose lowest bit is @var{allow-other-keys},
690 second bit is @var{has-rest}, and whose following six bits are unused.
692 Find the last positional argument, and shuffle all the rest above
693 @var{ntotal}. Initialize the intervening locals to
694 @code{SCM_UNDEFINED}. Then load the constant at @var{kw-offset} words
695 from the current @var{ip}, and use it and the @var{allow-other-keys}
696 flag to bind keyword arguments. If @var{has-rest}, collect all shuffled
697 arguments into a list, and store it in @var{nreq-and-opt}. Finally,
698 clear the arguments that we shuffled up.
700 The parsing is driven by a keyword arguments association list, looked up
701 using @var{kw-offset}. The alist is a list of pairs of the form
702 @code{(@var{kw} . @var{index})}, mapping keyword arguments to their
703 local slot indices. Unless @code{allow-other-keys} is set, the parser
704 will signal an error if an unknown key is found.
706 A macro-mega-instruction.
709 @deftypefn Instruction {} bind-rest u24:@var{dst}
710 Collect any arguments at or above @var{dst} into a list, and store that
715 @node Trampoline Instructions
716 @subsubsection Trampoline Instructions
718 Though most applicable objects in Guile are procedures implemented in
719 bytecode, not all are. There are primitives, continuations, and other
720 procedure-like objects that have their own calling convention. Instead
721 of adding special cases to the @code{call} instruction, Guile wraps
722 these other applicable objects in VM trampoline procedures, then
723 provides special support for these objects in bytecode.
725 Trampoline procedures are typically generated by Guile at runtime, for
726 example in response to a call to @code{scm_c_make_gsubr}. As such, a
727 compiler probably shouldn't emit code with these instructions. However,
728 it's still interesting to know how these things work, so we document
729 these trampoline instructions here.
731 @deftypefn Instruction {} subr-call u24:@var{ptr-idx}
732 Call a subr, passing all locals in this frame as arguments. Fetch the
733 foreign pointer from @var{ptr-idx}, a free variable. Return from the
737 @deftypefn Instruction {} foreign-call u12:@var{cif-idx} u12:@var{ptr-idx}
738 Call a foreign function. Fetch the @var{cif} and foreign pointer from
739 @var{cif-idx} and @var{ptr-idx}, both free variables. Return from the calling
740 frame. Arguments are taken from the stack.
743 @deftypefn Instruction {} continuation-call u24:@var{contregs}
744 Return to a continuation, nonlocally. The arguments to the continuation
745 are taken from the stack. @var{contregs} is a free variable containing
746 the reified continuation.
749 @deftypefn Instruction {} compose-continuation u24:@var{cont}
750 Compose a partial continution with the current continuation. The
751 arguments to the continuation are taken from the stack. @var{cont} is a
752 free variable containing the reified continuation.
755 @deftypefn Instruction {} tail-apply x24:@var{_}
756 Tail-apply the procedure in local slot 0 to the rest of the arguments.
757 This instruction is part of the implementation of @code{apply}, and is
758 not generated by the compiler.
761 @deftypefn Instruction {} builtin-ref u12:@var{dst} u12:@var{idx}
762 Load a builtin stub by index into @var{dst}.
766 @node Branch Instructions
767 @subsubsection Branch Instructions
769 All offsets to branch instructions are 24-bit signed numbers, which
770 count 32-bit units. This gives Guile effectively a 26-bit address range
773 @deftypefn Instruction {} br l24:@var{offset}
774 Add @var{offset} to the current instruction pointer.
777 All the conditional branch instructions described below have an
778 @var{invert} parameter, which if true reverses the test:
779 @code{br-if-true} becomes @code{br-if-false}, and so on.
781 @deftypefn Instruction {} br-if-true u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
782 If the value in @var{test} is true for the purposes of Scheme, add
783 @var{offset} to the current instruction pointer.
786 @deftypefn Instruction {} br-if-null u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
787 If the value in @var{test} is the end-of-list or Lisp nil, add
788 @var{offset} to the current instruction pointer.
791 @deftypefn Instruction {} br-if-nil u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
792 If the value in @var{test} is false to Lisp, add @var{offset} to the
793 current instruction pointer.
796 @deftypefn Instruction {} br-if-pair u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
797 If the value in @var{test} is a pair, add @var{offset} to the current
801 @deftypefn Instruction {} br-if-struct u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
802 If the value in @var{test} is a struct, add @var{offset} number to the
803 current instruction pointer.
806 @deftypefn Instruction {} br-if-char u24:@var{test} b1:@var{invert} x7:@var{_} l24:@var{offset}
807 If the value in @var{test} is a char, add @var{offset} to the current
811 @deftypefn Instruction {} br-if-tc7 u24:@var{test} b1:@var{invert} u7:@var{tc7} l24:@var{offset}
812 If the value in @var{test} has the TC7 given in the second word, add
813 @var{offset} to the current instruction pointer. TC7 codes are part of
814 the way Guile represents non-immediate objects, and are deep wizardry.
815 See @code{libguile/tags.h} for all the details.
818 @deftypefn Instruction {} br-if-eq u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
819 @deftypefnx Instruction {} br-if-eqv u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
820 @deftypefnx Instruction {} br-if-equal u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
821 If the value in @var{a} is @code{eq?}, @code{eqv?}, or @code{equal?} to
822 the value in @var{b}, respectively, add @var{offset} to the current
826 @deftypefn Instruction {} br-if-= u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
827 @deftypefnx Instruction {} br-if-< u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
828 @deftypefnx Instruction {} br-if-<= u12:@var{a} u12:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
829 If the value in @var{a} is @code{=}, @code{<}, or @code{<=} to the value
830 in @var{b}, respectively, add @var{offset} to the current instruction
835 @node Constant Instructions
836 @subsubsection Constant Instructions
838 The following instructions load literal data into a program. There are
841 The first set of instructions loads immediate values. These
842 instructions encode the immediate directly into the instruction stream.
844 @deftypefn Instruction {} make-short-immediate u8:@var{dst} i16:@var{low-bits}
845 Make an immediate whose low bits are @var{low-bits}, and whose top bits are
849 @deftypefn Instruction {} make-long-immediate u24:@var{dst} i32:@var{low-bits}
850 Make an immediate whose low bits are @var{low-bits}, and whose top bits are
854 @deftypefn Instruction {} make-long-long-immediate u24:@var{dst} a32:@var{high-bits} b32:@var{low-bits}
855 Make an immediate with @var{high-bits} and @var{low-bits}.
858 Non-immediate constant literals are referenced either directly or
859 indirectly. For example, Guile knows at compile-time what the layout of
860 a string will be like, and arranges to embed that object directly in the
861 compiled image. A reference to a string will use
862 @code{make-non-immediate} to treat a pointer into the compilation unit
863 as a @code{SCM} value directly.
865 @deftypefn Instruction {} make-non-immediate u24:@var{dst} n32:@var{offset}
866 Load a pointer to statically allocated memory into @var{dst}. The
867 object's memory is will be found @var{offset} 32-bit words away from the
868 current instruction pointer. Whether the object is mutable or immutable
869 depends on where it was allocated by the compiler, and loaded by the
873 Some objects must be unique across the whole system. This is the case
874 for symbols and keywords. For these objects, Guile arranges to
875 initialize them when the compilation unit is loaded, storing them into a
876 slot in the image. References go indirectly through that slot.
877 @code{static-ref} is used in this case.
879 @deftypefn Instruction {} static-ref u24:@var{dst} s32:@var{offset}
880 Load a @var{scm} value into @var{dst}. The @var{scm} value will be fetched from
881 memory, @var{offset} 32-bit words away from the current instruction
882 pointer. @var{offset} is a signed value.
885 Fields of non-immediates may need to be fixed up at load time, because
886 we do not know in advance at what address they will be loaded. This is
887 the case, for example, for a pair containing a non-immediate in one of
888 its fields. @code{static-ref} and @code{static-patch!} are used in
891 @deftypefn Instruction {} static-set! u24:@var{src} lo32:@var{offset}
892 Store a @var{scm} value into memory, @var{offset} 32-bit words away from the
893 current instruction pointer. @var{offset} is a signed value.
896 @deftypefn Instruction {} static-patch! x24:@var{_} lo32:@var{dst-offset} l32:@var{src-offset}
897 Patch a pointer at @var{dst-offset} to point to @var{src-offset}. Both offsets
898 are signed 32-bit values, indicating a memory address as a number
899 of 32-bit words away from the current instruction pointer.
902 Many kinds of literals can be loaded with the above instructions, once
903 the compiler has prepared the statically allocated data. This is the
904 case for vectors, strings, uniform vectors, pairs, and procedures with
905 no free variables. Other kinds of data might need special initializers;
906 those instructions follow.
908 @deftypefn Instruction {} string->number u12:@var{dst} u12:@var{src}
909 Parse a string in @var{src} to a number, and store in @var{dst}.
912 @deftypefn Instruction {} string->symbol u12:@var{dst} u12:@var{src}
913 Parse a string in @var{src} to a symbol, and store in @var{dst}.
916 @deftypefn Instruction {} symbol->keyword u12:@var{dst} u12:@var{src}
917 Make a keyword from the symbol in @var{src}, and store it in @var{dst}.
920 @deftypefn Instruction {} load-typed-array u8:@var{dst} u8:@var{type} u8:@var{shape} n32:@var{offset} u32:@var{len}
921 Load the contiguous typed array located at @var{offset} 32-bit words away
922 from the instruction pointer, and store into @var{dst}. @var{len} is a byte
923 length. @var{offset} is signed.
927 @node Dynamic Environment Instructions
928 @subsubsection Dynamic Environment Instructions
930 Guile's virtual machine has low-level support for @code{dynamic-wind},
931 dynamic binding, and composable prompts and aborts.
933 @deftypefn Instruction {} abort x24:@var{_}
934 Abort to a prompt handler. The tag is expected in slot 1, and the rest
935 of the values in the frame are returned to the prompt handler. This
936 corresponds to a tail application of abort-to-prompt.
938 If no prompt can be found in the dynamic environment with the given tag,
939 an error is signalled. Otherwise all arguments are passed to the
940 prompt's handler, along with the captured continuation, if necessary.
942 If the prompt's handler can be proven to not reference the captured
943 continuation, no continuation is allocated. This decision happens
944 dynamically, at run-time; the general case is that the continuation may
945 be captured, and thus resumed. A reinstated continuation will have its
946 arguments pushed on the stack from slot 1, as if from a multiple-value
947 return, and control resumes in the caller. Thus to the calling
948 function, a call to @code{abort-to-prompt} looks like any other function
952 @deftypefn Instruction {} prompt u24:@var{tag} b1:@var{escape-only?} x7:@var{_} u24:@var{proc-slot} x8:@var{_} l24:@var{handler-offset}
953 Push a new prompt on the dynamic stack, with a tag from @var{tag} and a
954 handler at @var{handler-offset} words from the current @var{ip}.
956 If an abort is made to this prompt, control will jump to the handler.
957 The handler will expect a multiple-value return as if from a call with
958 the procedure at @var{proc-slot}, with the reified partial continuation
959 as the first argument, followed by the values returned to the handler.
960 If control returns to the handler, the prompt is already popped off by
961 the abort mechanism. (Guile's @code{prompt} implements Felleisen's
962 @dfn{--F--} operator.)
964 If @var{escape-only?} is nonzero, the prompt will be marked as
965 escape-only, which allows an abort to this prompt to avoid reifying the
968 @xref{Prompts}, for more information on prompts.
971 @deftypefn Instruction {} wind u12:@var{winder} u12:@var{unwinder}
972 Push wind and unwind procedures onto the dynamic stack. Note that
973 neither are actually called; the compiler should emit calls to wind and
974 unwind for the normal dynamic-wind control flow. Also note that the
975 compiler should have inserted checks that they wind and unwind procs are
976 thunks, if it could not prove that to be the case. @xref{Dynamic Wind}.
979 @deftypefn Instruction {} unwind x24:@var{_}
980 @var{a} normal exit from the dynamic extent of an expression. Pop the top
981 entry off of the dynamic stack.
984 @deftypefn Instruction {} push-fluid u12:@var{fluid} u12:@var{value}
985 Dynamically bind @var{value} to @var{fluid} by creating a with-fluids
986 object and pushing that object on the dynamic stack. @xref{Fluids and
990 @deftypefn Instruction {} pop-fluid x24:@var{_}
991 Leave the dynamic extent of a @code{with-fluid*} expression, restoring
992 the fluid to its previous value. @code{push-fluid} should always be
993 balanced with @code{pop-fluid}.
996 @deftypefn Instruction {} fluid-ref u12:@var{dst} u12:@var{src}
997 Reference the fluid in @var{src}, and place the value in @var{dst}.
1000 @deftypefn Instruction {} fluid-set u12:@var{fluid} u12:@var{val}
1001 Set the value of the fluid in @var{dst} to the value in @var{src}.
1005 @node Miscellaneous Instructions
1006 @subsubsection Miscellaneous Instructions
1008 @deftypefn Instruction {} halt x24:@var{_}
1009 Bring the VM to a halt, returning all the values from the stack. Used
1010 in the ``boot continuation'', which is used when entering the VM from C.
1014 @node Inlined Scheme Instructions
1015 @subsubsection Inlined Scheme Instructions
1017 The Scheme compiler can recognize the application of standard Scheme
1018 procedures. It tries to inline these small operations to avoid the
1019 overhead of creating new stack frames. This allows the compiler to
1022 @deftypefn Instruction {} make-vector/immediate u8:@var{dst} u8:@var{length} u8:@var{init}
1023 Make a short vector of known size and write it to @var{dst}. The vector
1024 will have space for @var{length} slots, an immediate value. They will
1025 be filled with the value in slot @var{init}.
1028 @deftypefn Instruction {} vector-length u12:@var{dst} u12:@var{src}
1029 Store the length of the vector in @var{src} in @var{dst}.
1032 @deftypefn Instruction {} vector-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1033 Fetch the item at position @var{idx} in the vector in @var{src}, and
1034 store it in @var{dst}.
1037 @deftypefn Instruction {} vector-ref/immediate u8:@var{dst} u8:@var{src} u8:@var{idx}
1038 Fill @var{dst} with the item @var{idx} elements into the vector at
1039 @var{src}. Useful for building data types using vectors.
1042 @deftypefn Instruction {} vector-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1043 Store @var{src} into the vector @var{dst} at index @var{idx}.
1046 @deftypefn Instruction {} vector-set!/immediate u8:@var{dst} u8:@var{idx} u8:@var{src}
1047 Store @var{src} into the vector @var{dst} at index @var{idx}. Here
1048 @var{idx} is an immediate value.
1051 @deftypefn Instruction {} struct-vtable u12:@var{dst} u12:@var{src}
1052 Store the vtable of @var{src} into @var{dst}.
1055 @deftypefn Instruction {} allocate-struct/immediate u8:@var{dst} u8:@var{vtable} u8:@var{nfields}
1056 Allocate a new struct with @var{vtable}, and place it in @var{dst}. The
1057 struct will be constructed with space for @var{nfields} fields, which
1058 should correspond to the field count of the @var{vtable}.
1061 @deftypefn Instruction {} struct-ref/immediate u8:@var{dst} u8:@var{src} u8:@var{idx}
1062 Fetch the item at slot @var{idx} in the struct in @var{src}, and store
1063 it in @var{dst}. @var{idx} is an immediate unsigned 8-bit value.
1066 @deftypefn Instruction {} struct-set!/immediate u8:@var{dst} u8:@var{idx} u8:@var{src}
1067 Store @var{src} into the struct @var{dst} at slot @var{idx}. @var{idx}
1068 is an immediate unsigned 8-bit value.
1071 @deftypefn Instruction {} class-of u12:@var{dst} u12:@var{type}
1072 Store the vtable of @var{src} into @var{dst}.
1075 @deftypefn Instruction {} make-array u12:@var{dst} u12:@var{type} x8:@var{_} u12:@var{fill} u12:@var{bounds}
1076 Make a new array with @var{type}, @var{fill}, and @var{bounds}, storing it in @var{dst}.
1079 @deftypefn Instruction {} string-length u12:@var{dst} u12:@var{src}
1080 Store the length of the string in @var{src} in @var{dst}.
1083 @deftypefn Instruction {} string-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1084 Fetch the character at position @var{idx} in the string in @var{src}, and store
1088 @deftypefn Instruction {} cons u8:@var{dst} u8:@var{car} u8:@var{cdr}
1089 Cons @var{car} and @var{cdr}, and store the result in @var{dst}.
1092 @deftypefn Instruction {} car u12:@var{dst} u12:@var{src}
1093 Place the car of @var{src} in @var{dst}.
1096 @deftypefn Instruction {} cdr u12:@var{dst} u12:@var{src}
1097 Place the cdr of @var{src} in @var{dst}.
1100 @deftypefn Instruction {} set-car! u12:@var{pair} u12:@var{car}
1101 Set the car of @var{dst} to @var{src}.
1104 @deftypefn Instruction {} set-cdr! u12:@var{pair} u12:@var{cdr}
1105 Set the cdr of @var{dst} to @var{src}.
1108 Note that @code{caddr} and friends compile to a series of @code{car}
1109 and @code{cdr} instructions.
1112 @node Inlined Mathematical Instructions
1113 @subsubsection Inlined Mathematical Instructions
1115 Inlining mathematical operations has the obvious advantage of handling
1116 fixnums without function calls or allocations. The trick, of course,
1117 is knowing when the result of an operation will be a fixnum, and there
1118 might be a couple bugs here.
1120 More instructions could be added here over time.
1122 All of these operations place their result in their first operand,
1125 @deftypefn Instruction {} add u8:@var{dst} u8:@var{a} u8:@var{b}
1126 Add @var{a} to @var{b}.
1129 @deftypefn Instruction {} add1 u12:@var{dst} u12:@var{src}
1130 Add 1 to the value in @var{src}.
1133 @deftypefn Instruction {} sub u8:@var{dst} u8:@var{a} u8:@var{b}
1134 Subtract @var{b} from @var{a}.
1137 @deftypefn Instruction {} sub1 u12:@var{dst} u12:@var{src}
1138 Subtract 1 from @var{src}.
1141 @deftypefn Instruction {} mul u8:@var{dst} u8:@var{a} u8:@var{b}
1142 Multiply @var{a} and @var{b}.
1145 @deftypefn Instruction {} div u8:@var{dst} u8:@var{a} u8:@var{b}
1146 Divide @var{a} by @var{b}.
1149 @deftypefn Instruction {} quo u8:@var{dst} u8:@var{a} u8:@var{b}
1150 Divide @var{a} by @var{b}.
1153 @deftypefn Instruction {} rem u8:@var{dst} u8:@var{a} u8:@var{b}
1154 Divide @var{a} by @var{b}.
1157 @deftypefn Instruction {} mod u8:@var{dst} u8:@var{a} u8:@var{b}
1158 Compute the modulo of @var{a} by @var{b}.
1161 @deftypefn Instruction {} ash u8:@var{dst} u8:@var{a} u8:@var{b}
1162 Shift @var{a} arithmetically by @var{b} bits.
1165 @deftypefn Instruction {} logand u8:@var{dst} u8:@var{a} u8:@var{b}
1166 Compute the bitwise @code{and} of @var{a} and @var{b}.
1169 @deftypefn Instruction {} logior u8:@var{dst} u8:@var{a} u8:@var{b}
1170 Compute the bitwise inclusive @code{or} of @var{a} with @var{b}.
1173 @deftypefn Instruction {} logxor u8:@var{dst} u8:@var{a} u8:@var{b}
1174 Compute the bitwise exclusive @code{or} of @var{a} with @var{b}.
1178 @node Inlined Bytevector Instructions
1179 @subsubsection Inlined Bytevector Instructions
1181 Bytevector operations correspond closely to what the current hardware
1182 can do, so it makes sense to inline them to VM instructions, providing
1183 a clear path for eventual native compilation. Without this, Scheme
1184 programs would need other primitives for accessing raw bytes -- but
1185 these primitives are as good as any.
1187 @deftypefn Instruction {} bv-u8-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1188 @deftypefnx Instruction {} bv-s8-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1189 @deftypefnx Instruction {} bv-u16-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1190 @deftypefnx Instruction {} bv-s16-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1191 @deftypefnx Instruction {} bv-u32-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1192 @deftypefnx Instruction {} bv-s32-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1193 @deftypefnx Instruction {} bv-u64-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1194 @deftypefnx Instruction {} bv-s64-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1195 @deftypefnx Instruction {} bv-f32-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1196 @deftypefnx Instruction {} bv-f64-ref u8:@var{dst} u8:@var{src} u8:@var{idx}
1198 Fetch the item at byte offset @var{idx} in the bytevector @var{src}, and
1199 store it in @var{dst}. All accesses use native endianness.
1202 @deftypefn Instruction {} bv-u8-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1203 @deftypefnx Instruction {} bv-s8-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1204 @deftypefnx Instruction {} bv-u16-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1205 @deftypefnx Instruction {} bv-s16-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1206 @deftypefnx Instruction {} bv-u32-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1207 @deftypefnx Instruction {} bv-s32-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1208 @deftypefnx Instruction {} bv-u64-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1209 @deftypefnx Instruction {} bv-s64-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1210 @deftypefnx Instruction {} bv-f32-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1211 @deftypefnx Instruction {} bv-f64-set! u8:@var{dst} u8:@var{idx} u8:@var{src}
1213 Store @var{src} into the bytevector @var{dst} at byte offset @var{idx}.
1214 Multibyte values are written using native endianness.