Compilation by Program Transformation

Goal: understand some of the concepts behind compilation by writing a high-level transformational compiler.

Compilers are faster than interpreters by several orders of magnitude.
Probably about 90% of the prodution software running is compiled
Compilation is a very complex process
Compilers these days all perform multiple passes on a program to get source code to target code.
Our goal: understand the most basic concepts behind compilation, skipping over issues needed to write a fast, efficient compiler.

Our compiler:

Compile DSR to a very limited subset of C ("pseudo-assembly")
Use a series of program transformations to express compilation
Program transformations map DSR programs to equivalent DSRprograms.
These program transformations remove high-level features one at a time:
- Closure conversion
- A-Translation
- Function hoisting
After transformations, arrive at something very close to assembly language, but still in the form of a DSR program;
Lastly, translate the primitive DSR program directly to C.

Real compilers:

Lots of technology for producing efficient code: optimization
Not so many passes on the program as out compiler
But, more passes at the lower levels for optimization
real compilers stop at some third language in the middle: three-address code.
Real languages are huge so the engineering effort is significant.

Some points about the approach we will take.

Main goal here is pedagogy: understand the gaps seperating high- and low-level languages by bridging them one by one. Each transformation bridges one gap.
Program transformations are interesting in their own right, as they give insights into the DSR language.
Due to lack of time we will give short shrift to optimization, even though much compiler code is for this purpose.
The SML/NJ ML compiler is in fact implemented as a transformational compiler, so the methodology here is not purely pedagogical.
Our focus is more on higher-order languages, not C/C++; issues there are somewhat different.
We will not try to catch run-time type errors or garbage collect unused memory.

Desired Soundness Property for program translations: programs before and after translation have the same execution behavior (in our case, termination and same numerical output, but in general the same i/o behavior).

The Transformations

The DSR transformations are now covered in the order they are applied to the source program.

Closure Conversion

Closure conversion is a transformation which gets rid of nonlocal variables in functions (x in Function y -> x * y is nonlocal: it is not the parameter and is used in the body).
In C/C++ there are no nonlocal variables: functions can't be nested so variables are either local or global.
So, closure conversion is not relevant to C/C++ compilation. Inner classes have a form of nonlocal variable and closure-conversion-like transformation.
After closure conversion the functions will look like C/C++ functions: variables are all local
Functions still could be defined anywhere in the code, so there is more work to do on them later.

Consider the example of a curried addition function.

add = Function x -> Function y -> x + y

In the body x + y, x is nonlocal and y is local.

What should add 3 return?

Function y -> x + y would be stupid because the variable x would not have a value.
Function y -> 3 + y amounts to a substitution, something a compiler can't do since compiled code should be fixed (code is not mutable).

Answer: return a closure, consisting of the function and an environment which remembers the values of the nonlocal variables for later use:

(Function y -> x + y, { x |-> 3 })

Some more structure than this is needed in order for the function to get its x value when invoked; we cover that next.

Closure conversion is a global program transformation that explicitly performs this operation in the language itself. Core ideas

Function values are not just Function .. , they are closures, i.e. tuples of the function and an environment remembering the values of nonlocal variables
When calling one of these new-style function values, explicitly pass it the nonlocals environment which is in the closure so it can use it to find values of the nonlocals!

The translation is introduced by way of example. add above translates to

add' = { fn = Function xx ->
   { fn = Function yy -> (yy.envt.x) + (yy.arg); envt = { x = xx.arg } };
      envt = {} }

Whew! This is a pretty complicated operation. Some comments.

Closures we define as tuples in the form of records
```
{ fn = Function ...; envt = {x = ...; ...}}
```
, consisting of the original function (fn field) and the nonlocals environment (envt field).
in the nonlocals environment { x = xx.arg }, x was a nonlocal variable and its value is remembered in this record under a label of the same name, x.
Functions that used to take an argument y are modified to take an argument named yy (double up the original variable name). Note we don't really have to change the name but it can help save confusion.
The new arguments yy etc are always expected to be records of the form { envt = ..; arg = ..}, passing both the environment and the original argument to the function.
Within the body of the revised function,
- yy.envt.x is the new way to access what was a nonlocal variable x in the function body (where the function had parameter previously named y);
- yy.arg is the new way to access what was the (single) argument to the function y.
Note, in { x = xx.arg }, the left x is a label and the right xx a variable.

