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: 4, Insightful) by robp on Saturday March 08 2014, @09:17AM
I'm not fully sure I understand the question, but here are my (probably uninformed) two cents.
-Should mplayer, libavcodec, libvpx et al. be using inline assembly?
I would hope that if all of this inlined code is being used for multimedia acceleration, that someone had profiled it and found it to indeed be faster. I am optimistic and assuming that this is the case. Also, realistically many modern codecs are not going to run well on systems as old as the 586 and K5/K6 class processors. You could try replacing the inlined bits with generic C code, and you might find that it runs unbearably slow.
-Should anyone use inline assembly in userland programs?
If you want to use SIMD extensions, there are a lot of vector libraries out there that will let you avoid coding this directly. I believe this was part of how Apple handled switching from Altivec to SSE when they switched artchitectures. For other situations, you really need to profile the hell out of the C code and figure out exactly what needs optimization before jumping into assembly by hand.
-Should people understand assembly?
Absolutely. Particularly with how gnarly the x86 architecture is, with the strange GDT, IDT, LDT structures, and specific quirks like VM86 mode and such. Understanding assembly is really important for understanding backtraces and getting a better feel for whats going on under the hood..
(Personally, I'm crap at assembly, but I have written a bootloader that gets into 32-bit protected mode, and lets me run flat compiled C code. Doesn't do anything useful, but it was a great learning experience.)