SoylentNews is people
SoylentNews
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: 5, Informative) by maxwell demon on Saturday March 08 2014, @09:52AM
Assembly language is not undocumentable. For an example of documented assembly code, see here. [literateprograms.org]
Now of course the same in C code needs less documentation (and probably would have been fairly understandable even with no documentation at all), but needing more effort is entirely different from being impossible.
Note that I'm not advocating using more assembly language (it is still unportable, prone to errors, hard to maintain, and in most case just a waste of effort), I'm only objecting to your claim that it is undocumentable. If you don't manage to document your assembly code, it's your failure, not the failure of assembly language.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by anubi on Saturday March 08 2014, @12:22PM
Personally, I only like to use assembler when bit-banging a *specific* processor in a *specific* application.
Example: I wanted an I2C interface which needs only to interface to 8574 and ADS1110 chips. I bit banged one in assembler. For a specific microprocessor - for a specific port. That's all my code will do. Extremely limited, but what it does do, it does very fast.
The code is extremely fast, but it is not portable... it only runs on that specific machine with that specific architecture.
If you elect to use assembler, please be generous with the comments. I find the only way I have ever been able to document my code is to explain what every line does in a comment.
Maxwell dug up an excellent link for an example. Maxwell is so right on his urging to document what you did, as assembly is not well known and will confuse the hell out of most people. I consider myself to be halfway formidable with assembly, mostly because while I can read and write MY code, I can have a helluva time trying to understand what someone else is doing unless they do a good documentation job.
An assembler is a nice tool to know, but its kinda like superglue. If they try to port this thing to another processor, they are apt to have to rewrite everything I did. My algorithm may be re-used, but there is a snowball's chance in hell the code will neatly drop in.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 1) by tftp on Saturday March 08 2014, @09:21PM
Perhaps I was a bit harsh claiming undocumentality of assembly code. However, the problem is that your execution environment changes as you move from one area of the code to another. You use registers, or parts of registers, for one function here, and then for another function there. There is no consistency; you can't have as story here. You can have a single bit flag in R3 bit 0 in one place; but then you optimize the code and notice that 100 lines down R3 comes loaded with something that you need, so in that place you have a similar flag in R2 bit 3. The compiler can't care less about such things; a bit is a bit. A human, however, is very likely to lose track of things. Coupled with lack of verification of the code, aside from mere syntax checks, a program in assembly is not an easy thing to work on. Small, tight loops are often OK, as they can be seen inserted into an otherwise C code (for GCC.) But a whole 'wc' in assembly is pure masochism. One could do it for a very clear, specific and justified purpose, like when coding something for a 4-bit MCU that runs a doll and costs 7.02 cents.