More examples of non-trivial mapping from C code to generated code: https://godbolt.org/z/jab6vh6dM
More examples of non-trivial mapping from C code to generated code: https://godbolt.org/z/jab6vh6dM
For contrast, here's the assembly generated for Haskell for integer addition: https://godbolt.org/z/vdeMKMETT
And here's assembly for C++: https://godbolt.org/z/dedcof9x5
It is very straightforward indeed, but it is still not mapping primitive operations to direct machine code, but it is forwarding to out-of-line code. Same as operator overloading in other languages.
> And here's assembly for C++: https://godbolt.org/z/dedcof9x5
That's just a symptom of allowing the compiler to inline the add code, otherwise the generated code is as straightforward:
addOne(Int):
push rax
mov esi,0x1
call 4010c0 <add_safe(int, int)>
Ref: https://godbolt.org/z/xo1es9TcW > It is very straightforward indeed, but it is still not mapping primitive
> operations to direct machine code, but it is forwarding to out-of-line code.
> Same as operator overloading in other languages.
I am not claiming that C is a collection of assembler macros. There is no expectation that a C compiler emit machine code that has exact 1:1 correspondence with the input source code. > Same as operator overloading in other languages.
The lack of operator overloading, and other hidden complex control flow, is the reason that someone can read C code and have a pretty good idea of what it compiles to. > That's just a symptom of allowing the compiler to inline the add code,
> otherwise the generated code is as straightforward:
No, that's just moving the instructions around. You've still got dynamic allocation and stack-unwinding being generated for a line that doesn't have any sign of entering a complex control flow graph.Until someone calls longjmp() or a signal() is triggered. Extra bonus of fun if it happens to be multithreaded application, or in the middle of a non-rentrant call.