Rosette translation problems on the example of translating OpXmit

Timm, Nov 13, 2017

At the beginning of sprint four I picked up OpApplyPrimArg because I wanted to figure out the details on how primitives work in Rosette. I realized that looking at the code was not enough and spent some time to a) get Rosette running with gdb and b) figure out how to get information out of Rosette objects in gdb. After that I realized that in order to achieve my goal, translating and understanding OpXmit instead of OpApplyPrimArg was the better thing to do.

With our class-based translation approach we often translate a method by leaving methods called by that method as stubs. Besides a lack of detail knowledge (partly resulting from looking at classes and methods in isolation) another reason why we do this is that we want to keep PRs small. Breaking things down into smaller tickets also encourages leaving called methods as stubs.

While this works for some methods, it doesn't work well for methods with a big call stack (this is the case with OpXmit). The reason is that we do a translation from a code base which has a lot of global variables to something functional where all necessary state is passed along (we don't want any global state). In order to decide what state is needed by a method, we have to know what state is needed by all methods called by the method in question.

Unfortunately for cases like this I don't see a good way around the problem of going deep and ending up with a big PR.