4 ms·
And on the Fourth Day, God proclaimed "Thou shalt have the ability to use inline assembly in thy C/C++ code for performance-critical tasks". I can think of abs
by Breakthrough 14y ago
And on the Fourth Day, God proclaimed "Thou shalt have the ability to use inline assembly in thy C/C++ code for performance-critical tasks".
I can think of absolutely zero reason to write an entire program in x86 assembly, let alone any other kind of assembly (GCC spits out some pretty optimized code for my little Atmel MCU)... It's a lot nicer to write everything in a high-level, and then write any performance specifics in inline assembly.
The really cool thing to see is how other newer languages have adopted this scheme (e.g. PyASM for Python, or the ability to edit the instructions for interpreted languages that run in their own VM). And as always, great power comes with great responsibility ;)
- ohwp 14y ago"I can think of absolutely zero reason to write an entire program in x86 assembly," I can think of 2 reasons: study and fun.
- tedajax 14y agoFor x86 I'd say study but I don't think there's any fun to be had there. Something like MIPS32 would be pretty fun because that instruction set actually makes sense to a human.
- LockeWatts 14y agoI'm in a class using MIPS, and I don't find it fun.
- ryanmolden 14y agoOh, come on, the ModR/M byte, opcode extensions, variable length instructions, opcode prefixes, what's not to love </sarcasm>
- bitwize 14y agoFunny. x86 was designed to be understandable to humans. MIPS32 was designed to be more suitable for compilers.
- mikeash 14y ago8086, maybe, but I don't think we can say that modern x86 was "designed" for any one thing at all. Modern x86 is an excellent example of what you get when you evolve something for decades with backwards compatibility as a paramount requirement and little other consistent guidance, for all the good and bad that implies.
- wfunction 14y agoThe LOADALL instruction is certainly fun to get working though!
- tripzilch 14y agowriting 4096 byte demos and similar, back in the day, I can assure you I had fun coding x86 asm :) maybe if the Asphyxia tutorials hadn't been written for Turbo Pascal (+inline asm) and the C-compilers (back in '97) were really that good at optimizing as comments here suggest, I'd have gone a different route. but still, that's just performance. I doubt a compiler can beat a human at size optimization, cramming as much audio-visual power into as little bytes as possible--although executable-packers have come a loooong loong way since then (and impressively, afaik mostly by research and not so much Moore's law).
- drp4929 14y agoNow a days, compiler writers sees zero reason to write inline assembly. First of all, it throws a wrench in high level optimizer's analysis. Plus, compilers and processors are getting smarter day by day while inline assembly in shipping code becomes more and more untouchable everyday.
- tomjen3 14y agoYou have never written embedded code, or code to deal with low level hardware in drivers? I haven't either, but I imagine ASM would be required here.
- pornel 14y agoI've written code for GameBoy Advance which has no OS, just magic memory addresses, and didn't need any assembly. Even hblank interrupts could be implemented in C.
- snogglethorpe 14y agoA typical reason to use assembly these days is for instructions the compiler doesn't output (for instance specialized instructions which are only useful for a kernel). GCC's extended assembly at least (which clang/LLVM also support), allows one to specify constraints for asm() statements that let the compiler respect dependencies etc.