Manually, sure, but it sounds like the idea is/was to use an automated approach. I imagine many of the same techniques used by modern decompilers could be applied, and there's probably lots of information in assembly that is lost in machine code (e.g., JE vs JZ on x86). One could also assume some knowledge of the coding conventions used by the organization. Even a tool that could translate 90% automatically, leaving the rest to be done manually, would work out pretty well.

In some ways it reminds me of the project to programatically translate the golang compiler from C to Go. Though I imagine the codebase is quite a bit messier!

Did you manually convert the assembler, or automate it ? With regard to manual conversions, I'm with you 100% - no thanks. :-)

But, my understanding is that the bulk of the work done in this case was done by a conversion tool that was designed and developed by a group of 8 people led by the gentleman referred to in the article (Jian Wang). The conversion tool project was the work that I was referring to in my comment.

Yes, manually. I missed that distinction, building the tool could be fun, but verifying it works would be a huge pain. Shouldn't be too hard to write test cases for tax code.

> Shouldn't be too hard to write test cases for tax code.

I would disagree here -- like timezones, tax software has the disadvantage of being both extremely boring, and very fiddly (thus requiring close attention). This combination makes it very hard to maintain the concentration that's required to write exhaustive tests.

Different strokes. Although, given a long enough period of working through assembly it might break the strongest of wills. I can imagine some people being very excited at setting up tests to ensure compatibility and watching them slowly going from fail to pass.