Hacker News Reader

Comment by Breakthrough | Hacker News Reader

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 ;)

View on HN

"I can think of absolutely zero reason to write an entire program in x86 assembly,"

I can think of 2 reasons: study and fun.

For 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.

Funny. x86 was designed to be understandable to humans. MIPS32 was designed to be more suitable for compilers.

8086, 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.

Oh, come on, the ModR/M byte, opcode extensions, variable length instructions, opcode prefixes, what's not to love </sarcasm>

writing 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).

The LOADALL instruction is certainly fun to get working though!

I'm in a class using MIPS, and I don't find it fun.

Now 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.

You 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.

I'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.

A 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.

Reply on news.ycombinator.com