3 ms·

>It's always better to have a single C code for all architectures than an assembly stub for each, it reduces the chance to have different behaviours across impl

>It's always better to have a single C code for all architectures than an assembly stub for each, it reduces the chance to have different behaviours across implementations (or subtle bugs in one implementation but not the other). >Don't let the small clean assembly for this simple function fool you, writing optimized assembly on modern architectures is getting harder and harder Maybe in the general case, but this is literally a single instruction over unchecked arithmetic. You just add and then branch on overflow. Kinda hard to screw that up. It's really sad that people are so afraid of assembly these days that they can't even bother to write, say, a couple lines of assembly for their language VM's overflow-checking add instruction, and rely on hacks like this instead. Who cares if pure C is more portable if the assembly is shorter and it takes two minutes at worst to look up what the opcode for "branch on overflow" is for any other platform you want to port to? At some point, you're not playing it safe or even saving much time, you're just wasting CPU for the sake of laziness.

pm215 12y ago
The project I work on compiles for eight different target architectures. Debian supports at least fourteen. Every program in a Linux distribution which has any inline assembly code means extra work that has to be done to support porting that distro to a new architecture, and code that has to be audited if an existing architecture gets a new calling convention (like x86's "x32", or ARM "hardfloat"). A portable 10-line implementation that gets reviewed and tested once is often going to be better than half a dozen 5 line architecture specific implementations.
simias 12y ago
You'll probably still have to write the C version anyway, as a fallback if you build on a new architecture and as a reference implementation to test the asm. So at that point it's probably valuable to see if you can't get the compiler to generate the correct code by itself in a portable way. I'm not afraid of writing assembly when I have to but I always consider it a last resort scenario when I really can't get the same result with some good old C.

pm215 12y ago

The project I work on compiles for eight different target architectures. Debian supports at least fourteen. Every program in a Linux distribution which has any inline assembly code means extra work that has to be done to support porting that distro to a new architecture, and code that has to be audited if an existing architecture gets a new calling convention (like x86's "x32", or ARM "hardfloat"). A portable 10-line implementation that gets reviewed and tested once is often going to be better than half a dozen 5 line architecture specific implementations.

simias 12y ago

You'll probably still have to write the C version anyway, as a fallback if you build on a new architecture and as a reference implementation to test the asm. So at that point it's probably valuable to see if you can't get the compiler to generate the correct code by itself in a portable way. I'm not afraid of writing assembly when I have to but I always consider it a last resort scenario when I really can't get the same result with some good old C.