3 ms·

I have not worked in C in a long while. Would you mark the assembly section as volatile to avoid the compiler & assembler doing anything to it? Is there any g

I have not worked in C in a long while. Would you mark the assembly section as volatile to avoid the compiler & assembler doing anything to it? Is there any guarantee that the assembler will not aggressively re-optimize assembly-within-C?

drb91 7y ago
It's generally the linker you need to worry about, but it depends on what you're doing with the assembly.
aidenn0 7y ago
Most C compilers vary from fairly to completely hands-off when it comes to inline assembly. You can also just write it in a separate assembler file and then the C compiler does not see it. That leaves just the linker, and most optimizing linkers will treat code outside of the purview of the compiler as a "black-box" otherwise you wouldn't be able to link with code that makes system-calls.
- Avamander 7y ago
  How does link time optimization affect separate assembler file?
  - comex 7y ago
    In general, in the implementations I've seen, "link-time optimization" is a bit of a misnomer. It's more like a glorified version of `gcc -combine`. The "compiler" binary stuffs its half-finished results (IR) into fake object files, and the "linker" binary calls back into the compiler (built as a library) and sends it the IR from all the fake objects, which the compiler combines and builds into one giant, real object file. That object file is sent back to the linker, which goes on to do its normal job. (LLVM ThinLTO is a bit more advanced than that in terms of scalability and incrementality, but it maintains the same "hands-off" approach from the linker's perspective.) On the other hand, if the linker sees an object file passed to it is a real object, it doesn't send it to the compiler and handles it during the normal linking phase instead. And if you build a .s file, you always get a real object file, even if you passed -flto. TL;DR: It doesn't affect it.
black-tea 7y ago
You can't trust your compiler, but it should be easy enough to inspect the output of a small routine in a hex editor to verify that it hasn't been modified.

drb91 7y ago

It's generally the linker you need to worry about, but it depends on what you're doing with the assembly.

aidenn0 7y ago

Most C compilers vary from fairly to completely hands-off when it comes to inline assembly. You can also just write it in a separate assembler file and then the C compiler does not see it. That leaves just the linker, and most optimizing linkers will treat code outside of the purview of the compiler as a "black-box" otherwise you wouldn't be able to link with code that makes system-calls.

Avamander 7y ago
How does link time optimization affect separate assembler file?
- comex 7y ago
  In general, in the implementations I've seen, "link-time optimization" is a bit of a misnomer. It's more like a glorified version of `gcc -combine`. The "compiler" binary stuffs its half-finished results (IR) into fake object files, and the "linker" binary calls back into the compiler (built as a library) and sends it the IR from all the fake objects, which the compiler combines and builds into one giant, real object file. That object file is sent back to the linker, which goes on to do its normal job. (LLVM ThinLTO is a bit more advanced than that in terms of scalability and incrementality, but it maintains the same "hands-off" approach from the linker's perspective.) On the other hand, if the linker sees an object file passed to it is a real object, it doesn't send it to the compiler and handles it during the normal linking phase instead. And if you build a .s file, you always get a real object file, even if you passed -flto. TL;DR: It doesn't affect it.

black-tea 7y ago

You can't trust your compiler, but it should be easy enough to inspect the output of a small routine in a hex editor to verify that it hasn't been modified.