[Webassembly][wasm] is a new technology aimed at being a vendor-independent virtual machine format. It has implementations by all major browser vendors. It looks like there's staying power in webassembly that could outlast staying power in other new technologies.
So, time's perfect to snipe it with something useful that you can target compilers to today. Hence: [Land][land].
Computer programs are effectively a bunch of business logic around function calls that can affect the "real world" outside of the program. These "magic" functions are also known as [system calls][syscall]. Here's an example of a few in C style syntax:
```
int close(int file);
int open(const char *name, int flags);
int read(int file, char *ptr, int len);
int write(int file, char *ptr, int len);
```
These are all fairly low-level file I/O operations (we're not dealing with structures for now, those are for another day) that all also are (simplified forms of) system calls (TODO: link to linux system call reference).
Effectively, the system calls of a program form the "API" with it and the rest of the computer. Commonly this is called the [ABI (Applcation Binary Interface)][abi] and is usually platform-specific. With Land, we are effectively creating a platform-independent ABI that just so happens to target Webassembly.
In Land, we can wrap an [Afero][afero] filesystem, a set of files (file descriptors are addresses in this set), a webassembly virtual machine, its related webassembly module and its filename into a Process. This process will also have some functions on it to access the resources in it, aimed at being used by the webassembly guest code. In Land, we define this like such:
```
// Process is a larger level wrapper around a webassembly VM that gives it
Memory operations are implemented on top of each WebAssembly process. The two most basic ones are `writeMem` and `readMem`:
```
// writeMem writes the given data to the webassembly memory at the given pointer offset.
func (p *Process) writeMem(ptr int32, data []byte) (int, error) {
mem := p.vm.Memory()
if mem == nil {
return 0, errors.New("no memory, invalid state")
}
for i, d := range data {
mem[ptr+int32(i)] = d
}
return len(data), nil
}
// readMem reads memory at the given pointer until a null byte of ram is read.
// This is intended for reading Cstring-like structures that are terminated
// with null bytes.
func (p *Process) readMem(ptr int32) []byte {
var result []byte
mem := p.vm.Memory()[ptr:]
for _, bt := range mem {
if bt == 0 {
return result
}
result = append(result, bt)
}
return result
}
```
Every system call that deals with C-style strings uses these functions to get arguments out of the WebAssembly virtual machine's memory and to put the results back into the WebAssembly virtual machine.
Below is the [`open(2)`](open2) implementation for Land. It implements the following C-style function type:
```
int open(const char *name, int flags);
```
WebAssembly natively deals with integer and floating point types, so the first argument is the pointer to the memory in WebAssembly linear memory. The second is an integer as normal. The code handles this as such:
As you can see, the integer arguments can sufficiently represent the datatype of C: machine words. String pointers are machine words. Integers are machine words. Everything is machine words.
Write is very simple to implement. Its type gives us a bunch of advantages out of the gate:
```
int write(int file, char *ptr, int len);
```
This gives us the address of where to start in memory, and adding the length to the address gives us the end in memory:
Close lets us let go of files we don't need anymore. This will also have to have a special case to clear out the last file properly when there's only one file open:
```
func (p *Process) close(fd int32) int32 {
f := p.files[fd]
err := f.Close()
if err != nil {
panic(err)
}
if len(p.files) == 1 {
p.files = []afero.File{}
} else {
p.files = append(p.files[:fd], p.files[fd+1])
}
return 0
}
```
These calls are enough to make surprisingly nontrivial programs, considering standard input and standard output exist, but here's an example of a trivial program made with some of these calls (equivalent C-like shown too):
Right now this is very lean and mean, as such all errors instantly result in a panic which will kill the WebAssembly VM. I would like to fix this but I will need to make sure that programs don't use certain bits of memory where Land will communicate with the WebAssembly module. Other good steps are going to be setting up reserved areas of memory for things like error messages, [posix errno][errno] and other superglobals.
