undefined | Better HN

0 pointsjcranmer1y ago0 comments

> The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language.

The usual outcome of this assumption is that a user complains to the compiler that it doesn't produce the expected assembly code, which the compiler ignores because they never guaranteed any particular assembly output.

This is especially true for the kinds of implicit assembly guarantees people want when working with exotic hardware. Compilers will happily merge loads and stores into larger load/stores, for example, so if you need to issue two adjacent byte loads as two byte loads and not one 16-bit load, then you should use inline assembly and not C code.

0 comments

dartos1y ago

I’m not saying every C compiler is always perfectly predictable, but by virtue of it being a simpler language it should Always be more predictable than rust, barring arcane optimizations.

I do agree that if someone actually cares about the assembly they should be writing it by hand.

Ygg21y ago

> I’m not saying every C compiler is always perfectly predictable

No C compiler is predictable. First, there is the compiler magic of optimization.

Then you have Undefined Behavior, which in C, that's almost a guarantee, you'll experience inconsistent behavior between compilers, targets, optimization levels and the phases of the moon.

In Rust, use .iter a lot to avoid bound checks, or if you want auto-vectorization use a lot of fixed length arrays, and look how LLVM auto-vectorizes it. It takes getting used to it, but hey, so does literally every language if you care about SOURCE -> ASSEMBLY translation.

j / k navigate · click thread line to collapse