Translation of function calls

Function call add 3 after closure conversion then must pass in the environment since the caller needs to know it.

(add'.fn)({ envt = add'.envt; arg = 3})

Translation of add 3 4 takes the result of the above, which is a function closure { fn = ...; envt = ... }, and does the same trick to apply 4 to it:

Let add3' = (add'.fn)({ envt = add'.envt; arg = 3}) In
  (add3'.fn)({ envt =  add3'.envt; arg = 4})

and the result would be 12, the same as the original result, confirming the soundness of the translation in this case.

In general,

At function call time, the remembered environment in the closure is passed to the function in the closure.
Thus, for the add' 3 closure above, add3', when it is applied later to e.g. 7, the envt will know it is 3 that is to be added to 7.

One more level of nesting

Well, its even slightly more complicated if we consider one more level of nesting of functions, for example

triadd = Function x -> Function y -> Function z -> x + y + z

--the z function needs to get the x value, and since that function is defined in the Function y, that function has to be an intermediary which passes x.

Here is the translation.

triadd' =
  { fn = Function xx ->
    { fn = Function yy -> 
      { fn = Function zz -> (zz.envt.x) + (zz.envt.x)  + (zz.arg);
        envt = { x = yy.envt.x; y = yy.arg } };
      envt = { x = xx.arg } };
    envt = {} }

Some observations about this example

The inner z function has nonlocals x and y so those need to be in its environment;
The y function doesn't directly use nonlocals, but it has nonlocal x because the function inside it, Function z, needs it. So its envt has x in it.
Function z can get x into its environment from y's environment, as yy.envt.x. This is y being middleman to get x to z. Whew!

The official translation

With that example in mind, we can write out the official closure conversion translation. We will use the notation clconv(e) to express the closure conversion function, defined inductively as follows (this code is informal, it uses concrete DSR syntax which in the case of e.g. records looks like Caml syntax).

clconv(x) = x (* variables *)
clconv(n) = n (* numbers *)
clconv(b) = b (* booleans *)
clconv(Function x -> e) = letting x, x1, ..., xn be precisely the free variables in e, the result is the DSR expression
```
      { fn = Function xx -> SUB[clconv(e)], 
        envt = { x1 = x1; ...; xn = xn } } 
```
where SUB[clconv(e)] is clconv(e) with substitutions (xx.envt.x1)/x1,...,(xx.envt.xn)/xn and (xx.arg)/x performed on it, but not substituting in Function's inside clconv(e) (stop substituting when you hit a Function).
clconv(e e') = Let f = clconv(e) In (f.fn){ envt = f.envt; arg = clconv(e')}
clconv(e op e') = clconv(e) op clconv(e') for all other operators in the language (the translation is homormorphic in all of the other operators). This is pretty clear in every case except maybe records which we will give just to be sure...
clconv( { l1 = e1; ...; ln = en } ) = { l1 = clconv(e1);...; ln = clconv(en) }

From the above example, clconv(add) = add'.

The desired soundness result is
Theorem: e computes to a value if and only if clconv(e) computes to a value. Additionally, if one returns numerical value n, the other returns the same numerical value n.

This operation results in a language that has no nonlocal variables in functions, more like the C/C++ languages. We are getting closer to machine code.

The A-translation

Machine language programs are a linear sequence of simple instructions
The A-translation rephrases expression-based programs to show linear order of operations
Translation does this by using multiple Let statements to evaluate expressions in the order indicated by the operational semantics.

The idea should be self-evident from the case of arithmetic expressions. Consider for instance

4 + (2 * (3 + 2))

Our interpreter defined a tree-notion of evaluation order on such expressions. The order in which evaluation happens on this program can be made explicitly linear by using Let to factor out the parts that are evaluated first:

Let v1 = 3 + 2 In
Let v2 = 2 * v1 In
Let v3 = 4 + v2 In
 v3

