4 ms·
> (b) you kill your portability by writing inline assembly. If you expect your code to run on Windows (and gamedevs expect their code to run on Windows, though
by jwr 13y ago
> (b) you kill your portability by writing inline assembly. If you expect your code to run on Windows (and gamedevs expect their code to run on Windows, though this may be changing) you'll need to maintain two parallel, #ifdef'd hand written bits of assembly that do exactly the same thing: one for GCC, and one for MSVC. It's a Royal Pain.
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.
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.
The disadvantage of writing externally-linked assembly code is that in general, x86 assemblers are crap. You don't even get register allocation, so when I program, I have those pieces of paper around with register allocation tables (1970s-style).
- sillysaurus3 13y agowhen I program, I have those pieces of paper around with register allocation tables (1970s-style). Would you please make a video or tutorial demonstrating you doing this? Because that's awesome.
- jwr 13y agoHmm, I'm not quite sure if you're ironic or not? Because it sure feels backwards to be doing that. And the guys next door who program Texas Instruments DSPs roll on the floor laughing -- they write linear assembly for their VLIW chips and the assembler composes the VLIW instructions, takes care of register allocations, and even reorders branch instructions as needed. I feel like using a chisel next to guys with jackhammers.
- erichocean 13y agoNot ironic, I'd love to see it too. I like knowing how things were done originally. :)
- 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.
- caf 13y agoI cut my teeth on Intel style (using tasm), but these days I've come to prefer AT&T. The DWORD PTR thing just feels a lot less elegant than movl.