4 ms·

I would disagree. On of my first jobs was porting assembler to C for a paging switch. The assembler was well written and well documented. The task was slow, har

by FigBug 9y ago

I would disagree. On of my first jobs was porting assembler to C for a paging switch. The assembler was well written and well documented. The task was slow, hard and painfully boring. It took months to get every function to be a perfect match.

nickspacek 9y ago
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.
TimJYoung 9y ago
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.
- FigBug 9y ago
  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.
  - theptip 9y ago
    > 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.
hannibalhorn 9y ago
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!

by FigBug 9y ago

nickspacek 9y ago

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.

TimJYoung 9y ago

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.

FigBug 9y ago
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.
- theptip 9y ago
  > 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.

hannibalhorn 9y ago

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!