Why Learning Assembly Language Is Still Good 667
nickirelan writes "Why Learning Assembly Language Is Still a Good Idea by Randall Hyde -- Randall Hyde makes his case for why learning assembly language is still relevant today. The key, says Randall, is to learn how to efficiently implement an application, and the best implementations are written by those who've mastered assembly language. Randall is the author of Write Great Code (from No Starch Press)."
Re:Because you can kill any 2.6.x kernel (Score:3, Informative)
Yep, it kills 2.6.6.
Re:Schools not teaching assembly anymore (Score:0, Informative)
As somebody who has done DSP algorithms (Score:5, Informative)
For low power/embedded applications, efficiency makes sense as well. Every CPU cycle wasted chips away at battery power. A more efficient algorithm means a smaller ROM size, and the CPU can either be clocked slower (can use cheaper memory and/or CPU) or put into a halted state when it isn't needed. (longer battery life) Coding small ISRs in assembly makes sense as well, as C compilers often must make worst case assumptions about saving processor context.
That being said, only a fool would try and re-write printf or cout in assembly, if they have a C/C++ compiler handy. Hand optimization is best used as a silver bullet, for the most computationally intensive or critical functions.
Re:I disagree (Score:2, Informative)
Depends on what you are sorting. Anyone will tell you that the quicksort algorithm works fastest when dealing with total randomness, but a properly designed bubblesort can quickly shake out a couple of minor swaps much faster than a quicksort.
Re:Which Platforms? (Score:4, Informative)
Just a couple of years ago I did a fairly large 68HC908 application for a housekeeping processor entirely in assembler.
Intel Architecture Manuals (Score:1, Informative)
Here they are. [intel.com]
Or you may prefer AMD-64, here [amd.com].
Re:how many people actually program in assembly? (Score:2, Informative)
This guy clearly doesn't work in the real world. (Score:3, Informative)
The point of using a profiler to optimize your application is that usually you're going to identify a couple key areas where you need to do some tuning because your algorithm is not efficient regardless of the architecture on which its running.
Further, within the x86 family, different CPUs have different performance characteristics. The most efficient machine code on one may be the slowest on another. So to write the most efficient programs for x86, according to this guy's definition, I would end up having to implement run time CPU checking with different code paths depending on the result.
Guess what? It isn't worth the additional development time unless the result is substantial. How do we know which improvements would be substanial? We profile the code.
This guy needs to take a leave of absence from teaching and work as a programmer for a while before he shoots off his mouth on topics where he clearly has no clue.
Re:As somebody who has done DSP algorithms (Score:2, Informative)
It's nice to have a compliant C/C++ compiler for your target device, some even have language extensions allowing you to take advantage of more specific features on the chip. However, when it comes down to speed and critical timing issues assembly can't (yet) be beat.
On some recent DSP projects we used the supplied C compiler to do simple things like control logic and other tasks, and it works wonderfully for that type of task, but the critical algorithms were all hand-tuned assembly. Often we would use the compiler output as a start and work from there, but we would invariably blow the doors off it performance-wise, but the compiler did surprise us a few times.
The biggest impact comes with tight timing restrictions. If you've only got 500 microseconds to get a sample done, or process a set of data, *and* you've got to do it a very tight memory space with minimal power consumption, you've got to rely on your assembly language skills to work it out. It's gruelling work, but we can't all just buy faster chips or more memory and use the compiler.
Re:don't bother........ (Score:2, Informative)
Considering that imbedded processors, where every single bit of performance is important, outnumber PCs by a LARGE margin it's still applicable.
Sure, most of the code for them would be done in C as well, those habits you gained out of assembly would come in handy.
assembly as a game (Score:3, Informative)
This is a bit of a digression, but I'd like to point out that not only is assembly useful to implement games, it can be a game in itself: 7th anual International Functional Programming Contest [upenn.edu], CoreWars [koth.org] (though I don't expect them to displace the market share of UT2004)
-jim
Re:don't bother........ (Score:2, Informative)
-michael
Re:Debugging (Score:3, Informative)
Or, just Google for Mel the Programmer and hit I'm feeling lucky.
Schools not teaching assembly...Really? (Score:3, Informative)
The CompE curriculum at my university was very electronics / hardware oriented, so there was quite a bit of asm to learn. Not to mention VHDL, etc, which is also quite valuable stuff to know. Nothing like building individual logic from scratch and putting it together to simulate a microprocessor. Then trying to implement it on a chip.
Re:it's a tradeoff (Score:1, Informative)
Re:Counterpoint (Score:3, Informative)
Re:This guy clearly doesn't work in the real world (Score:3, Informative)
Re:Schools not teaching assembly...Really? (Score:3, Informative)
Re:Schools not teaching assembly anymore (Score:1, Informative)
embedded code (Score:3, Informative)
Another reason why assmbler will always be useful is that many CPUs have valuable instructions that have no C equivalent. Therefore to use these instructions one typically needs to write assembler.
Frequently it is simpler to write a function that accesses hardware directly in assembler than it is to write it in C. With C the compiler will often jerk you around and optimise away specific behaviour that you want.
Re:don't bother........ (Score:4, Informative)
1) You are a programmer, and knowing how the computer functions is your job
2) Many of the high-level constructs are better understood when you know what it is they are trying to abstract. It will also keep you from doing stupid things like making everything in java a BigNum or whatever that is.
3) The idea of references and pointers are a lot more fuzzy for programmers who never learned assembly language. The difference between a pointer and a value is harder to grasp.
4) Debugging is a lot easier when you know assembly language, because you know how the parts fit together. You understand what a calling convention is, you understand how memory mapping works, you understand how the stack works - you just can see the whole picture of how the machine is processing your data.
There's even some optimizations that you can do still in higher-level languages that you get from knowing assembly language. For example, in C, the first member of a struct is accessed faster because the compiler can just do straight indirect addressing rather than base pointer addressing. It might also convince you to rewrite your loops so they have a better chance of fitting entirely into the instruction cache. But even without these things, knowing assembly language is useful for the four reasons I outlined above. It's also useful for people who are having trouble learning to code, because it forces them to think on a much more exacting, step-by-step, concrete level.
Re:This guy clearly doesn't work in the real world (Score:2, Informative)
Or how about in the embedded "real world" with 64K (that's 65,536) bytes (or less) of program code space and 512 bytes (or less) of RAM? Believe it or not, there are literally thousands of these computers for every desktop computer on earth. Where not ony time efficency but cost and power consumption (lower speed processors), code and data efficency are critical. Profilers aren't much use here.
It may also suprise you to know that some compiled programs do run time CPU type checking and use different code paths depending on the results for exactly the reasonds you give. A profiler can't always help produce code that is efficent enough on all the variations of the x86 CPU architecture. Few programs need this level of efficency, but when they do, there are few alternatives.
And, last. No compiler can produce realy good optimized code without a programmer with an intimate knowledge of the instruction set and hardware architecture of the processor the compiler is producing machine instructions for.
Maybe you need to learn more about "other" types of "real world" computer software uses before you shoot your foot off talking about subjects you clearly do not know enough about.
Re:Debugging (Score:3, Informative)
I can write two programs to do the same thing... one that takes a second one that takes a year. Both written in C of course. If optimized C takes a year and perl takes a second... there ya go... counterexample.
Of course I would have to see it to believe it.
JIT? (Score:4, Informative)
Re:don't bother........ (Score:3, Informative)
Re:desire to teach someone 6502 assembly language (Score:2, Informative)
-- HighT1mes
Re:.Net micro-benchmarking tool (Score:3, Informative)
I wrote a C# performance comparison tool [leeholmes.com] to help me in this respect. When you're trying to optimize a hot-spot in your program, you can click on the "ILDasm Result" tab to see how .Net compiles it down to its Microsoft Intermediate Language (MSIL) representation.
I've also got the book, "Inside Microsoft .Net IL Assembler" [amazon.com] that's very helpful. For whatever reason, you can get it for like $2 + shipping used from Amazon.
Re:Debugging (Score:3, Informative)
Re:Counterpoint (Score:3, Informative)
Erm... today? Seriously. Today.
See, I had this mere 4 megs of actual data stored in 48,000 records, that happened to come to me as 1500 pages of fairly clean HTML tables (originally in about 50 separate files), and I needed to convert it all to a single file in comma-delimited format.
It choked every modern program I tried to get to handle it -- and that was while it was still in much smaller chunks of half a meg or less. The only Win32 app it didn't crash outright was EditPad, and even that worthy got a bit laggy on the needful search and replace.
I wound up doing most of the conversion by hand, in ... are you ready for this?? WordPerfect 5.1 for DOS. In about 2 minutes to S&R the table structures to CSV, and 5 seconds to sort the records. And no editing lag at all.
As it happens, WP5.1 was written in ASM.
Well, you asked :)
Re:ARGH (Score:3, Informative)
I'm not saying everyone has to be a hardcore assembly programmer, but I am saying understanding assembly and the underlying architecture on which you are developing software can make a huge difference. The fact of the matter is, an optimising compiler is not a magic bullet any more than anything else is a magic bullet. The optimiser is great for doing the real low-level instruction shifting type optimizations that a lot of people think are the real optimizations.
But the optimiser can't help you with poor data structure design, poor memory access patterns, or any other of a host of high-level decisions that still have a lot to do with architecture.
It's not about hand-optimised assembly anymore, anyway - at least, not if you're working on a beefy architecture with out-of-order execution and all that. But you still need to have a general idea of what kinds of things your particular computer does well and what kinds of things it drags ass on, otherwise you can still end up writing your own little version of Halo PPC.
Re:Long article makes one point. (Score:1, Informative)
I'm posting this so that you (the moderator) have some context to consider twitter and not mod him up whenever he posts his filler preformatted rants about installing Knoppix or whatever that unfortunately get him karma every single time and allow him to continue posting his trademark toxic crap (read on) day in and day out. You may consider this a troll - I consider it community service. And I ain't kidding.
If you're a /. subscriber, I invite you to look through some of his posting history [slashdot.org]. I guarantee that you'll be hard pressed to find someone that is more "out there" than twitter. You'll also probably notice he's got quite an AC following. Don't just read his posts, make sure you go through the replies.
To get an idea of what I'm talking about, check this [slashdot.org] post out. I mean, this is an article about email disclaimers, right? The parent of the post is complaining about the ads in the linked page and so on, and twitter actually goes off on a rant to blame it on Microsoft and recommend Lynx. WTF?
Here's another. In this post [slashdot.org] twitter not only calls the OP a troll but attempts to "tell it like it is" while making some vague argument about "GNU". Yes, if you're confused, you're not alone. The reply (modded +4) proceeds to simply destroy his bogus argument. You will notice he did not reply. This is what some people call "drive-by advocacy". A sort of I'll just leave you with my thoughts here and move on to the next flamebait kind of deal. In fact, he almost never replies because he knows that his fanatical arguments simply do not hold up to any sort of discussion. It's not that he's chosen the wrong cause - he's just going at it in a completely wrong way.
More? Just read though this [slashdot.org] post and the subsequent replies. I guess this stands on its own. Or this [slashdot.org]. Or this [slashdot.org].
More? Bad spelling in astounding conspiracy theories [slashdot.org], more [slashdot.org] offtopic [slashdot.org] FUD [slashdot.org] and uninformed "I'm right, look at me" rants [slashdot.org], promptly proven wrong. Worse even, twitter wants to be RMS [slashdot.org], apparently [slashdot.org] (that first one is a winner). I mean, really [slashdot.org]. You think [slashdot.org]?
FUD [slashdot.org], FUD [slashdot.org], FU [slashdot.org]
Re:Schools not teaching assembly anymore (Score:2, Informative)
Principles learned while programming assembler& (Score:2, Informative)
- Never Copy - if not necessary (be careful with the "=" operator in C++ and other high-level Lang.)
- Aggregate Information as soon as possible
- Preserve Locality
- Save Memory always - your Computer has lots of RAM, but little Cache.
- Be careful with 2D-Arrays and similar structures and consider the cache organiziation
- Try to use Regular automata wherever appropriate instead of more complex structures.
Some more important non-algorithmic ideas?Re:Counterpoint (Score:3, Informative)
And this is why your computer still takes a minute to boot-up, despite being 8 million times faster than a 1980s computer that boots in 6 seconds.
"Think... when was the last time you thought "This word processor just doesn't respond to my keypresses fast enough."
Last time I loaded Microsoft Word. It takes about 10 seconds to start on my 2GHz machine at work.
"The reason why these programs aren't getting "faster" (as the article complains) is because there is no way to do so. They spend 99.9% of their time waiting for user input already."
So tell me why KPPP (a dial-up network program with just 3 buttons) takes 15 seconds to load in my WindowMaker desktop, or why KDE itself takes almost 25 seconds to load? Waiting for my user-input, is it?
"When that added efficiency does not lead to any noticeable benefit to the user, why do it?"
Everyone here has used fast applications and slow applications. The fast applications feel nice to use and let you get stuff done. The slow applications are annoying and frustrating and difficult to use. I'd certainly count speed (and memory footprint) as a benefit to the user.
Assembly language is on the way out. (Score:2, Informative)
Understanding how a computer works is more important than learning to write in assembly language. In fact, assembly code has simpler constructs than most high level languages. The perceived complexity of assembly language is due to the tedium of programming solutions to even simple problems.
A good start then is to learn how a computer works by reading "Code" by Charles Petzold or "Computer Organisation & Design : The Hardware and Software interface" by Hennesey and Patterson. With such an understanding you will know "when" to write in assembly instead of high level language. When you ought to write code in assembly, grab an instruction set reference manual for your architecture and/or a tutorial on how to interface C/C++ functions with assembly and you are off.
Assembly language is surely on the way out. It becomes irrelevant in distributed, cluster or grid computing. How will you optimise if your cluster is made of heterogenous processors ? A variant of the problem has already cropped up with modern processors supporiting different kinds of SIMD instructions leading to messy template switched code. Optimisation then shifts strongly towards choosing efficient algorithms rather than fidding with assembly. In any case, code generation should be the headache of the compiler where its better solved than each application trying to do it on its own.
Re:Because you can kill any 2.6.x kernel (Score:3, Informative)
Re:Because you can kill any 2.6.x kernel (Score:2, Informative)
Re:Which Platforms? (Score:3, Informative)
If I had learned assembly then as a child it would have been 6502 or Z80, as an undergrad it would have been x86 (or a small subset of x86 assembly, since it really is horrible). Now, most of the coding I do is on PowerPC, so none of them would have been any use and would have taught me misleading things (for example, register allocation is horrible on x86 and context switches are very expensive. On PowerPC most of the registers are general purpose and context switches have about the same overhead as function calls).
I doubt that learning a real assembly language is much use (unless you learn PIC assembly, or similar and then develop embedded systems), but using something like the Tiny Machine is very good experience (and since it runs on about any platform with a C compiler and a libc it eliminates hardware constraints).
Re:Problems with article (Score:2, Informative)
Which does not actually make much sense for virtual machine based languages such as Java and C#.
I agree, kinda (Score:2, Informative)
But I still think inorder to program efficant code you still must know assembly. The best courses I took were about compliers. This lets you know exactly how the compiler will optimize that assembly you know, so you know what is worth optimizing in a high level language.
For example, a lot of the things people do like rearanging local variable instanciation has absolutly nothing to do with how the machine code is actually written. The first think a compiler does is translate your code into a meta-code that has the exact same syntax style everywhere. All the variable declarations are moved to the front, every for, while, and do-while is turned into a while. All the code is normalized into a functional equivalent.
Then the code is optimized, if statements may be turned into the logical opposite, extra variables will be eliminated, code will be rearranged to increase parallel processing.
If you write code with this in mind you focus more on the important problems, like is this loop n-squared or just n.
But in-order to know what to optimize in code you still need to know assembly.
-nicnak
Re:Debugging (Score:4, Informative)
You can of course use assembly to track the bug, but I myself find that tedious. If you are programming in plain C (and not C++), you can use lint, a tool that evaluates sourcecode, very often. When lint reports no more possible problems you are done.
If you happen to use C++ you'll probably have to shell out big bucks for a linter or be out of luck because there are only commercial linters available.
Tho, that's why I always have a Linux system with valgrind [kde.org], which is amongst other things a memory debugging tool, available on it (unfortunately valgrind does not work on any of the BSDs). Valgrind will scream and give a stack backtrace when your program does something wrong - be it an off-by-one error, be it memory being read uninitialized or whaterver. A truly genial tool.
Gibson Research (Score:2, Informative)
Re:Debugging (Score:3, Informative)
Debuggers are useless for this, since they permute the execution order of a program. Only some hardware-level debuggers running on external machines are any use here.
The normal way to find these is print statements and thinking.
2) A deadlock.
Debuggers are useful here. But you can debug a deadlock with print statements by putting a timeout in your lock primitives that dumps the call stack. That's useful if you don't have a debugger, for example if your software is deployed somewhere and you need to debug the production system.
3) A performance anomaly in I/O bound code.
Debuggers are essentially useless here. Since it's IO bound, you probably want to use logging and possibly some sort of profiler code if you don't think it's a network issue.
4) A stack-smasher.
Debuggers tend to be useless here since the stack gets shredded before the program trips an exception. You might be able to find some stack information with a lot of effort, but it's sketchy.
Try logging instead - you'll hopefully be able to localize where the error comes from. At that point, maybe the debugger can help, but usually you can just look at the code and see the error.
5) Heap corruption.
Debuggers are mostly useless here. What you want to use is a heap debugging library. Usually writing your own is best, since you usually need to write your own hacks to only track the source of the problem if possible.
6) The, uh, printf family of functions.
Heh. write(2)
I program for a living, and I hardly ever use a debugger. For that matter, I hardly ever *have* a debugger. I do recognize that this is somewhat unusual though - most programmers do more apps work, where debuggers are common.
The ironic thing is, in systems level work, I really need to understand assembly.