4 ms·

C as a portable assembly: porting RAEdit to 64-bit

41 points by akavel 12y ago

pjmlp 12y ago
C is a a portable macro assembler, that's all.
- Sanddancer 12y ago
  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.
  - pjmlp 12y ago
    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: ...".
  - farva 12y ago
    Forth might be a better fit for this kind of thing.
blt 12y ago
Whoa, never seen any MASM code before. What an interesting hybrid!
- pjmlp 12y ago
  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.
jheriko 12y ago
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?
yoklov 12y ago
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.
- Aldo_MX 12y ago
  GCC displayed more than 1,000 warnings, most of which complain about incompatibility of types. I was actually surprised that it was able to compile. Probably it did.
- tedunangst 12y ago
  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.
  - yoklov 12y ago
    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.
- breadbox 12y ago
  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.
ExpiredLink 12y ago
I bet it wasn't as easy as he would have us believe.
e12e 12y ago
Makes me wonder if the C code compile to a work-a-like binary on 32bit as well? [edit: after looking at the "C" code, I guess not -- this really is asm wrapped in C (which is perfectly ok)]
inDigiNeous 12y ago
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 ?
- cylinder714 12y ago
  I'll give you a hint: what's the name of this website?

41 points by akavel 12y ago

pjmlp 12y ago

C is a a portable macro assembler, that's all.

Sanddancer 12y ago
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.
- pjmlp 12y ago
  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: ...".
- farva 12y ago
  Forth might be a better fit for this kind of thing.

blt 12y ago

Whoa, never seen any MASM code before. What an interesting hybrid!

pjmlp 12y ago
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.

jheriko 12y ago

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?

yoklov 12y ago

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.

Aldo_MX 12y ago
GCC displayed more than 1,000 warnings, most of which complain about incompatibility of types. I was actually surprised that it was able to compile. Probably it did.
tedunangst 12y ago
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.
- yoklov 12y ago
  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.
breadbox 12y ago
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.

ExpiredLink 12y ago

I bet it wasn't as easy as he would have us believe.

e12e 12y ago

Makes me wonder if the C code compile to a work-a-like binary on 32bit as well? [edit: after looking at the "C" code, I guess not -- this really is asm wrapped in C (which is perfectly ok)]

inDigiNeous 12y ago

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 ?

cylinder714 12y ago
I'll give you a hint: what's the name of this website?