The Developer Productivity Case for C++ Translation
Tuesday, November 3, 2009 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.
Reader Comments (6)
Mason - will it be possible for third party LIR libs (developed in c++) to be delivered to Firefox/Flash dynamically - where there can be called from js/actionscript. That would be useful for code that requires performance.
that would violate the Flash Player's security.
Hello,
It would be possible to develop LIR libs although I don't think you would want to do that. A better approach would be to make ActionScript execute faster in the VM, which is what we're trying to do. IMHO, you want to get away from C/C++ if possible and into something memory managed, type safe, etc.
And I agree with Siva. Not only does it violate Flash's security, it seems like you'd be leaving yourself open to a ton of security holes (ActiveX).
Mason
Google seem to be doing something with Native Client - where x86 (conforming to certain restrictions) can be downloaded and run.
LIR - presumably higher level than x86 - could be 'verified' as safe. Maybe just once on installation.
Though i take your point re security. ActiveX.
doing that could also cause other kinds of troubles. For platforms like brew(coop system), where flash runs, all processes needs to yield to the OS regularly. If you allow native code to run indefinitely, device reboots :(.
to get the tamarin running on brew, we had to insert LIR at regular intervals to call our yielding function