Dev.SN ♥ developers
Sections
Dev.SN
Subsentient writes:
"I'm a C programmer and Linux enthusiast. For some time, I've had it on my agenda to build the new version of my i586/Pentium 1 compatible distro, since I have a lot of machines that aren't i686 that are still pretty useful.
Let me tell you, since I started working on this, I've been in hell these last few days! The Pentium Pro was the first chip to support CMOV (Conditional move), and although that was many years ago, lots of chips were still manufactured that didn't support this (or had it broken), including many semi-modern VIA chips, and the old AMD K6.
Just about every package that has to deal with multimedia has lots of inline assembler, and most of it contains CMOV. Most packages let you disable it, either with a switch like ./configure --disable-asm or by tricking it into thinking your chip doesn't support it, but some of them (like MPlayer, libvpx/vp9) do NOT. This means, that although my machines are otherwise full blown, good, honest x86-32 chips, I cannot use that software at all, because it always builds in bad instructions, thanks to these huge amounts of inline assembly!
Of course, then there's the fact that these packages, that could otherwise possibly build and work on all types of chips, are now limited to what's usually the ARM/PPC/x86 triumvirate (sorry, no SPARC Linux!), and the small issue that inline assembly is not actually supported by the C standard.
Is assembly worth it for the handicaps and trouble that it brings? Personally I am a language lawyer/standard Nazi, so inline ASM doesn't sit well with me for additional reasons."
(Score: 2, Interesting) by AnythingGoes on Saturday March 08 2014, @10:24AM
I think you will find that most OS nowadays only have a very small assembly language layer that is used for the initial setup. Everything else is then written in C or higher languages. That also helps in making the OS multi-platform (Linux, BSDs, OS X, Windows, etc)
For JIT compilers and compilers in general, yes, there is a need to understand assembly language, but the failure of the Itanium should be a large indication that relying on the compiler to perform "magic" is not feasible. Even Intel's best programmers and hardware designers with access to the underlying hardware characteristics could not create an Itanium compiler that could make the assembly perform much faster than most x86 systems. IOW, a very good understanding of the underlying assembly language does not really help in squeezing out the last iota of speed (due to the vagaries of out-of-order-execution, pipeline stalls and cache hits/flushes).
Regarding hacking, yes, it is still an important part of the hacker's arsenal, but really how many people need to do that? when was the last time most non-kernel programmers had to debug into the kernel?
The only other case where assembly is really useful is for the programmer to understand what is happening under the hood of what they write. Getting programmers to think of the consequences of what they write is useful, because it does help in debugging/performance analysis. As almost every language compiler is way better at performance optimization than humans, the gains from actually replacing code segments with assembly tends to be great only in corner cases, and sometimes only for 1 specific version of a CPU, which is then not needed for the next version as there would be a better instruction to sue (x86 assembly usually), most other platforms do not have this problem, as they have a very reduced instruction set as compared to Intel...
Practically, assembly language should be taught and every programmer should understand it, but when it comes to hand coding assembly language modules, anything more than a few lines usually ends up being not much faster than machine generated code at the risk of much more nasty bugs.
For the original poster, while CMOV does in theory perform faster, there are issues with pipeline stalls and cache flushes which can cause performance slowdowns.. just because it performs faster for one set of tests, does not mean that every other processor will perform equally as fast or get faster speedup or that every new processor from now onwards would perform faster. Hence, it is probably easier to just leave it to the compiler.