4 ms·
> This is why, when I write assembly, I separate out entire functions, use an external assembler and link them into the final executable. You still have to worr
by exDM69 13y ago
> This is why, when I write assembly, I separate out entire functions, use an external assembler and link them into the final executable. You still have to worry about calling conventions, but in general your code is much easier to maintain than inline assembly.
This will only yield performance benefits if the functions you write in assembly are large enough to actually create a performance benefit. Having a non-inlineable function call to a few instructions of assembly may yield worse performance than having a few lines of C code that may be optimized. This is especially true if you write 32 bit code where the ABI needs you to put parameters into stack.
> Also, at least for the x86 and gcc, the inline assembly syntax is horrific, and I can't see how anyone can write software in it and still keep their sanity. You really want to use Intel syntax.
This is just a matter of getting used to. It's just an assembler syntax, get over it.
You're going to have to learn to read AT&T syntax assembler anyway when looking at disassembly in the debugger or inspecting object files with binutils.
I, too, learned assembly programming with the Intel syntax and I still kinda prefer it, but for the occasional few instructions of ASM code I need here and there, it's just easier to use inline asm.
- pcwalton 13y ago> You're going to have to learn to read AT&T syntax assembler anyway when looking at disassembly in the debugger Not anymore. I use `set disassembly-flavor intel` in my .gdbinit. Modern LLVM binutils clones also allow disassembly into Intel syntax with `-x86-asm-syntax=intel`. Modern versions of GAS can also use the `.intel_syntax` directive, which carries over into GCC inline assembly.