flohofwoe (above) and aw1621107 (next to this post) both figured out that the magic ingredient isn't whether we code an if or add the boolean value of a comparison to the array size. The magic ingredient is whether the store is conditional or not.
Having the compiler convert a conditional store to an unconditional store can have bad consequences if you have interrupts or task switches or SMP going on, so it's not a good idea to do it -- unless you can guarantee that the thread of execution the compiler can see is indeed the only one. Yeah, yeah, volatile and barriers etc... still, not a good idea.
I played a bit with your link. It depends on the compiler. x86_64 clang trunk indeed compiles the original first and your fixed second form to the exact same code. I tried a couple of msvc and gcc versions and they did not but they all made them both branchless.
The Linux kernel had problems years ago when gcc started to do exactly that in certain cases (because it screwed things up with task switches, interrupts, and SMP). It fairly quickly afterwards either stopped doing it entirely or got a switch that would stop it from doing it. Don't remember which.
Of course the degree doesn't help with that. What helps is accountability. When a bridge collapses, and it turns out the engineer who drew the plans made a mistake, they can be and often are held criminally liable.
When's the last time you saw a software engineer prosecuted for criminal negligence after a design error took down Cloudflare or whatever? Attitudes in software development will not change until that becomes a viable scenario that people anticipate when making design and implementation decisions.
Windows NT was developed on various different CPUs before the Alpha was a thing. When it was released in 1993, it was released for three CPUs: IA-32, MIPS, and Alpha.
https://github.com/planetlambert
There are links from there to the repos and some more papers + to similar websites.
reply