Notice how similar this is to 3-address machine code: its a linear sequence and operations are directly applied to variables
The v1 etc variables are temporaries; in machine code they generally end up being registers
These temporaries are not re-used (re-assigned to) above; its not possible in DSR but its also how real 3-address intermediate language works. In the final machine code generation are temporaries re-used ("register allocation").
This translation did not change the meaning of the program

We are in fact going to define a more simple translation, that also first assigns constants and variables to other variables:

Let v1 = 4 In
Let v2 = 2 In
Let v3 = 3 In
Let v4 = 2 In
Let v5 = v3 + v4 In
Let v6 = v2 * v5 In
Let v7 = v1 + v6 In
 v7

Some points

This simple translation very closely corresponds to the operational semantics--every node in a derivation of e |--> v is a Let in the above (Exercise: write out the operational semantics derivation and compare).
This translation has the advantage that every operation will be between variables. In the previous example above, 4+v2 may not be low-level enough for some machine languages since there may be no add immediate instruction.
Let is a primitive in DSR -- this is not strictly necessary, but if Let were defined in terms of application, the A-translation results would be harder to manipulate.
One easy optimization would avoid making fresh variables for constants.

Next consider some code with higher-order functions.

((Function x -> Function y -> y)(4))(2)

the function that 2 is being applied to first needs to be computed. We can make this explicit as well:

Let v1 = (Function x -> Function y -> y)(4) In
Let v2 = v1(2) In
 x

The A-translation given below does even more linearization on this example:

Let v1 =
  (Function x ->
     Let v1' = (Function y -> Let v1'' = y in v1'') In v1') In
Let v2 = 4 In
Let v3 = v1 v2 In
Let v4 = 2 In
Let v5 = v3 v4 In
 v5

Every other evaluation construct can be linearized in this fashion. Except If:

If (3 = x + 2) Then 3 Else 2 * x

can be turned into (approximately)

Let v1 = x + 2 In
Let v2 = (3 = v1) In
If v2 Then 3 Else Let v1 = 2 * x In v1

but the If still has a branch in it.
However we can implement this simple form of If in machine code as

v1 := x + 2
v2 := 3 = v1
BRANCH v2, L2
L1: v3 := 3
GOTO L3
L2: v4 := 4
L3:

So, this form is quite close to machine code.

We will give the A-translation the core DSR syntax.
The intermediate result of the translation is a list of tuples

[(v1,e1); ...; (vn,en)] : (ide * term) list

which is intended to represent

Let v1 = e1 In .. In Let vn = en In vn ...

but is a form easier to manipulate in Caml since lists of declarations will be appended together at translation time. In your compilers, you may or may not want to use this intermediate form, it is not much harder to write the functions to work directly on the Let representation.

The Official A-translation

We define the A-translation as a Caml function, atrans(e) : term -> term. We will always apply A-translation to the result of closure conversion, but we really don't need to be aware of that now. We now sketch the translation for the core primitives.

We assume auxiliary functions:

newid() which returns a fresh DSR variable every time called,
the function letize which converts from the list-of-tuples form to the actual Let form, and
resultId which for list [(v1,e1); ...; (vn,en)] returns result identifier vn.

let atrans e = letize (atrans0 e)

