2024-03-20 09:31:14 +00:00
|
|
|
# Dust
|
|
|
|
|
2024-12-10 13:04:47 +00:00
|
|
|
A programming language that is **fast**, **safe** and **easy to use**.
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
Dust's syntax, safety features and evaluation model are inspired by Rust. The instruction set,
|
|
|
|
optimization strategies and virtual machine are inspired by Lua and academic research in the field
|
|
|
|
(see the [Inspiration](README#Inspiration). Unlike Rust and most other compiled languages, Dust has
|
|
|
|
a very low time to execution. Unlike Lua and most other interpreted languages, Dust enforces static
|
|
|
|
typing during compilation, with a simple yet powerful type system that enhances clarity and prevents
|
|
|
|
bugs.
|
|
|
|
|
|
|
|
```rust
|
2024-11-30 04:58:33 +00:00
|
|
|
write_line("Enter your name...")
|
|
|
|
|
|
|
|
let name = read_line()
|
|
|
|
|
|
|
|
write_line("Hello " + name + "!")
|
|
|
|
```
|
2024-08-02 19:10:29 +00:00
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
```rust
|
|
|
|
fn fib (n: int) -> int {
|
|
|
|
if n <= 0 { return 0 }
|
|
|
|
if n == 1 { return 1 }
|
|
|
|
|
|
|
|
fib(n - 1) + fib(n - 2)
|
|
|
|
}
|
|
|
|
|
|
|
|
write_line(fib(25))
|
|
|
|
```
|
|
|
|
|
|
|
|
Dust uses the same library for error reporting as Rust, which provides ample opportunities to show
|
|
|
|
the user where they went wrong and how to fix it. Helpful error messages are a high priority and the
|
|
|
|
language will not be considered stable until they are consistently informative and actionable.
|
|
|
|
|
|
|
|
```
|
|
|
|
error: Compilation Error: Cannot add these types
|
|
|
|
|
|
|
|
|
1 | 40 + 2.0
|
|
|
|
| -- info: A value of type "int" was used here.
|
|
|
|
|
|
|
|
|
1 | 40 + 2.0
|
|
|
|
| --- info: A value of type "float" was used here.
|
|
|
|
|
|
|
|
|
1 | 40 + 2.0
|
|
|
|
| -------- help: Type "int" cannot be added to type "float". Try converting one of the values to the other type.
|
|
|
|
|
|
|
|
|
```
|
2024-12-10 13:04:47 +00:00
|
|
|
|
|
|
|
## Project Status
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
**Dust is under active development and is not yet ready for general use.**
|
|
|
|
|
|
|
|
**Features discussed in this README may be unimplemented, partially implemented, temporarily removed
|
|
|
|
or only available on a seperate branch.**
|
|
|
|
|
|
|
|
Dust is an ambitious project that acts as a continuous experiment in language design. Features may
|
|
|
|
be redesigned and reimplemented at will when they do not meet the project's performance or
|
|
|
|
usability goals. This approach maximizes the development experience as a learning opportunity and
|
|
|
|
enforces a high standard of quality but slows down the process of delivering features to users.
|
|
|
|
Eventually, Dust will reach a stable release and will be ready for general use. As the project
|
|
|
|
approaches this milestone, the experimental nature of the project will be reduced and a replaced
|
|
|
|
with a focus on stability and improvement.
|
|
|
|
|
|
|
|
## Language Overview
|
|
|
|
|
|
|
|
### Syntax
|
|
|
|
|
|
|
|
Dust belongs to the C-like family of languages, with an imperative syntax that will be familiar to
|
|
|
|
many programmers. Dust code looks a lot like Ruby, JavaScript, TypeScript and other members of the
|
|
|
|
family but Rust is its primary point of reference for syntax. Rust was chosen as a syntax model
|
|
|
|
because its imperative code is *obvious* and *familiar*. Those qualities are aligned with Dust's
|
|
|
|
emphasis on safety and usability. However, some differences exist because Dust is a simpler language
|
|
|
|
that can tolerate more relaxed syntax. For example, Dust has more relaxed rules about semicolons:
|
|
|
|
they can be used to suppress values (like in Rust) but are not required at the end of every
|
|
|
|
statement.
|
|
|
|
|
|
|
|
In this example, these semicolons are optional. Because these `let` statements do not return a
|
|
|
|
value, the semicolons have nothing to suppress and are ignored.
|
|
|
|
|
|
|
|
```dust
|
|
|
|
let a = 40;
|
|
|
|
let b = 2;
|
|
|
|
|
|
|
|
write_line("The answer is ", a + b);
|
|
|
|
```
|
|
|
|
|
|
|
|
One could write the above program without any semicolons at all.
|
|
|
|
|
|
|
|
```dust
|
|
|
|
let x = 10
|
|
|
|
let y = 3
|
|
|
|
|
|
|
|
write_line("The remainder is ", x % y)
|
|
|
|
```
|
|
|
|
|
|
|
|
The next example produces a compiler error because the `if` block returns a value of type `int` but
|
|
|
|
the `else` block does not return a value at all. Dust does not allow branches of the same `if/else`
|
|
|
|
statement to return different types of values. In this case, adding a semicolon after the `777`
|
|
|
|
expression fixes the error by supressing the value.
|
|
|
|
|
|
|
|
```dust
|
|
|
|
let input = read_line()
|
|
|
|
|
|
|
|
if input == "42" {
|
|
|
|
write_line("You got it! Here's your reward.")
|
|
|
|
|
|
|
|
777
|
|
|
|
} else {
|
|
|
|
write_line("That is not the answer.")
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
Remember that even if some syntax is optional, that does not mean it should always be omitted or is
|
|
|
|
not useful. Aside from their practical use, semicolons provide a visual barrier between statements
|
|
|
|
written on the same line. Dust's design philosophy is to provide a balance between strictness and
|
|
|
|
expressiveness so that the language is applicable to a wide range of use cases. A web server with a
|
|
|
|
team of developers may prefer a more long-form style of code with lots of line breaks while a user
|
|
|
|
writing Dust on the command line may prefer a more terse style without sacrificing readability.
|
|
|
|
|
|
|
|
```dust
|
|
|
|
let a = 0; let b = 1; let c = 2; let list = [a, b, c];
|
|
|
|
|
|
|
|
write_line("Here's our list: ", list)
|
|
|
|
```
|
|
|
|
|
|
|
|
### Safety
|
|
|
|
|
|
|
|
#### Type System
|
|
|
|
|
|
|
|
All variables have a type that is established when the variable is declared. This usually does not
|
|
|
|
require that the type be explicitly stated, Dust can infer the type from the value. Types are also
|
|
|
|
associated with the arms of `if/else` statements and the return values of functions, which prevents
|
|
|
|
different runtime scenarios from producing different types of values.
|
|
|
|
|
|
|
|
#### Null-Free
|
|
|
|
|
|
|
|
There is no `null` or `undefined` value in Dust. All values and variables must be initialized to one
|
|
|
|
of the supported value types. This eliminates a whole class of bugs that permeate many other
|
|
|
|
languages. "I call it my billion-dollar mistake. It was the invention of the null reference in
|
|
|
|
1965." - Tony Hoare
|
|
|
|
|
|
|
|
Dust *does* have a `none` type, which should not be confused for being `null`-like. Like the `()` or
|
|
|
|
"unit" type in Rust, `none` exists as a type but not as a value. It indicates the lack of a value
|
|
|
|
from a function, expression or statement. A variable cannot be assigned to `none`.
|
|
|
|
|
|
|
|
#### Memory Safety
|
|
|
|
|
|
|
|
<!-- TODO: Introduce Dust's approach to memory management and garbage collection. -->
|
|
|
|
|
|
|
|
### Values, Variables and Types
|
|
|
|
|
|
|
|
Dust supports the following basic values:
|
|
|
|
|
|
|
|
- Boolean: `true` or `false`
|
|
|
|
- Byte: An unsigned 8-bit integer
|
|
|
|
- Character: A Unicode scalar value
|
|
|
|
- Float: A 64-bit floating-point number
|
|
|
|
- Function: An executable chunk of code
|
|
|
|
- Integer: A signed 64-bit integer
|
|
|
|
- String: A UTF-8 encoded string
|
|
|
|
|
|
|
|
Dust's "basic" values are conceptually similar because they are singular as opposed to composite.
|
|
|
|
Most of these values are stored on the stack but some are heap-allocated. A Dust string is a
|
|
|
|
sequence of bytes that are encoded in UTF-8. Even though it could be seen as a composite of byte
|
|
|
|
values, strings are considered "basic" because they are parsed directly from tokens and behave as
|
|
|
|
singular values. Shorter strings are stored on the stack while longer strings are heap-allocated.
|
|
|
|
Dust offers built-in native functions that can manipulate strings by accessing their bytes or
|
|
|
|
reading them as a sequence of characters.
|
|
|
|
|
|
|
|
<!-- TODO: Describe Dust's composite values -->
|
2024-12-10 13:04:47 +00:00
|
|
|
|
2024-11-30 00:30:08 +00:00
|
|
|
## Feature Progress
|
2024-11-30 00:13:53 +00:00
|
|
|
|
2024-12-10 13:04:47 +00:00
|
|
|
This list is a rough outline of the features that are planned to be implemented as soon as possible.
|
|
|
|
*This is not an exhaustive list of all planned features.* This list is updated and rearranged to
|
|
|
|
maintain a docket of what is being worked on, what is coming next and what can be revisited later.
|
2024-11-30 03:43:13 +00:00
|
|
|
|
2024-11-30 00:30:08 +00:00
|
|
|
- [X] Lexer
|
|
|
|
- [X] Compiler
|
|
|
|
- [X] VM
|
2024-11-30 04:58:33 +00:00
|
|
|
- [X] Disassembler (for chunk debugging)
|
2024-12-10 13:04:47 +00:00
|
|
|
- [ ] Formatter
|
|
|
|
- [ ] REPL
|
2024-11-30 00:30:08 +00:00
|
|
|
- CLI
|
|
|
|
- [X] Run source
|
2024-12-10 14:10:34 +00:00
|
|
|
- [X] Compile source to a chunk and show disassembly
|
2024-12-03 23:46:21 +00:00
|
|
|
- [X] Tokenize using the lexer and show token list
|
2024-12-10 14:10:34 +00:00
|
|
|
- [ ] Format using a built-in formatter
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] Compile to and run from intermediate formats
|
|
|
|
- [ ] JSON
|
|
|
|
- [ ] Postcard
|
2024-12-10 13:04:47 +00:00
|
|
|
- [ ] Integrated REPL
|
2024-11-30 06:27:53 +00:00
|
|
|
- Basic Values
|
2024-11-30 04:58:33 +00:00
|
|
|
- [X] No `null` or `undefined` values
|
|
|
|
- [X] Booleans
|
|
|
|
- [X] Bytes (unsigned 8-bit)
|
|
|
|
- [X] Characters (Unicode scalar value)
|
|
|
|
- [X] Floats (64-bit)
|
2024-11-30 00:30:08 +00:00
|
|
|
- [X] Functions
|
2024-11-30 06:27:53 +00:00
|
|
|
- [X] Integers (signed 64-bit)
|
2024-11-30 04:58:33 +00:00
|
|
|
- [X] Strings (UTF-8)
|
2024-12-02 02:17:22 +00:00
|
|
|
- Composite Values
|
2024-11-30 04:58:33 +00:00
|
|
|
- [X] Concrete lists
|
|
|
|
- [X] Abstract lists (optimization)
|
|
|
|
- [ ] Concrete maps
|
|
|
|
- [ ] Abstract maps (optimization)
|
2024-12-10 13:04:47 +00:00
|
|
|
- [ ] Ranges
|
2024-11-30 04:58:33 +00:00
|
|
|
- [ ] Tuples (fixed-size constant lists)
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] Structs
|
2024-11-30 04:58:33 +00:00
|
|
|
- [ ] Enums
|
2024-11-30 00:13:53 +00:00
|
|
|
- Types
|
2024-11-30 06:27:53 +00:00
|
|
|
- [X] Basic types for each kind of basic value
|
2024-11-30 04:58:33 +00:00
|
|
|
- [X] Generalized types: `num`, `any`, `none`
|
2024-12-10 15:03:11 +00:00
|
|
|
- [ ] Type conversion (safe, explicit and coercion-free)
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] `struct` types
|
|
|
|
- [ ] `enum` types
|
2024-11-30 03:43:13 +00:00
|
|
|
- [ ] Type aliases
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] Type arguments
|
2024-11-30 03:43:13 +00:00
|
|
|
- [ ] Compile-time type checking
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] Function returns
|
|
|
|
- [X] If/Else branches
|
|
|
|
- [ ] Instruction arguments
|
|
|
|
- Variables
|
|
|
|
- [X] Immutable by default
|
|
|
|
- [X] Block scope
|
|
|
|
- [X] Statically typed
|
2024-11-30 03:43:13 +00:00
|
|
|
- [X] Copy-free identifiers are stored in the chunk as string constants
|
2024-11-30 00:30:08 +00:00
|
|
|
- Functions
|
|
|
|
- [X] First-class value
|
|
|
|
- [X] Statically typed arguments and returns
|
2024-11-30 03:43:13 +00:00
|
|
|
- [X] Pure (no "closure" of local variables, arguments are the only input)
|
2024-11-30 00:30:08 +00:00
|
|
|
- [ ] Type arguments
|
2024-11-30 03:43:13 +00:00
|
|
|
- Control Flow
|
|
|
|
- [X] If/Else
|
2024-12-10 15:03:11 +00:00
|
|
|
- [ ] Match
|
2024-11-30 03:43:13 +00:00
|
|
|
- [ ] Loops
|
|
|
|
- [ ] `for`
|
|
|
|
- [ ] `loop`
|
|
|
|
- [X] `while`
|
2024-12-10 15:03:11 +00:00
|
|
|
- Native Functions
|
|
|
|
- Assertions
|
|
|
|
- [X] `assert`
|
|
|
|
- [ ] `assert_eq`
|
|
|
|
- [ ] `assert_ne`
|
|
|
|
- [ ] `panic`
|
|
|
|
- I/O
|
|
|
|
- [ ] `read`
|
|
|
|
- [X] `read_line`
|
|
|
|
- [X] `write`
|
|
|
|
- [X] `write_line`
|
|
|
|
- String Functions
|
|
|
|
- List Functions
|
|
|
|
- Map Functions
|
|
|
|
- Math Functions
|
|
|
|
- Filesystem Functions
|
|
|
|
- Network Functions
|
|
|
|
- System Functions
|
2024-11-30 00:13:53 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
## Implementation
|
2024-08-02 19:10:29 +00:00
|
|
|
|
2024-11-30 03:43:13 +00:00
|
|
|
Dust is implemented in Rust and is divided into several parts, most importantly the lexer, compiler,
|
|
|
|
and virtual machine. All of Dust's components are designed with performance in mind and the codebase
|
2024-11-30 04:58:33 +00:00
|
|
|
uses as few dependencies as possible. The code is tested by integration tests that compile source
|
|
|
|
code and check the compiled chunk, then run the source and check the output of the virtual machine.
|
|
|
|
It is important to maintain a high level of quality by writing meaningful tests and preferring to
|
|
|
|
compile and run programs in an optimal way before adding new features.
|
2024-08-02 19:10:29 +00:00
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
### Command Line Interface
|
|
|
|
|
|
|
|
Dust's command line interface and developer experience are inspired by tools like Bun and especially
|
|
|
|
Cargo, the Rust package manager that includes everything from project creation to documentation
|
|
|
|
generation to code formatting to much more. Dust's CLI has started by exposing the most imporant
|
|
|
|
features for debugging and developing the language itself. Tokenization, compiling, disassembling
|
|
|
|
and running Dust code are currently supported. The CLI will eventually support a REPL, code
|
|
|
|
formatting, linting and other features that enhance the development experience and make Dust more
|
|
|
|
fun and easy to use.
|
|
|
|
|
2024-11-30 04:58:33 +00:00
|
|
|
### Lexer and Tokens
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
The lexer emits tokens from the source code. Dust makes extensive use of Rust's zero-copy
|
|
|
|
capabilities to avoid unnecessary allocations when creating tokens. A token, depending on its type,
|
|
|
|
may contain a reference to some data from the source code. The data is only copied in the case of an
|
2024-11-30 04:58:33 +00:00
|
|
|
error. In a successfully executed program, no part of the source code is copied unless it is a
|
|
|
|
string literal or identifier.
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
### Compiler
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
The compiler creates a chunk, which contains all of the data needed by the virtual machine to run a
|
|
|
|
Dust program. It does so by emitting bytecode instructions, constants and locals while parsing the
|
|
|
|
tokens, which are generated one at a time by the lexer.
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
#### Parsing
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
Dust's compiler uses a custom Pratt parser, a kind of recursive descent parser, to translate a
|
2024-11-30 03:43:13 +00:00
|
|
|
sequence of tokens into a chunk. Each token is given a precedence and may have a prefix and/or infix
|
|
|
|
parser. The parsers are just functions that modify the compiler and its output. For example, when
|
|
|
|
the compiler encounters a boolean token, its prefix parser is the `parse_boolean` function, which
|
|
|
|
emits a `LoadBoolean` instruction. An integer token's prefix parser is `parse_integer`, which emits
|
2024-12-10 15:03:11 +00:00
|
|
|
a `LoadConstant` instruction and adds the integer to the constants list. Tokens with infix parsers
|
|
|
|
include the math operators, which emit `Add`, `Subtract`, `Multiply`, `Divide`, `Modulo` and `Power`
|
2024-11-30 03:43:13 +00:00
|
|
|
instructions.
|
|
|
|
|
|
|
|
Functions are compiled into their own chunks, which are stored in the constant list. A function's
|
2024-12-10 15:03:11 +00:00
|
|
|
arguments are stored in its locals list. Before the function is run, the VM must bind the arguments
|
|
|
|
to values by filling locals' corresponding registers. Instead of copying the arguments, the VM uses
|
|
|
|
a pointer to one of the parent's registers or constants.
|
2024-08-02 19:10:29 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
#### Optimizing
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
When generating instructions for a register-based virtual machine, there are opportunities to
|
2024-11-30 03:43:13 +00:00
|
|
|
optimize the generated code by using fewer instructions or fewer registers. While it is best to
|
2024-12-10 15:03:11 +00:00
|
|
|
output optimal code in the first place, it is not always possible. Dust's uses a single-pass
|
|
|
|
compiler and therefore applies optimizations immeadiately after the opportunity becomes available.
|
|
|
|
There is no separate optimization pass and the compiler cannot be run in a mode that disables
|
|
|
|
optimizations.
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-30 04:58:33 +00:00
|
|
|
#### Type Checking
|
|
|
|
|
|
|
|
Dust's compiler associates each emitted instruction with a type. This allows the compiler to enforce
|
|
|
|
compatibility when values are used in expressions. For example, the compiler will not allow a string
|
|
|
|
to be added to an integer, but it will allow either to be added to another of the same type. Aside
|
|
|
|
from instruction arguments, the compiler also checks the types of function arguments and the blocks
|
|
|
|
of `if`/`else` statements.
|
|
|
|
|
|
|
|
The compiler always checks types on the fly, so there is no need for a separate type-checking pass.
|
2024-12-10 15:03:11 +00:00
|
|
|
Type information is removed from the instructions list before the chunk is created, so the VM (which
|
|
|
|
is entirely type-agnostic) never sees it.
|
2024-11-30 04:58:33 +00:00
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
### Instructions
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-12-09 15:30:57 +00:00
|
|
|
Dust's virtual machine uses 32-bit instructions, which encode seven pieces of information:
|
2024-11-30 03:43:13 +00:00
|
|
|
|
|
|
|
Bit | Description
|
|
|
|
----- | -----------
|
2024-12-09 15:30:57 +00:00
|
|
|
0-4 | Operation code
|
2024-12-10 13:04:47 +00:00
|
|
|
5 | Flag indicating if the B field is a constant
|
|
|
|
6 | Flag indicating if the C field is a constant
|
2024-12-09 15:30:57 +00:00
|
|
|
7 | D field (boolean)
|
|
|
|
8-15 | A field (unsigned 8-bit integer)
|
|
|
|
16-23 | B field (unsigned 8-bit integer)
|
|
|
|
24-31 | C field (unsigned 8-bit integer)
|
|
|
|
|
|
|
|
#### Operations
|
|
|
|
|
2024-12-10 13:04:47 +00:00
|
|
|
The 1.0 version of Dust will have more than the current number of operations but cannot exceed 32
|
|
|
|
because of the 5 bit format.
|
2024-12-09 15:30:57 +00:00
|
|
|
|
|
|
|
##### Stack manipulation
|
|
|
|
|
|
|
|
- MOVE: Makes a register's value available in another register by using a pointer. This avoids
|
|
|
|
copying the value or invalidating the original register.
|
|
|
|
- CLOSE: Sets a range of registers to the "empty" state.
|
|
|
|
|
|
|
|
##### Value loaders
|
|
|
|
|
2024-12-10 13:04:47 +00:00
|
|
|
- LOAD_BOOLEAN: Loads a boolean to a register. Booleans known at compile-time are not stored in the
|
|
|
|
constant list. Instead, they are encoded in the instruction itself.
|
|
|
|
- LOAD_CONSTANT: Loads a constant from the constant list to a register. The VM avoids copying the
|
|
|
|
constant by using a pointer with the constant's index.
|
2024-12-09 15:30:57 +00:00
|
|
|
- LOAD_LIST: Creates a list abstraction from a range of registers and loads it to a register.
|
|
|
|
- LOAD_MAP: Creates a map abstraction from a range of registers and loads it to a register.
|
|
|
|
- LOAD_SELF: Creates an abstraction that represents the current function and loads it to a register.
|
|
|
|
|
|
|
|
##### Variable operations
|
|
|
|
|
|
|
|
- GET_LOCAL: Loads a variable's value to a register by using a pointer to point to the variable's
|
|
|
|
canonical register (i.e. the register whose index is stored in the locals list).
|
|
|
|
- SET_LOCAL: Changes a variable's register to a pointer to another register, effectively changing
|
|
|
|
the variable's value.
|
|
|
|
|
|
|
|
##### Arithmetic
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
Arithmetic instructions use the A, B and C fields. The A field is the destination register, the B
|
2024-12-09 15:30:57 +00:00
|
|
|
and C fields are the arguments, and the flags indicate whether the arguments are constants.
|
|
|
|
|
|
|
|
- ADD: Adds two values and stores the result in a register. Unlike the other arithmetic operations,
|
2024-12-10 15:03:11 +00:00
|
|
|
the ADD instruction can also be used to concatenate strings and/or characters. Characters are the
|
|
|
|
only type of value that can perform a kind of implicit conversion. Although the character itself
|
|
|
|
is not converted, its underlying bytes are concatenated to the string.
|
2024-12-09 15:30:57 +00:00
|
|
|
- SUBTRACT: Subtracts one argument from another and stores the result in a register.
|
2024-12-10 15:03:11 +00:00
|
|
|
- MULTIPLY: Multiplies one argument by another and stores the result in a register.
|
2024-12-09 15:30:57 +00:00
|
|
|
- DIVIDE: Divides one value by another and stores the result in a register.
|
|
|
|
- MODULO: Calculates the division remainder of two values and stores the result in a register.
|
|
|
|
- POWER: Raises one value to the power of another and stores the result in a register.
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
##### Logic and Control Flow
|
2024-12-09 15:30:57 +00:00
|
|
|
|
|
|
|
Logic instructions work differently from arithmetic and comparison instructions, but they are still
|
2024-12-10 15:03:11 +00:00
|
|
|
essentially binary operations with a left and a right argument. These areguments, however, are other
|
|
|
|
instructions. This is reminiscent of a stack-based virtual machine in which the arguments are found
|
|
|
|
in the stack rather than having their location encoded in the instruction. The logic instructions
|
|
|
|
perform a check on the left-hand argument and, based on the result, either skip the right-hand
|
|
|
|
argument or allow it to be executed. A `TEST` is always followed by a `JUMP`. If the left argument
|
|
|
|
passes the test (a boolean equality check), the `JUMP` instruction is skipped and the right argument
|
|
|
|
is executed. If the left argument fails the test, the `JUMP` is not skipped and it jumps past the
|
|
|
|
right argument.
|
2024-12-09 15:30:57 +00:00
|
|
|
|
|
|
|
- TEST
|
|
|
|
- TEST_SET
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
<!-- TODO: Discuss control flow using TEST -->
|
|
|
|
|
2024-12-09 15:30:57 +00:00
|
|
|
##### Comparison
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
<!-- TODO -->
|
|
|
|
|
2024-12-09 15:30:57 +00:00
|
|
|
- EQUAL
|
|
|
|
- LESS
|
|
|
|
- LESS_EQUAL
|
|
|
|
|
|
|
|
##### Unary operations
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
<!-- TODO -->
|
|
|
|
|
2024-12-09 15:30:57 +00:00
|
|
|
- NEGATE
|
|
|
|
- NOT
|
|
|
|
|
|
|
|
##### Execution
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
<!-- TODO -->
|
|
|
|
|
2024-12-09 15:30:57 +00:00
|
|
|
- CALL
|
|
|
|
- CALL_NATIVE
|
|
|
|
- JUMP
|
|
|
|
- RETURN
|
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
### Virtual Machine
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-30 04:58:33 +00:00
|
|
|
The virtual machine is simple and efficient. It uses a stack of registers, which can hold values or
|
2024-12-10 13:04:47 +00:00
|
|
|
pointers. Pointers can point to values in the constant list or the stack itself.
|
2024-11-30 04:58:33 +00:00
|
|
|
|
|
|
|
While the compiler has multiple responsibilities that warrant more complexity, the VM is simple
|
|
|
|
enough to use a very straightforward design. The VM's `run` function uses a simple `while` loop with
|
|
|
|
a `match` statement to execute instructions. When it reaches a `Return` instruction, it breaks the
|
|
|
|
loop and optionally returns a value.
|
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
## Previous Implementations
|
2024-08-14 02:25:33 +00:00
|
|
|
|
2024-11-30 04:58:33 +00:00
|
|
|
Dust has gone through several iterations, each with its own design choices. It was originally
|
|
|
|
implemented with a syntax tree generated by an external parser, then a parser generator, and finally
|
|
|
|
a custom parser. Eventually the language was rewritten to use bytecode instructions and a virtual
|
|
|
|
machine. The current implementation is by far the most performant and the general design is unlikely
|
|
|
|
to change.
|
2024-11-30 03:43:13 +00:00
|
|
|
|
|
|
|
Dust previously had a more complex type system with type arguments (or "generics") and a simple
|
|
|
|
model for asynchronous execution of statements. Both of these features were removed to simplify the
|
|
|
|
language when it was rewritten to use bytecode instructions. Both features are planned to be
|
|
|
|
reintroduced in the future.
|
|
|
|
|
2024-11-07 00:18:38 +00:00
|
|
|
## Inspiration
|
2024-03-20 09:31:14 +00:00
|
|
|
|
2024-12-03 23:38:47 +00:00
|
|
|
[Crafting Interpreters] by Bob Nystrom was a great resource for writing the compiler, especially the
|
2024-12-10 13:04:47 +00:00
|
|
|
Pratt parser. The book is a great introduction to writing interpreters. Had it been discovered
|
|
|
|
sooner, some early implementations of Dust would have been both simpler in design and more ambitious
|
|
|
|
in scope.
|
2024-11-30 03:43:13 +00:00
|
|
|
|
|
|
|
[The Implementation of Lua 5.0] by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar
|
2024-12-03 23:38:47 +00:00
|
|
|
Celes was a great resource for understanding register-based virtual machines and their instructions.
|
2024-12-10 13:04:47 +00:00
|
|
|
This paper was recommended by Bob Nystrom in [Crafting Interpreters].
|
|
|
|
|
|
|
|
[A No-Frills Introduction to Lua 5.1 VM Instructions] by Kein-Hong Man has a wealth of detailed
|
|
|
|
information on how Lua uses terse instructions to create dense chunks that execute quickly. This was
|
|
|
|
essential in the design of Dust's instructions. Dust uses compile-time optimizations that are based
|
|
|
|
on Lua optimizations covered in this paper.
|
|
|
|
|
|
|
|
[A Performance Survey on Stack-based and Register-based Virtual Machines] by Ruijie Fang and Siqi
|
|
|
|
Liup was helpful for a quick yet efficient primer on getting stack-based and register-based virtual
|
|
|
|
machines up and running. The included code examples show how to implement both types of VMs in C.
|
|
|
|
The performance comparison between the two types of VMs is worth reading for anyone who is trying to
|
2024-12-10 15:03:11 +00:00
|
|
|
choose between the two[^1]. Some of the benchmarks described in the paper inspired similar benchmarks
|
2024-12-10 13:04:47 +00:00
|
|
|
used in this project to compare Dust to other languages.
|
2024-11-30 03:43:13 +00:00
|
|
|
|
2024-12-10 14:10:34 +00:00
|
|
|
## License
|
|
|
|
|
|
|
|
Dust is licensed under the GNU General Public License v3.0. See the `LICENSE` file for details.
|
|
|
|
|
2024-12-10 15:03:11 +00:00
|
|
|
## References
|
|
|
|
|
|
|
|
[^1]: [Crafting Interpreters](https://craftinginterpreters.com/)
|
|
|
|
[^2]: [The Implementation of Lua 5.0](https://www.lua.org/doc/jucs05.pdf)
|
|
|
|
[^3]: [A No-Frills Introduction to Lua 5.1 VM Instructions](https://www.mcours.net/cours/pdf/hasclic3/hasssclic818.pdf)
|
|
|
|
[^4]: [A Performance Survey on Stack-based and Register-based Virtual Machines](https://arxiv.org/abs/1611.00467)
|
|
|
|
[^5]: [List of C-family programming languages](https://en.wikipedia.org/wiki/List_of_C-family_programming_languages)
|