2 ms·

I'm not sure that's a counter-example -- what assembly do you think should be emitted for floating-point math on an AVR microcontroller?

gpderetta 2y ago
It means that "a += 1` is easy to understand as incrementing a numeric value by 1" is not true and instead "it can be really difficult to map between the original source and the machine code". More examples of non-trivial mapping from C code to generated code: https://godbolt.org/z/jab6vh6dM https://godbolt.org/z/jab6vh6dM
- jmillikin 2y ago
  All of those look pretty straightforward to me -- again, what assembly would you expect to be emitted in those cases? For contrast, here's the assembly generated for Haskell for integer addition: https://godbolt.org/z/vdeMKMETT https://godbolt.org/z/vdeMKMETT And here's assembly for C++: https://godbolt.org/z/dedcof9x5 https://godbolt.org/z/dedcof9x5
  - gpderetta 2y ago
    > All of those look pretty straightforward to me -- again, what assembly would you expect to be emitted in those cases? 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 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 https://godbolt.org/z/xo1es9TcW
    - jmillikin 2y ago
      > 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.
      - pjmlp 2y ago
        > ... and other hidden complex control flow,.... 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.
        gpderetta 2y ago
        Or your emulated float or atomic relies on non-local state, like a control word or a spin-lock pool.

gpderetta 2y ago

It means that "a += 1` is easy to understand as incrementing a numeric value by 1" is not true and instead "it can be really difficult to map between the original source and the machine code". More examples of non-trivial mapping from C code to generated code: https://godbolt.org/z/jab6vh6dM https://godbolt.org/z/jab6vh6dM

jmillikin 2y ago
All of those look pretty straightforward to me -- again, what assembly would you expect to be emitted in those cases? For contrast, here's the assembly generated for Haskell for integer addition: https://godbolt.org/z/vdeMKMETT https://godbolt.org/z/vdeMKMETT And here's assembly for C++: https://godbolt.org/z/dedcof9x5 https://godbolt.org/z/dedcof9x5
- gpderetta 2y ago
  > All of those look pretty straightforward to me -- again, what assembly would you expect to be emitted in those cases? 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 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 https://godbolt.org/z/xo1es9TcW
  - jmillikin 2y ago
    > 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.
    - pjmlp 2y ago
      > ... and other hidden complex control flow,.... 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.
      - gpderetta 2y ago
        Or your emulated float or atomic relies on non-local state, like a control word or a spin-lock pool.