I’m on my way to finishing the second requirement to graduate with honors; last week I started to write my honors thesis. One of the goals I set as a freshman was to graduate with honors. I started my honors project last semester with my first guided independent study in compiler development and, as scheduled, I continued to work on the same project this spring. I’m well on my way to acquiring 6 hours of honors course credit so all I have left to do is finish my Honors thesis.

At first I thought writing my thesis would be an impossible task, especially when I got off to a very slow, unmotivated start. However, after I finished my introduction I found that writing about an enjoyable project is fun. This paper gives me a nostalgic feeling because I get to look back and review all of my progress. It’s even more exciting to know that I’ve contributed to a project that will live on well after I leave the U. of Iowa.

I updated the Blaise compiler so it has a Foreign Function Interace (FFI). Earlier this month I modified the compiler so arrays could be made in Blaise, the support I added was more like a hack where the compiler looked for predefined function names. I re-factored the compiler so now it supports a FFI where the compiler now looks for external function declarations. Every time a Blaise programmer uses and function that is declared externally the compiler trusts that the programmer is calling a supported external function.

Here is a snippet of blaise code:

# Here are the external declarations, these tell the compiler which
# functions will be used from an existing library

external Array_make [ typeInfo ] : [ typeInfo ]
external Array_get [ typeInfo ] : [ typeInfo ]

define mn =
    var arr = Array_make(5,1);
    print_int(Array_get(arr, 0))

I added support for arrays inside of Blaise. Instead of modifying the grammar I modified the compiler to look for foreign function interface constructs. Since Blaise compiles to C I have to make sure all Blaise code compiles to compliable C. Supporting arrays in Blaise wasn’t too hard, but there was one obstacle I didn’t expect to run into. Due to little experience with C I found out  that creating arrays dynamically in C isn’t as easy as I first thought.

For example, the following createArray function does not work in C:

void* createArray(int length, void* initialValueForEachElement){
    void* arr[length];
    int i;
    for(i = 0;i< length; i++){
        arr[i] = initialValueForEachElement;
    }
}

I did come up with a solution to my problem. Anytime I call the createArray function I know the length of an array specified by the Blaise programmer so I declare the array before the function call and pass it in.

void* createArray(void* arr[], int length, void* initialValueForEachElement){
    int i;
    for(i = 0;i< length; i++){
        arr[i] = initialValueForEachElement;
    }
}
int main(){
    int length = 5;
    void* arr[length]; createArray(arr, length, 3); // arr was successfully created
}

After talking to a postdoc I discovered an even better solution so I don’t have to declare the array before the call.

void **Array_make(int size) {
    void **arr = malloc(size*sizeof(void *));
    return arr;
}

Working on software with a lot of code can be a lot of fun. It can be hard to manage properly, too. Usually teams are formed to build large software projects. This is great because normally a team of developers is more productive than a single developer. However, it is crucial that all members are aware of other members’ contributions and changes to the project. I don’t want a team member to break my code, just as other team members don’t want me to break their code. It’s important for each team member to understand the effects of their code as well as the rest of their team’s code.

A couple of months ago I added tail recursion optimization to Blaise. It worked quite well for a while until a team member changed a piece of code that was completely unrelated to tail recursion and unknowing broke the tail recursion optimization. Sadly, this created more work for both of us. We have to figure out which change caused the tail recursion optimization to break and then we need to figure out how to modify the code we have. Ideally, we would have known potential side effects from changing code beforehand and we would have proactively handled them instead of finding them weeks later.