The Developer Productivity Case for C++ Translation

Why go through all this trouble to translate C++ into LIR? The "easiest" or most direct route is to manually create and inline LIR that represents the functionality we want. Consider adding two values:

if (areNumbers(left, right)) {
    // do integer add
    return sum
}
else {
    // do lots of look ups and checks
    return sum
} 

 

We could create the LIR that represents areNumbers and the x86 integer add, and have it up and running tomorrow. The problem is that it becomes a maintanence hassle. Tamarin would have a bunch of manually inlined LIR snippets that is difficult to understand and debug. The following is the simplified equivalent LIR for the code snippet above:

ld1 = load vars[4]
ld2 = load vars[8]
 
areNumbers1 = call areNumbers(ld1, ld2)
eq1 = eq areNumbers, 0
jump false slowPath
 
   // fall through to fast path
   // do integer add
   store returnValue[0], sum
 
slowPath:
   // more checks
   store returnValue[0], sum
 
ld3 = returnValue[0]
ret ld3

 

It's a lot nicer to just code the functionality in C++, where its a lot more maintainable, malleable, and easier to debug. The counter-argument is that you have to develop the translation program and maintain another piece of code. While that's true, overall, there is less work, and a lot less pain. (Debugging LIR is a painful process). Developer productivity is actually the main reason Adobe's investing in what I consider an "infrastructure" software update.