

C as a portable assembly: porting RAEdit to 64-bit - akavel
http://rammichael.com/c-as-a-portable-assembly-porting-raedit-to-64-bit

======
yoklov
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.

~~~
tedunangst
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
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.

------
inDigiNeous
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
I'll give you a hint: what's the name of this website?

------
e12e
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)]

------
jheriko
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?

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

~~~
pjmlp
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.

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

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

~~~
Sanddancer
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
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: ...".

