Interesting. To be honest, I'm somewhat surprised a mechanical translation of assembly to C didn't result in a lot of hard to track down bugs, considering how much of what's well-defined in assembly being undefined behavior in C.
That doesn't really follow. Most of the time, like behavior of integer overflow, the program doesn't really care (as in the machine language version doesn't reflect a specific desire for wrapping behavior, especially for signed values). The naive C version is good enough. And of course, it's always possible to even more carefully disassemble and preserve semantics, though this is usually undesirable because it obscures what's relevant.
Signed wrapping behavior is well-defined in the machine language for every architecture that ever existed (or at least, that I've ever heard of). If the assembly code depends on the wrapping behavior and you translated that to C, you'd get C code that depends on the behavior of signed overflow, which the compiler is free to completely remove, no matter your target.
This is a somewhat extreme case, as code that depends on the behavior of signed overflow is rare, but there's a lot of things that are perfectly well specified by the architecture, but that C leaves undefined.
Actually, most of C's "undefined behavior" is left undefined to permit compilers to define whatever behavior is most natural for the target's assembly. Undefined behavior is an issue when you're trying to write portable code. So it's really not surprising that this worked out in the programmer's favor in this situation.
Nope. You're describing implementation-defined behavior. The compiler is free to assume undefined behavior never happens, and optimize it away if it does. This can be a big problem, whether or not you are trying to write portable code.
Interesting to see projects still written in assembly? Real question is, why ? Is there a subculture of people who prefer Assembly Only programs, like the ultimate lightweight linux distro enthusiastics or something ?
the real challenge in portability is where the code must interact with the platform. making C command line tools that run across linux/osx/windows is quite straightforward, but anything more involved can be interesting, esp once you include iOS, Android and WinRT/Phone into the mix.
i'd be curious how reliable your port is too. automated code conversion can introduce subtle and unexpected bugs in a ton of cases... did you measure it somehow?
MASM and TASM were very powerful macro assemblers. You had enough capabilities to make Assembly look like an high level language, while enjoying full Assembly power.
This goes back to the days when the code generated by C, Pascal, Modula-2 and many other compilers were deemed too slow for home computers and real developers used Assembly.
This is exactly the attitude as to why Lisps don't, and for at least the near-term future won't, be used outside of tiny niches of computer-priesthoods. C was used because that's what the coder is most comfortable working in. Had he wanted to, he almost certainly could have used the regex to convert the code into Lisp, or Fortran, or Smalltalk, but he'd be getting rid of the advantages C has for his intended use cases, such as interoperability with a large amount of other software. If you want to stop complaining why your favorite language gets no respect, start learning from C and make it easier to dip one's toe into the language instead of complaining about a language's purity of essence.
This is the attitude from someone that was doing systems programming when C was still a UNIX only thing and had the pleasure to use better languages for such purpose.
But since those languages weren't married to UNIX, they lost.
EDIT:
Forgot to mention that actually my whole point was about the title " C as a portable assembly: ...".
