Ahh the fine old days, they are long gone now. Still the memory remains and I wonder if there is any merit in still using assembly (not shader assembly, mind you) now and then and when, for what purpose?
Not supported in x64 (at least not inline assembly). Was looking at Michael Abrash’s ‘Black book of graphics’ recently wondering the same thing, is any of this relevant anymore?
Seems to be more intrinsics these days.
–I removed my vote, I refuse to take a stand :eek: My background is fortran guys trying to eek out that last 2% peformance, though, and I’ve seen the pain and maintenance nightmare that such an approach causes. I see an analogy here!!
Rather rarely, imho. Still, I’d recommend people to learn it and kinda master x86 optimizations, then study their compiler’s output (plus the LTCG).
I keep some obscure gems like stackless qsort and memory searches as inline asm in my base library; as they still have an edge against the compiler’s output.
Not supported in x64 (at least not inline assembly).
This is VC problem only (no inline asm). And im really curious as to why did they remove this possibility - you can link with assembler written obj’s perfectly fine in VC.
As to reasons of using assembly, i cant find many. I dont think these changed much - if you need to use super high performance special opcodes your compiler does not emit (like sse magic, or aes dedicated stuff, or other 8+ characters mnemonics), you may want to do that. There may be few others. I dont see average developer doing that much though.
On the other hand, its good to know how HW works, and playing around with asm can be pretty fun too.
Assembly is not used often, but occasionally it will be the easiest or the only way to code something you need your program to do.
ie. If you need to use the cpuid instruction to get the capabilities of your processor (and your compiler/OS does not provide a function to do this for you).
If you need to call a DLL that uses the ‘this’ calling convention from a compiler that does not support it, then you need to use assembly to put the object pointer into the ECX register before each call, so you can use the StdCall convention.
There are also a lot of non-standard calling conventions that use registers to pass parameters, or use classes/objects (such as PhysX).
These cant be called directly from a different language than the DLL was written in (and sometimes even from a different compiler for the same language), so you may need to write an assembly language routine to move parameters between registers and the stack, or convert objects to a different format before passing them to the DLL.
However, the biggest use of assembly language is in debugging.
When you have a difficult bug in a complex program that you just cant find, stepping through the code with an assembly language debugger will show you exactly whats going on and makes it obvious why your program is not doing what you expected it to be doing.
You can even trace into a DLL that you dont have source code for to determine what you are doing that is causing it to throw an exception. (such as calling it with the wrong calling convention)