Slashdot Mirror
Why Learning Assembly Language Is Still Good
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)."
Assembly is great because you can kill any linux system you got ssh access to using assembly.
9/11: Never forget it was a false-flag operation
Also, don't forget, a good deal of programming is still done in assembly. Both in a job I've had coding stuff and in my current research (crypto), I did/do a lot of assembly programming. Yes, learning assembly will make a better programmer out of those who never will code assembly again, but for some people, assembly is a valuable and often-used skill
It's a shame that schools are phasing assembly classes out of their computer science curriculums. If anything, it makes for a great foundation on which to learn more modern languages while teaching students things about computers that they probably wouldn't take the time to learn otherwise.
I've programmed a few embedded systems in assembly and it's not very fun at all.
To make matters worse, each CPU has it's own instruction set, and special set of commands that you must learn before you can even sit down and start writing code.
With C++ or at least a C compiler, you don't need to worry about so many implementation details. You should only resort to assembly if you absolutely, must have the performance required. Maybe the author of this article forgets how difficult it is to debug assembly code, or how difficult it is to implement abstract concepts such as OO at such a low level.
I don't agree at all that writing "efficient code" necessarily creates better code. Writing "clearer" is better from a quality standard.
We have compilers for a reason, to produce assembly code as efficiently as possible for a higher level language. Most 99% of the time, the compiler will optomize the code just as well, or better than you can.
I would still recommend learning assembly language to C++ programmers simply so they understand how the computer is actually working. But to require anyone to program in assembly requires a great deal of justification.
Absolutely.
Disclaimer: I learned to debug before I learned to code.
With extremely few exceptions, machine code performs exactly as advertised. When things are not exactly as they should be, it helps to be able to see exactly what is going on.
Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.
I'll put my crudely coded Javascript quicksort algorithm against your finely honed 100% assembly bubblesort algorithm any day. Not only will my algorithm beat the pants off of your algorithm, but I'll also code it in far less time and with way fewer debugging sessions than you would.
You're on. After my exams are over, I'll code a bubblesort algorithm in assembly language. I wonder how large the dataset will have to be before you win? Mail me.
What platforms would you use to teach assembly?
Intel could give many kickbacks to university programs, but they appear to get criticized for chips with too much baggage and backward compatability.
The RISC PowerPC processor has potential, but the number of consumer desktops with it has been on the decline (Is anyone but Apple left?). Computers might be too expensive for some students.
A Palm Pilot / Handheld sounds like a great choice to me. They're cheap and can be synced with whatever consumer desktop the user has (I can't imagine coding assembly in Graffiti). The limited hardware is probably a plus for academic purposes.
I think this fellow makes some great points, but what platform and tools would you choose to learn assembly with?
While the majority of the Unreal engine is C++, we often write assembly-code versions of critical functions for specific platforms. Of course this is done after the C++ versions are tried and tested, and the bottlenecks are idetified.
To take full advantage of processor features like SSE or AltiVec you don't really have a choice.
For example, UT2004 contains SSE and AltiVec assembly versions of some of the vector and matrix manipulation functions, some of the visibility culling code, etc. The amount of work Dan Vogel put into this kind of optimization is one of the reasons that UT2004 runs better than UT2003 on the same hardware.
Learning assembly language is useful, as it's sometimes the right tool for the job.
I think learning compilers and how they will take your code and mangle it into machine code is more important than learning assembly, specifically. Building your own compiler will require you to learn some assembly (or at least the notion of it) which is sufficient for this purpose.
I wonder how large the dataset will have to be before you win?
:) For a large, random dataset I think I'd win out on that one. Check out this sorting algorithm demo page (uses Java applets). Looks like the Shear sort kicks ass over all of them.
Yes, this really is the crux of it all and I left that out. I participated in a very interesting challenge to generate 10 unique random numbers in a scripting language. The goal was for minimal time. As it turns out, a simple array check of whether or not the number has been included worked the fastest due to the fact that you're generating only 10 numbers. As soon as it got up to 100 or more, the array approach O(n^2) broke down.
So for a small dataset, I'll award you your prize already.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
In this case I think the reason was the system having to load the binary vs. the script interpreter already being resident in memory. The start up overhead dominated the actual runtime overhead - binary searchs are very quick.
Having said that, knowing assembler is useful because it teaches you how the machine works.
However, most modern compilers can generate code that is much faster than handwritten assembler - especially because they know how to take advantage of the specialized processor architectures (hyper-threading, pipeling etc).
...richie - It is a good day to code.
I've been reading this site since it was chips n dip, but this is the first time i've ever felt the need to comment.
I can't believe that any developer could write and code without some knowlege of ASM. Disclaimer: I'm self-educated, so have no bias except my own.
More importantly, if you don't know ASM and can't understand machine language, you'd never get through Knuth's tome "The Art Of Computer Programming".
In my opinion, this is the most important work ever written in our field. Any developer worth his/her salt should have at least read and understood these books, and completed at least the simple exercises.
the examples in tAoCP are written in machine language for a fictional machine, but the depth one learns by reviewing what that machine does with its data is important in any project.
I've never programmed professionally in ASM. infact, i usually work in Perl/PHP/Python. But i would not be able to write quality code in those languages if my mind was not constantly thinking of the machine. After all, i'm a computer programmer, not a linguist or scientist.
Not knowing assembly, or at least having some idea as to how a computer processor works, would make a programmer useless in my eyes. leave them to Access or VBA, and leave the coding to us pro's :)
I beleive that ASM should be taught first. If you can't understand ASM, you'll neer be a good programmer, so why bother learning Java/C++ or whatever? would you trust a doctor who didn't know how the body works?
drewcOpen Source Business: The Tech Co-op
Drew Crampsie - Software Developer
Open Source Business : The Tec
Actually, there's a Perl module that does this. But if you wanted to write said C program from scratch, it could take you a while--writing the Perl program would be much faster. And then there's the choice of algorithms involved. Have fun writing your own sorting functions in C, your own regular expression library in C, your own arbitrary precision number library in C, your own reference-counting garbage collector in C, your own closures in C...
:)
Of course, there are other pre-existing C libraries you could use that do all of these things, but there's no telling whether or not they're faster than what Perl uses internally, and since you're re-implementing everything in C anyhow, you might as well just write your own!
So the point I'm trying to make here is this--Perl is convenient because it has all these things written for you and integrated together. Sure you could write a C program that does the same thing, but you'd end up re-inventing the wheel many times over, and you'd have to work hard to make it a better wheel.
Or you could target Parrot instead, for a lot of things it's already faster than Perl. It also has a JIT compiler, so who knows--it might generate some code here and there that's faster than what your C compiler generates.
pb Reply or e-mail; don't vaguely moderate.
Turns out I was overruning an array, and the static strings for the debug printf()s gave my process just enough space that it stopped trying to trash another process' memory (just its own).
Luckily, as a former assembly language programmer, from the mere change in behaviour, I had an inkling of what was going on...
--
An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.
As I argue in Code Reading, other cases where reading assembly code can be of use are:
To read compiler-generated assembly code you need:
Obligatory "hello, world" program written in i386 assembly:
Diomidis Spinellis - #include "/dev/tty"
In an article I read the CEO of FSecure was quoted as saying the biggest recruitment problem is the lack of assembly language teaching in universities these days.
I guess it helps if you are in the business of making bugs, too.
I'm sorry if I haven't offended anyone
A number of years ago, while I was working for a Baby Bell, we were building a system, and integrating it with BEA's Tuxedo. One day a couple of the consultants came to me, to tell me that it was crashing, and they couldn't figure out why.
I pulled it up in the debugger (a Sun box), and stepped through the code...and, when I found it was crashing in Tuxedo, I did something the consultants (young guys) had no clue you could do...I stepi'd *into* the binary.
Now, I didn't know Sun assembly language, but that was irrelevant. I nexti'd and stepi'd my way through, and found the name of the function it was crashing in, which will *always* be there, even in a stripped binary, and where it was doing it in the function.
I could then call BEA (I was senior technical, and Rank Hath Its Privileges), and get info from their developers.
Turned out to be the environment, not a bug, but the point is, once in a while, *knowing* what how things work Down There will save your butt, and maybe even lead you to better code.
mark "and I pushed my kids to know what
happens under the hood of the car, too"
I was reading hex dumps and hand coding small assembler routines in high school (read: 24 years ago), and its been an invaluable skill over the years. I've written 'C' programs that call assembly routines to access OS functions that no routines existed for, understood how parameters got passed on the stack so when something got corrupted I could look at a hex dump and figure it out within minutes.
I took the TCP/IP software for an old minicomputer at my old job, licensed to the particular CPU, and figured out how to defeat the licensing so it'll run on any machine... all with no source, just by decoding/hacking the assembler and changing a few BNZ (branch Not Zero) to straight branches. I've played with building my own boards, and writing drivers for them.
From the standpoint of knowing how things work.. having the base knowledge of how the underlying hardware works, I can pretty much pick up any language on the fly.
I had a guy recently who I had to explain why:
status="green";
if (result1 >= 0) status="red";
if (result2 >= 0) status="red";
was better than:
if ((result1 >=0) && (result2 == 0)) status="red";
else if ((result1 == 0) && (result2 >= 0)) status="red";
else if ((result1 >= 0) && (result2 >= 0)) status="red";
else status="green";
no concept of the difference in 6 compares & 3 logical and's, vs two compares. Not that his way wouldn't work.. but *efficiency*. In a lot of ways, in my mind, mastery of assembly language can bring great insight into the *best* way to accomplish something.