3 ms·
Of course nobody wants C to backstab them with UB, but at the same time programmers want compilers to generate optimal code. That's the market pressure that for
by pornel 6y ago
Of course nobody wants C to backstab them with UB, but at the same time programmers want compilers to generate optimal code. That's the market pressure that forces optimizers to be so aggressive. If you can accept less optimized code, why aren't you using tcc?
The idea of C that "just" does a straightforward machine translation breaks down almost immediately. For example, you'd want `int` to just overflow instead of being UB. But then it turns out indexing `arr[i]` can't use 64-bit memory addressing modes, because they don't overflow like a 32-bit int does. With UB it doesn't matter, but a "straightforward C" would emit unnecessary separate 32-bit mul/shift instructions.
https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...
- MaxBarraclough 6y ago> nobody wants C to backstab them with UB, but at the same time programmers want compilers to generate optimal code The value of compiler optimization isn't the same thing as the value of having extensive undefined behaviour in a programming language. Rust and Ada perform about the same as C, but lack C's many footguns. > indexing `arr[i]` can't use 64-bit memory addressing modes What do you mean here?
- remexre 6y agoTypically, the assembly instruction that would do the read in arr[i] can do something like: x = *(y + z); where y and z are both 64-bit integers. If I had int arr[1000]; initialize(&arr); int i = read_int(); int x = arr[i]; print(x); then to get x I'd need to do something like, tmp = i * 4; tmp1 = (uint64_t)tmp; x = *(arr + tmp1); Which, since i is signed, can't just be a cheap shift, and then needs to be upcasted to a uint64_t (which is cheap, at least).