A memory-safe language with a simple translator to x86 that can be feasibly written without itself needing a translator/compiler.
Memory-safe: it should be impossible to:
a) create a pointer out of arbitrary data, or
b) to access heap memory after it's been freed.
Simple: do all the work in a 2-pass translator:
Pass 1: check each statement's types in isolation.
Pass 2: emit code for each statement in isolation.
=== Language summary
Program organization is going to be fairly conventional and in the spirit of C: programs will consist of a series of type, global and function declarations. More details below. Functions will consist of a list of statements, each containing a single operation. Since we try to map directly to x86 instructions, combinations of operations and operands will not be orthogonal. You won't be able to operate at once on two memory locations, for example, since no single x86 instruction can do that.
Statement operands will be tagged with where they lie. This mostly follows C: local variables are on the stack, and variables not on the stack are in the global segment. The one addition is that you can lay out (only word-size) variables on registers. This is kinda like C's `register` keyword, but not quite: if you don't place a variable on a register, you are *guaranteed* it won't be allocated a register. Programmers do register allocation in this language.
The other memorable feature of the language is two kinds of pointers: a 'ref' is a fat pointer manually allocated on the heap, and an 'address' is a far more ephemeral thing described below.
--- Ref
Refs are used to manage heap allocations. They are fat pointers that augment the address of a payload with an allocation id. On x86 a ref requires 8 bytes: 4 for the address, and 4 for the alloc id. Refs can only ever point to the start of a heap allocation. Never within a heap allocation, and *certainly* never to the stack or global segment.
How alloc ids work: Every heap allocation allocates an additional word of space for an alloc id in the payload, and stores a unique alloc id in the payload as well as the pointer returned to the caller. Reclaiming an allocation resets the payload's alloc id. As long as alloc ids are always unique, and as long as refs can never point to within a heap allocation, we can be guaranteed that a stale pointer whose payload has been reclaimed will end up with a mismatch between pointer alloc id and payload alloc id.
x <- alloc # x's alloc id and *x's alloc id will be the same, say A
y <- copy x # y also has alloc id A
free x # x's alloc id is now 0, as is *x's alloc id
..*y.. # y's alloc id is A, but *y's alloc id is 0, so we can signal an error
z <- alloc # say z reuses the same address, but now with a new alloc id A'
..*y.. # y's alloc id is A, but *y's alloc id is A', so we can signal an error
--- Address
Since our statements are really simple, many operations may take multiple statements. To stitch a more complex computation like `A[i].f = 34` across multiple statements, we need addresses.
Addresses can be used to manage any memory address. They can point inside objects, on the stack, heap or global segment. Since they are so powerful we greatly restrict their use. Addresses can only be stored in a register, never in memory on the stack or global segment. Since user-defined types will usually not fit on a register, we forbid addresses in any user-defined types. Since an address may point inside a heap allocation that can be freed, and since `free` will be a function call, addresses will not persist across function calls. Analyzing control flow to find intervening function calls can be complex, so addresses will not persist across basic block boundaries.
The key open question with this language: can we find *clear* rules of address use that *don't complicate* programs, and that keep the type system *sound*?
=== Language syntax
The type system basically follows Hindley-Milner with product and (tagged) sum types. In addition we have address and ref types. Type declarations have the following syntax:
# product type
type foo [
x : int
y : (ref int)
z : bar
]
# sum type
choice bar [
x : int
y : point
]
Functions have a header and a series of statements in the body:
fn f a : int b : int -> b : int [
...
]
Statements have the following format:
io1, io2, ... <- operation i1, i2, ...
i1, i2 operands on the right hand side are immutable. io1, io2 are in-out operands. They're written to, and may also be read.
Two example programs:
i) Factorial:
fn factorial n : int -> result/EAX : int [
result/EAX <- copy 1
{
compare n, 1
break-if <=
var tmp/EBX : int
tmp/EBX <- copy n
tmp/EBX <- subtract 1
var tmp2/EAX : int
tmp2/EAX <- call factorial, tmp/EBX
result/EAX <- multiply tmp2/EAX, n
}
return result/EAX
]
ii) Writing to a global variable:
var x : char
fn main [
call read, 0/stdin, x, 1/size
result/EAX <- call write, 1/stdout, x, 1/size
call exit, result/EAX
]
One thing to note: variables refer to addresses (not to be confused with the `address` type) just like in Assembly. We'll uniformly use '*' to indicate getting at the value in an address. This will also provide a consistent hint of the addressing mode.
=== Compilation strategy
--- User-defined statements
User-defined functions will be called with the same syntax as primitives. They'll translate to a sequence of push instructions (one per operand, both in and in-out), a call instruction, and a sequence of pop instructions, either to a black hole (in operands) or a location (in-out operands). This follows the standard Unix calling convention:
push EBP
copy ESP to EBP
push arg 1
push arg 2
...
call
pop arg n
...
pop arg 1
copy EBP to ESP
pop ESP
Implication: each function argument needs to be something push/pop can accept. It can't be an address, so arrays and structs will either have to be passed by value, necessitating copies, or allocated on the heap. We may end up allocating members of structs in separate heap allocations just so we can pass them piecemeal to helper functions. (Mu has explored this trade-off in the past.)
--- Primitive statements
Operands may be:
in code (literals)
in registers
on the stack
on the global segment
Operands are always scalar. Variables on the stack or global segment are immutable references.
- Variables on the stack are stored at addresses like *(EBP+n)
- Global variables are stored at addresses like *disp32, where disp32 is a statically known constant
Since the language will not be orthogonal, compilation proceeds by pattern matching over a statement along with knowledge about the types of its operands, as well as where they're stored (register/stack/global). We now enumerate mappings for various categories of statements, based on the type and location of their operands.
Many statements will end up encoding to the exact same x86 instructions. But the types differ, and they get type-checked differently along the way.
A. x : int <- add y
Requires y to be scalar (32 bits). Result will always be an int. No pointer arithmetic.
This statement is used to translate an array index (denominated in the type of array elements) into an offset (denominated in bytes). It's just a multiply but with a new type for the result so that we can keep the type system sound.
Since index statements translate to multiplies, 'x' must be a register.
The %size(T) argument is statically known, so will always be a literal.
EDX <- copy *(EBP+8) # recompute the address in s because we can't save the value anywhere)
EDX <- add EDX, 4 # skip alloc id this time
Subtleties:
a) if the alloc id of the payload is 0, then the payload is reclaimed
b) looking up the payload's alloc id *could* cause a segfault. What to do?
=== More speculative ideas
Initialize data segment with special extensible syntax for literals. All literals except numbers and strings start with %. Global variable declarations would now look like:
var s : (array character) = "abc" # exception to the '%' convention