From 8103fc4b5061a5b3f9e674087f48f0db44b44000 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sat, 27 Mar 2021 10:09:53 -0400 Subject: More accurate bytecode information --- docs/implementation/vm.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'docs/implementation') diff --git a/docs/implementation/vm.html b/docs/implementation/vm.html index bb99151c..f00f64ac 100644 --- a/docs/implementation/vm.html +++ b/docs/implementation/vm.html @@ -8,22 +8,24 @@

BQN's self-hosted compiler and runtime mean that only a small amount of native code is needed to run BQN on any given platform. For example, the Javascript environment requires about 300 lines of Javascript code even though it compiles BQN bytecode to Javascript, a more complex strategy than interpreting it directly. This makes it fairly easy to port BQN to new platforms, allowing BQN to run "natively" within other programming languages and interact with arrays in those languages.

Bytecode

The BQN implementation here and dzaima/BQN share a stack-based object code format used to represent compiled code. This format is a list of numbers of unspecified precision (small precision will limit the length of list literals and number of locals per block, blocks, and constants). Previously it was encoded as bytes with the LEB128 format; while it no longer has anything to do with bytes it's called a "bytecode" because this is shorter than "object code".

-

dzaima/BQN can interpret bytecode or convert it to JVM bytecode, while the Javascript VM previously interpreted bytecode but now always compiles it. Since interpretation is a simpler strategy, it may be helpful to use the old Javascript bytecode interpreter as a reference when implementing a BQN virtual machine.

+

The self-hosted compiler uses a simpler, and less capable, format for block and variable data than dzaima/BQN. Only this format is described here; dc.bqn adapts it to be compatible with dzaima/BQN.

+

dzaima/BQN can interpret bytecode or convert it to JVM bytecode, while the Javascript VM previously interpreted bytecode but now always compiles it. Since interpretation is a simpler strategy, it may be helpful to use the old Javascript bytecode interpreter as a reference (for bytecode execution only) when implementing a BQN virtual machine.

Components

The complete bytecode for a program consists of the following:

Blocks

Each block in blocks is a list of the following properties:

Compilation separates blocks so that they are not nested in bytecode. All compiled code is contained in some block. The self-hosted compiler compiles the entire program into an immediate block, and the program is run by evaluating this block. Blocks are terminated with the RETN instruction.

The starting index refers to the position where execution starts in order to evaluate the block. When the block is evaluated depends on its type and immediateness. An immediate block (0,1) is evaluated as soon as it is pushed; a function (0,0) is evaluated when called on arguments, an immediate modifier (1 or 2, 1) is evaluated when called on operands, and a deferred modifier (1 or 2, 0) creates a derived function when called on operands and is evaluated when this derived function is called on arguments.

-- cgit v1.2.3