and atrans0(e) = match e with
    (Var x)  -> [(newid(),Var x)] |
    (Int n)  -> [(newid(),Int n)] |
    (Bool b) -> [(newid(),Bool b)] |
    Function(x,e) -> [(newid(),Function(x,atrans e)] |
    Appl(e,e') -> let a = atrans0 e in let a' = atrans0 e' in
                           a @ a' @ [(newid(),Appl(resultId a,resultId a')] |
    ...
   (* all other D binary operators + - = AND etc of form identical to Appl *)
    ...
    If(e1,e2,e3) -> let a1 = atrans0 e1 in
               a1 @ [(newid();If(resultId a1,atrans e2,atrans e3)] |
    ...

At the end of the A-translation, the code is all "linear" in the way it runs in the interpreter, not as a tree.
Machine code is also linearly ordered; we are getting much closer to machine code.

Theorem: The A translation is sound, i.e. e and atrans(e) both either compute to values or both diverge.

The A-Translation for the full DSR language

The extra syntax of DSR (records, reference cells) does not provide any major complication for the A-translation.

Function hoisting

So far, the compiler has performed closure conversion and A-translation in turn:

let intermedresult e = atrans(clconv(e))

Functions now have no nonlocal variables
So, we can now hoist all functions in the program body to the start of the program
This makes a C-esque program structure.
The leftover code is then made into the main function.
This transformation is done by the hoist function.

Informally, the operation is quite simple: take e.g.

4 + (Function x -> x + 1)(4)

and replace it by

Let f1 = Function x -> x + 1 In 4 + f1(4)

--in general, hoist all functions to the front of the code and give them a name via Let.
The transformation is always sound if there are no free variables in the function body, a property guaranteed by closure conversion.

We will define this process in a simple iterative (but inefficient) manner:

let hoist e =
if e = e1[(Function ea -> e')/f] for some e1 with f free in it, and e' contains no functions (i.e. Function ea -> e' is an innermost function)
then Let f = (Function ea -> e') In hoist(e1)
else e.

If functions are not hoisted out innermost-first, then there will still be some nested functions in the hoisted definitions. So, the order of hoisting is important.
You don't want to implement hoisting as sketched above -- its too inefficient. Instead, do it all in one pass through the program, accumulating a list of the functions and replacing them by variables as you go.

Resulting programs will be of the form

Let f1 = Function ea -> e1 In
       ...
    fn = Function ea -> en In
  e

Where each e1,...,en,e contain no function constants.

Theorem: e computes to a value if and only if hoist(e) computes to a value.

This Theorem is easily proved from iterative application of the following Lemma

Lemma: (e1[(Function ea -> e')/f]) ~= (Let f = (Function ea -> e') In e1)

We lastly transform the program to

Let f1 = Function x1ea -> e1 In
       ...
    fn = Function -> Function xnea -> en In
    main = Function dummy -> e In
    main(anything)

So, the program is officially nothing but a collection of functions. This brings the program closer to the form of a C program.

Final C translation

To summarize up to now, we have

let frontend e =  hoist(atrans(clconv(e)))

We have done about all the translation that is possible within the language.
Programs at this point can be viewed as a collection of functions including a distinguished main function
Each function consists of a linear sequence of atomic operations (with exception of If which is a branch).

The translation outline:

Map each function to a C function
for each function body, map each atomic tuple to a primitive C statement.

The atomic tuples we have now

Before giving the translation, we enumerate all possible right-hand sides of Let variable assignments that come out of the A-translation (in the following vi, vj, vk, f are variables). Fact: DSR programs that have passed through the first three phases should have function bodies consisting of tuple lists where each tuple is of one of the following forms only:

x for variable x
n for number n
b for boolean b
vi vj (application)
vj + vk
vj - vk
vj And vk
vj Or vk
Not vj
vj = vk
Ref vj
vj := vk
!vj
{ l1 = v1; ... ; ln = vn }
vi.l
If vi Then tuples1 Else tuples2
where tuples1 and tuples2 are the lists of variable assigments for the Then and Else bodies.

Functions and LetRecs all should have been hoisted to the top so there will be none of those in the tuples.
Observe that some of the records/selections are from the original program, and others are the ones we created ourselves by closure conversion. Who cares, they are all the same now.

All we need to do now is generate code for each of the above tuples.

Memory Layout

Before writing any compiler, you should always design the memory layout scheme for objects at run-time.

Every compiler has to have a firm convention for memory layout.
It is extremely important to carefully design the strategy beforehand.
Simple compilers use simple schemes, but for efficiency it is better to use a more complex scheme.

Lets consider briefly how memory is laid out in C.
Values can be stored in a couple different ways:

In registers.
- These must be temporary, as registers are generally local to each function/method.
- Also they are only one word in size (or a couple words, for floats) so can't directly hold arrays, etc.
On the run-time stack in the function's activation record.
- The value is then referenced as the memory location at some fixed offset from the stack pointer (which is in a register)
- Here is some C-ish code to give you the idea of how the stack pointer sp is used
```
      { register int sp; /* compiler will assign sp to a register */
        *(sp - 5) = 33;
        printf(*(sp - 5));
      }      
```
- Stack-stored entities are also temporary in that they will be junk when the function/method returns.
In fixed memory locations (globals).
In dynamically allocated (malloc'ed) memory locations (on the heap).

An important issue is whether to box or unbox various values.

Definition. A register/memory location vi's value is stored boxed if vi holds a pointer to a block of memory containing the actual value.
A variable's value is unboxed if it is directly in the register/memory location vi.

For multi-word entities, storing them unboxed means variables directly hold a pointer to the first word of the sequence of space.

Here is C's memory layout convention:

Variables may be declared either as globals, register (the register directive is a request to put in a register only), or on the call stack (all variables declared inside a function are kept on the stack).
Variables directly holding ints, floats, structs, and arrays are all unboxed
(examples: int x; float x; int arr[10]; snork x for snork a struct.)
There is no such thing as a variable directly holding a function; variables in C may only hold pointers to functions. Variables in C are all mutable, and code resides in a read-only section of memory and so its fundamentally impossible to store functions unboxed in C. It is possible to write "v = f" in C for f a previously declared function and not "v = &f", but that is because the former is really syntactic sugar for the latter. A pointer to a function is in fact a pointer to the start of the code of the function.
Boxed variables in C are declared explicitly, as pointer variables:
(examples: int *x; float *x; int *arr[10]; snork *x for snork a struct.)
All malloc'ed structures must be stored in a pointer variable because they are boxed: variables can't directly be heap entities. Variables are static and the heap is dynamic.

Here is an example of a stupid C program and the SPARC assembly output which gives some impressionistic idea of these concepts:

int glob;
main()
{
	int x;
        register int reg;
	int* mall;
	int arr[10];

	x = glob + 1;
	reg = x;
	mall = (int *) malloc(1);
	x = *mall;
	arr[2] = 4;
/*	arr = arr2; -- illegal in C -- arrays not boxed so can't do this */
}

Assembly (%o1 is a register, [%o0] means dereference, [%fp-24] means subtract 24 from frame pointer register %fpand dereference)

main:
	sethi	%hi(glob), %o1
	or	%o1, %lo(glob), %o0 /* load global address glob into %o0 */
	ld	[%o0], %o1  /* dereference */
	add	%o1, 1, %o0 /* increment */
	st	%o0, [%fp-20] /* store in [%fp-20], the memory 20 back from fp -- this is x */
                              /* note x directly contains a number, not a ptr */
	ld	[%fp-20], %l0 /* %l0 IS reg (its in a register directly) */
	mov	1, %o0
	call	malloc, 0 /* call malloc.  resulting address to %o0 */
	 nop
	st	%o0, [%fp-24] /* put newspace location in mall ([%fp-24]) */
	ld	[%fp-24], %o0 /* load mall into %o0 */
	ld	[%o0], %o1 /* this is a malloced structure -- UNBOX! */
	st	%o1, [%fp-20] /* store into x */
	mov	4, %o0
	st	%o0, [%fp-56] /* array is directly a sequence of memory on stack - no indirection needed */
.LL2:
	ret
	restore

Memory layout for our compilers

DSR is higher-level than C, there is no direct declaration of whether values will be boxed or unboxed
We will use a simple, uniform scheme in our compilers:
- Box refs and records and function values
- Keep bools and ints unboxed

Aside: Java memory layout

All object references are boxed pointers to heap locations
primitive int and bool and float types are unboxed

Observations:

refs must be boxed to be heap-allocated since they can be referred to after a function returns:
```
Let f = (Function x -> Ref 5) In !f(_) + 1
```
--if 5 were stored on the stack, after the return it could be wiped out.
All of the Let-defined entities in our tuples (the vi) can be either in registers or on the call stack:
- none of those variables are directly used outside the function due to lexical scoping;
- They don't directly contain values that should stay alive after the fucntion returns
- For efficiency, declare all of them as register Word variables:
```
register Word v1, v2, v3, v4, ... ;
```
Boxed values will almost always be larger than one word (our one exception is we box references and they, as pointers, are only one word).
But, under this simple scheme means every variable is a 1-word assignment.
This scheme is not very efficient, and real compilers optimize significantly.

All that remains is to come up with a scheme to compile each of the above atomic tuples and we are done. Records are the most difficult so we will consider them before writing out the full translation.

Compiling untyped records

Recall from when we covered records that the fields present in a record cannot be known in advance if there is no type system
Consider for example
```
      (Function x -> x.l)(If y = 0 Then {l = 3} Else {a = 4; l = 3})
      
```
--field l will be in two different positions in these records so the selection will not know where to look.
Thus we will need to use a hashtable for record lookup
In a typed language such as ML this problem is avoided: the above code is not well-typed in ML because the if-then can't be typed.
Note that the problems with records are closely related to problems with objects: Objects = records + refs.

Aside: This brings out some important properties of typing and compilation

Types are important for compilers as well as programmers!
Our compilers are going to core dump on e.g. 4 (5);
in Lisp/Smalltalk/Scheme these errors would be caught at run-time but would slow down execution;
in a typed language, the compiler would throw out the program
Thus for typed languages they will both be faster and safer.

Our Records Compilation

We must give records a heavy implementation, as hash tables (i.e., a set of key-value pairs, where the keys are label names).
In order to make the implementation simple, records are boxed so they take one word of memory (as mentioned above when we covered boxing)
A record selection operation vk.l is implemented by hashing on key "l" in the hashtable vk points to (at run-time).
This is also pretty much how Smalltalk message send is implemented, since records are similar to objects and Smalltalk is untyped.

The above is less than optimal because

Space will be needed for the hashtable;
Record field accessing will be much slower than e.g. struct access in C.
Since closures are records, this will also significantly slow down function call. A simple optimization would be to treat closure records specially since the field positions will always be fixed, and use a struct implemetation (create a different struct type for each function).

For instance,

(Function x -> x.l)(If y = 0 Then {l = 3} Else {a = 4; l = 3})

the code x.l will invoke a call of approximate form hashlookup(x,"l"). {a = 4; l = 3} will create a new hash table and add mappings of "a" to 4 and "l" to 3.

The translation

We are now ready to write the final translation to C, via functions

toCTuple mapping an atomic tuple to a C statement string,
toCTuples mapping a list of tuples to C statements,
toCFunction mapping a primitive DSR function to a string defining a C function,
toC mapping a list of prmitive DSR functions to a string of C functions.

The translation as informally written below takes a few liberties for simplicity.

Strings "..." below are sloppily written, for instance "vi = x" is sloppy shorthand for tostring(vi) ^ " = " ^ tostring(x)
The tuples Let x1 = e1 In Let ... In Let xn = en In xn of function and then/else bodies are assumed to have been converted to lists of tuples [(x1,e1),...,(xn,en)], and similarly for the list of top-level function definitions. In your compilers, it probably will be easier just to keep them in Let form, but the choice is yours.

    toCTuple(vi = x) =           "vi = x;" (* x is a DSR variable *)
    toCTuple(vi = n) =           "vi = n;"
    toCTuple(vi = b) =           "vi = b;"
    toCTuple(vi = vj + vk) =     "vi = vj + vk;"
    toCTuple(vi = vj - vk) =     "vi = vj - vk;"
    toCTuple(vi = vj And vk ) =  "vi = vj && vk;"
    toCTuple(vi = vj Or vk ) =   "vi = vj || vk;"
    toCTuple(vi = Not vj ) =     "vi = !vj;"
    toCTuple(vi = vj = vk) =     "vi = (vj == vk);"
    toCTuple(vi = (vj vk) =      "vi = *vj(vk);"
    toCTuple(vi = Ref vj) =      "vi = malloc(WORDSIZE); *vi = vj;"
    toCTuple(vi = vj := vk) =    "vi = *vj = vk;"
    toCTuple(vi = !vj) =         "vi = *vj;"
    toCTuple(vi = { l1 = v1; ... ; ln = vn }) =
             /* 1. malloc a new hashtable at vi
                2. add mappings l1 -> v1 , ... , ln -> vn  */

    toCTuple(vi = vj.l) =        "vi = hashlookup(vj,"l");"
    toCTuple(vi = If vj Then tuples1 Else tuples2) =

              "if (vj) { toCTuples(tuples1) } else { toCTuples(tuples2) };"

    toCtuples([]) = ""
    toCtuples(tuple::tuples) = toCtuple(tuple) ^ toCtuples(tuples)

    toCFunction(f = Function xx -> tuples) =
                  "Word f(Word xx) {" ^ ... declare temporaries ...
                     toCtuples(tuples) ^
                     "return(resultId tuples); };"

    toCFunctions([]) = ""
    toCFunctions(Functiontuple::Functiontuples) = toCFunction(Functiontuple) ^ toCFunctions(Functiontuples)

    toC then invokes toCFunctions on its list of functions.

Question: why is a fresh memory location malloc'ed for a Ref?? This is a subtle issue, but the code vi = &vj would definately not work for the Ref case.

This translation sketch above leaves out many details. Here is some elaboration.

For typing

We designed out memory layout so that every entity takes up one word. So, every variable is of some type that is one word in size.
Type all variables as Word's, where Word is a 1-word type (defined as e.g. typedef Word char *).
Many type casts need to be inserted; we are basically turning off the type-checking of C, but there is no "switch" that can be flicked.
So for instance vi = vj + vk will really be vi = (Word (int vj) + (int vk)) -- cast the words to ints, do the addition, and cast back to a word.
To cast to a function pointer is a tongue-twister: in C you can use (*((Word (*)()) f))(arg).

Some global issues you will need to deal with

You will need to print out the result returned by the main function (so, you probably want the DSR main function to be called something like DSRmain and then write your own main() by hand which will call DSRmain);
The C functions need to declare all the temporary variables they use. One solution is to declare in the function header a C array
```
Word v[22]
```
where 22 is the number of temporaries needed in this particular function, and use names v[0], v[1], etc for the temporaries. Note, this works well only if the newid() function is instructed to start numbering temporaries at zero again upon compiling each new function.
Every compiled program is going to have to come with a standard block of C code in the header, including the record hash implementation, main() as alluded to above, etc.

Other subtle points.

Record creation is only sketched; but there are many C hash set libraries you can reuse if you like.
The final result (resultId) of the Then and Else tuples needs to be in the same variable vi, which is also the variable where the result of the tuple is put, for the If code to be correct; your A-translation should put If tuples in this form to make this phase correct so go back and patch it.

Compilation to Assembly code

This C code is very close to assembly code. It would be conceptually easy to translate into assembly, but we skip the topic due to the large number of cases that arise in the process (saving registers, allocating space on the stack for temporaries.

Summary

let frontend e =  hoist(atrans(clconv(e)));;
let translator e = toC(frontend(e));;

We can assert the correctness of our translator. Assert: DSR program e terminates in the DSR operational semantics (or evaluator) just when the C program translator(e) terminates, provided the C program does not run out of memory. Core dump or other run-time errors are equated with nontermination. Furthermore, if DSR's eval(e) returns a number n, the compiled translator(e) will also produce numerical output n.

Optimization

Optimization can be done at all phases of the translation process. The above translation is embarrasingly inefficient. In the phases before C code is produced, optimizations consist of replacing chunks of the program with operationally equivalent chunks.

Some simple optimizations include

Implement the special closure records {fn = .., envt = .. } as a pointer to a C struct with fn and envt fields, instead of using the very slow hash method. Records which do not not have field names overlapping with other records can also be implemented in this manner (there can be two different records with the same fields, but not two different records with some fields the same and some different).
Modify the A-translation to avoid making tuples for variables and constants.
Fold together constant expressions such as 3 + 4.

More fancy optimizations require a global flow analysis be performed. Simply put, a flow analysis finds all possible uses of a particular definition, and all possible definitions corresponding to a particular use.
A definition is a record, a Function, or a number or boolean, and a use is a record field selection, function application, or numerical or boolean operator.

Garbage Collection

Our compiled code malloc's but never frees. We will eventually run out of memory. A garbage collector is needed.

Definition: In a run-time image, memory location n is garbage if it never will be read or written to again.

There are many notions of garbage detection. The most common is to be somewhat more conservative and take garbage to be memory locations which are not pointed to by any known ("root") object.

Last modified: Fri Apr 5 14:25:20 EST 2002