What I have been up to....

Classes are almost over! Wohoo! I am almost free to work on MIL and on Callas.

On both projects I have been focusing on their interpreters. The implementation is focused on representing the operational semantics in a clear and (hopefully) clean manner, so there is no virtual machine (VM) or bytecode representation of the language. We do intend to implement that, but it will be on the next step. I am gathering documentation about VM's and interpreters.

Another thing I have been doing in our compilers is to get rid of the Visitor pattern. It is one of those things that trying to generalize makes the code worse (at least in how we are using it)! To solve the same problem I have developed a dispatching engine that takes care of what Double Dispatch did. Which reminds me, Double Dispatching is evil! Don't do it. It adds circular dependencies and makes the entangles concerns. Forget about that hack.

Finally, my interest in LLVM has raised. Unfortunately, it has no support for concurrency. This would be very handy for MIL. I was also looking at Parrot. The paper On the Architecture of the Parrot virtual machine provides a good overview on the VM's internals. Unfortunately, the site is confusing and it is difficult to find what I was looking for (the PIR specification).

Accepted in PLACES '08

I am really happy to announce that my first publication was accepted in the workshop PLACES '08! Thanks to GLOSS (a research team from LaSIGE) I will be presenting the paper in Oslo, Norway. The subject is about the formalization of the compiler from the π-calculus into MIL.

Introduction to MIL (part 1)

The final work of my graduation was the creation of a compiler for the π-calculus that generated MIL. This is a small example on what is MIL.

MIL is an assembly language that looks better (syntactically) than x86 assembly. The usual assembly operations are supported:

-- this is a comment
{-
 A multi-line
 comment
-}
r1 := 1       -- copying values to a register
r1 := r1 + r2 -- arithmetics
r1 := r2[0]   -- loading a value from a tuple
r2[0] := r1   -- storing a value into a tuple
if r1 = 0
  jump label1 -- conditional jump
jump label2   -- usual jump

Processor registers have the format r_n, where n is a non-negative integer (a natural number). Notice that, currently, the language only supports literals in offsets (load and store operations); bounds are checked at compile time.

This language is typed. There is support for simple strings and integers. Instructions are grouped in code blocks that are delimited by curly braces. Code blocks are identified by a label and a type, specifying the type of each value stored in the registers when the processor is executing it. For example, in order execute code block cb1 (to jump into it) register r₁ must hold a value of type integer:

cb1 (r1: int) {
 r1 := r1 + 1 -- we can safely add one to this register
 --- some more code
}

The code block main is, as usual, the first code block to be executed. This code is valid:

main() {
  r1 := 1
  jump cb1
}
cb1 (r1: int) {
  -- ...
}

Yet, this code block will not compile,

main() {
  r1 := "foo"
  jump cb1
}
cb1 (r1: int) {
  -- ...
}

because r₁ holds a string, when it should hold an integer.

But typed assembly languages are not new. MIL also tackles the problem of concurrency. The machine executing this language contains various processors and a single shared main memory. Now I show you how to fork (i.e., to create) a thread:

main() {
  fork t1
  fork t2
  yield 
}
t1 () {
  r1 := 10
  -- ...
}
t2 () {
  r2 := 20
  -- ...
}

The first thread executes the code block main that forks a new thread that will execute the code block t1, then it forks a new thread that will execute the code block t2, and, finally, yield the control of the processor, terminating this execution thread. As we can observe, MIL uses a cooperative threading model — there is no context switching.

Next post about MIL will feature memory allocation and locking.