Slashdot Mirror
Is Assembly Programming Still Relevant, Today?
intelinsight asks: "Consider the following question given the current software development needs, and also the claims of the Assembly lovers for it being a language that gives one insights of the internal working of a computer. How relevant or useful is it to learn Assembly programming language in the current era? "
Please remain ignorant of all lowlevel details of your deployment and development platforms.
Please continue to treat both computers and the tools you use to program as magic black boxes.
That way old dogs like me will still have a job.
How we know is more important than what we know.
For good programmers, yes.
If you know DSP, are adept with fixed point arithmetic, know a bunch of fun tricks, can schedule well... there are many people who would like to hire you. Including the group I work in.
Simply, compilers cannot produce code of the same quality that great hand coders can produce code, especially for complex embedded devices like DSPs. But it's not enough to know how to write assembly, you need to know all the tricks the compiler knows, all the tricks you can play with the algorithm, and all the ways in which you can tinker with the code to fit it nicely into the architecture.
Those things are still highly valueable; people need to get really optimized code for their media players. If you can squeeze 20% out of your MP3 decoder, you can get 20% lower energy usage on your programmable logic.
-- Erich
Slashdot reader since 1997
Well, given that the world runs on embedded systems, and will probably become more reliant on even greater numbers of even more complex embedded systems, I'd say assembler will be around for quite a while. However, in terms of game programming or something, it's probably not amazingly useful any more. It is my understanding that most of the API calls to advanced graphics libraries are about as optimized as they are going to get. Clearly you don't need it to write a medical billing application.
I would not encourage universities to start pumping out CS graduates who have never seen assembly laguage, and don't expect it to phased out of the average Electrical Engineering curriculum any time soon.
Frankly, I don't think it's a very good question. It's sort of like saying, "Given that we now have calculators and computer algebra systems that will do the math for us, is it really worth it to waste students' time learning the nuts and bolts of mathematics?" It has been my (limited) experience in software engineering that knowing how something works on a deeper level will almost always be an asset, and at the worst have no effect at all.
I'm glad I took assembly. I've never "used" it in the traditional sense of writing an application other than in school, but understanding how things work "under the covers" (whether at the CPU, hard-disk or network level) has provided valuable guidance in day-to-day design and troubleshooting.
I've worked with people with very focused high-level programming skills and found that while they could write mostly decent code, their code was also most likely to fail in production since they were completely mentally removed from concepts like disk-seek times or bandwidth constraints. Programmers with a deeper understanding of what actually happened when their code ran tended to make wiser programming choices.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
One day won't there be little nanobots floating around with 512 bytes of memory and a 1 mhz processor that need to buzz around your body and eat up your precancerous cells? I imagine as things get smaller, the miniturization fronteir of computing nescesitates limitations in computing power and memory. This may necesitate a new generation of assembly programmers. Even today in the minituarization/embeddedness/realtimeyness world where many enjoy programming away in plain old C (like me) that knowing assembly is useful. First to look at the compiler's output and figure out what the hell its doing, second to just have a plain basic understanding (not necesarilly a detailed one) of what your C statements/operations/etc is probably turning into in assembly instructions.
Another question, would assembly be more popular if it wasn't such a nightmare to write for Intel's x86 architecture? If we all had nice Motorolla PCs, would assembly be really cool?
Give me a moment. I've still gotta figure out the six nested timing loops I need to toggle the speaker cone in and out in such a way that it sounds like a cricket instead of a bird.
If you never learn assembly language, it's a very strong possibility that:
- You can't write a compiler
- You can't debug C/C++ programs
- You don't really know why buffer overflows are bad
- You don't really understand memory management and what the heap and stack really are
- You don't really know why threads are different than processes
- You can't write a device driver
- You don't know any computer architecture at any depth that matters
- You won't ever understand garbage collection
- You don't know how your CPU works
- You won't think the movies with "hacking" in them are as funny as the rest of us do.
If not being able to do those things doesn't bother you, by all means, don't learn assembly.
The thing is, in order to be a really good programmer, you have to know how the machine works, all the way down. Once you do, you can pick up any language very easily, because you know what they're trying to do and how.
Just learn it. It's really one of the simplest languages to learn. Realize it's not a programming language, but simply the actual machine code represented by mnemonics. So you'll have to learn an architecture. Intel 386 is a great place to start, and it couldn't be easier than on Linux. You have a flat, protected memory model, GNU "as" is likely already installed, and you make system calls using interrupt 0x80 after setting up the arguments.
You should be printing stuff to the screen within minutes, and interfacing with C object files in hours. You can write the GTK "hello world" program in a combination of C and assembly fairly easily.
Get to work.
If moderation could change anything, it would be illegal.
Here are a few reasons you might need proficiency in assembly language:
Try the "Art of Assembly Language Programming" available free at this website http://webster.cs.ucr.edu/AoA/index.html it should get you started.
I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.
(For the ignorant, it takes two string pointers and copies the second one to the end of the first one; this requires zipping all the way from the start to the end of the first string to find where said end is. It then helpfully returns the pointer to the beginning of the first string, the very parameter you passed in. Never mind that the new end of the first string would be very handy for the next strcat to that same string.)
This programmer is generally good at what he does, but the idea that strcat is woefully inefficient is not obvious to him. Even after explaining it to him, yes he will avoid it, but he does not really understand why. He, and far too many other programmers, measure their program's "speed" in lines of code. Sure, they know that a subroutine call has to count those subroutine lines of codes as well, but they simply have no concept of the fact that some operations take longer than others, that there are better ways of doing simple things.
I think every beginning programmer should have to spend a semester on some funky old z80, for instance, all in assembler, debugging in machine language, before they can call themselves a good programmer. The idea is not to get them skilled in z80s, but to give them a basic idea of how computers work.
It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.
Infuriate left and right
First, I'll give the disclaimer that I am a hardware engineer, not a software engineer.
My experience has been that when bringing up new hardware, when you don't yet have a stable bootloader, let alone a compiler or operating system, then being able to write in assembly is very valuable.
More accurately I think I should say that being able to write in machine language is very valuable, as you might not even have a working assembler depending on what you are working on.
Being able to peek and poke a few registers, hand code a loop or two, and maybe write some sequential values across a bus can go a long way in helping you get the hardware going. Hook a logic analyzer to the bus and you're golden.
Even if you do have a whole infrastructure of compilers, device drivers, and operating systems available, none of that helps you when the first damn batch of prototypes (made of the first revision of the PCB, containing the first ever silicon of a new CPU, and the first ever silicon of the the new chipset) won't even boot, and you are trying to get to root-cause ASAP because you've got a whole army of testers ready to have at the hardware as soon as you get it running code.
In short, if you are the guy designing the raw iron that the software is going to talk to, you better be able to step up and take control of the raw iron when the software can't.
Knowing about optimising registers, partitioning the stack, minimising movs, and assembly tuning in general doesn't rely on the same concepts at all.
.net framework would be a major benefit and you cannot do that without an implicit understanding of assembler.
The GP is 100% correct in its uses and you are also correct that its current use is crap.
We have abstracted ourselves far enough away and insulated ourselves so much that I think we are in danger of losing the point of fast computers.
Anyone with visual studio can get a good example of this if you see how long the immediate window takes to calculate 1+1.
It might be great and super and empowers the developer to do more, but something has been lost that I feel Visual Basic classic is fast in comparison.
Finding a decent optimisation of the core
Every time this kind of discussion comes up I think of Mel.
Assemblers are a dying breed but their services are more than needed even today.
liqbase
Nothing to CX here, MOV along.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
I don't think that's a very apt analogy (though few analogies ever are apt). Driving a car to and from work is more akin to using Word (or OpenOffice) on your computer. You don't really need to understand the nuts and bolts of how either one works, but you do need to know what the controls do.
Programming in a high-level language is more like doing basic maintenance on said car. You definitely need to know something about how the car works, and the more you know, the more work you can do on that car yourself. Programming in assembly is sort of like taking the engine out and repairing or modding it. You may never need or want to do that, but knowing how an engine works on a detailed level can help you diagnose and remedy things that don't actually require going to those lengths. Similarly, knowing how a microprocessor works can help you understand more about what you're doing when you program in a high-level language.
It also gets you into a mindset where you're thinking about this sort of thing, which is why assembly should still be required teaching in an undergraduate computer science curriculum.
My philosophy is that you should know the layer beneath the layer you program on. Let's say you're working on Groovy code which is half-interpreted and half-compiled on a JVM which is written in C, perhaps using JIT or perhaps not, running on a CPU. Nothing that you can possibly known about how registers work or how jumps work will help you to understand the performance of your program several layers up -- especially given that your program will run on several different runtimes optimized in several different ways on several different CPUs.
But if you're going to program in Groovy then you should know Java and perhaps JVM IL. If you're going to program in C then you should know assembly. If you're programming in assembly then you should know about how CPUs will reorder your instructions etc. If you're building a CPU, then you'd better know physics.
I really don't think that if you're writing an app in Rails/Javascript/SQL you are going to achieve any performance or debugging benefits by understanding assembly language. It's just knee-jerk to say that every programmer, no matter what they do day-to-day should be knowledgeable about assembly. The same effort expended learning about the layer UNDER your development environment would have a much better payoff. E.g. a Javascript programmer reading the Firefox source code (or at least benchmarking FireFox and IE on important operations). With each level deeper you go, you achieve quickly diminishing returns.
Wow, the first programming language I learned was z80 assembly :-). I use to make games for the ti86.
/ 23280.html
here is a side scroller i made written all in assembly (includes animated screen shot)
http://www.ticalc.org/archives/files/fileinfo/232
The things I learned:
1. 4mhz processor is REALLY fast!
2. How the stack works.
3. How absolute and relative jumps work.
4. How to create "objects" and implement "methods"
5. How the smallest variable, the register works.
I have to say that after making games in assembly, I am actually disappointed in how well the current consoles handle them. I would expect them to be able to crazy things with the hardware they are given. That is also why I am interested in the ps3, it forces programmers to understand the underlying hardware.
Hmm. Assembly is still relevant and useful for certain tasks, of course.
/David
But two things come to mind:
1: Handcoders can code better than good compilers?
Yeah, in some cases after a lot of refining. But it is not as easy as it once was.
Compilers have gotten much better and processors have gotten a lot more complex. It's not just "how many clock cycles does this instruction use?", you also have to take various forms of micro-parallelism (pipelining, branch prediction, etc.) and cache hierachy issues into account.
2: It's good to know what goes on under the hood, sure.
But in many, many software developer tasks, early optimization is the root of all evil.
I would actually much rather recommend a top-down approach for most problems, abstracting away low-level details, rather than going bottom-up. The teaching approach of the great "Accelerated C++" comes to mind.
A lot of developers that know a little or a lot about low-level programming write less than excellent code in other regards (algorithmic complexity, design, re-use, etc.) and they can't seem to stop focusing on performance throughout the process.
For most problems, performance isn't critical, and even when it is, it might be better to look for algorithmic enhancements (lowering complexity) rather than do low-level fiddling.
As a marketable skill, assembly won't get you anywhere. There are a handful of places were knowing a specific assembly language is a prerequisite (boot loaders, deeply embedded applications, etc.) but these are just a fraction of the overall job-space for software engineers. Most software engineers never mess with assembly; they are, in fact, afraid of it and think that it's evil.
Given all of that, assembly language *is* the hardware/software boundary. It's where all of the fancy abstractions from CS dissertations meet reality. Understanding computer architecture is a huge asset as a software engineer, and to properly understand how software and hardware interact, you have to learn at least one assembly language. There is no alternative. For most people, it is an unpleasant experience, but the payoff is enormous. The learning process that you undergo while learning assembly will change the way that you see your software and will help you understand why your code is so slow and how to make it fast by design.
I have one last point. When you tell a potential employer about the low-level stuff that you know or work that you've done, your assembly skills are a proxy for understanding how hardware works (at least to interviewers with half a brain). If their software needs to run fast, they'll be happy that you understand the deep magic of hardware.
(Incidentally, I think that the fraction of software jobs that require an understanding of hardware and knowledge of assembly languages, linker internals, etc., are the only fun ones and the only ones worth having. So I learned MIPS, ARM, PowerPC, and TMS320C6 assembly, and they have all served me very well because I don't have to refactor C# for a living.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
This is particularly true for programs that
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The original post asks if Assembly is still relevant today. I'll ask some rhetorical questions (the only kind in a blog) and see how they apply:
a nalysis/architecture/whatever). The difference is training vs. education.
n dex.html.
* Would you want an astronaut to understand physics and math?
* Would you want a doctor to understand chemistry and biology?
* Should somebody studying to be a Literature teacher take their full set of liberal arts courses, including history?
* Should somebody earning a business degree take music appreciation?
Most of us probably said, "Yes" to most or all of those above. Even if the study seems irrelevant or too "low-level" or too "high-level" at the time, there are areas of coursework that help us understand things better.
I see a lot of dead wood in the IT industry. There are enormous numbers of people who either have no passion or who do not have a deep-enough or broad-enough knowledge of computer science to do their daily data processing job well. They are dependent on others around them for everything, even though they may be very skilled in one area.
By having both a broader and a deeper knowledge, people are necessarily better at troubleshooting and at understanding the areas outside their particular specialty. It makes them be better at all of IT and helps them do their specific role.
You should learn IT two ways -- deeply and broadly. You should deeply learn specific skills (Java/C#/Linux/Windows/scripting in Ruby/whatever) and you should learn broad skills (computing theory/relational databases/networking/troubleshooting/programming/
There is an enormous difference between training and education. Training is learning specific skills for specific tasks (narrow/specific), while education is broader and teaches you how to think, understand, and apply (broad/general).
While taking Assembly may not seem relevant at the time and you may never directly use it again, for every programming task, having a strong background in all of computing theory (including how the CPU handles its low-level instructions) educates you and gives you a deeper understanding. (Don't just be trained, be educated!)
My recommendation is the book My Job Went to India (And All I Got was this Lousy Book). If you can't afford it, read the sample chapters, especially the "Being a Generalist" and "Being a specialist" chapters at http://www.pragmaticprogrammer.com/titles/mjwti/i
Personally, unless you need the specific class/training, I'd say that FORTRAN or COBOL ought to be abolished as required material in all colleges and shouldn't be in the degree program. Those should be electives only. Assembly, on the other hand, should remain required, for a deeper and broader education. (Don't settle for a dumbed-down program).
The difference, again, is training (specific/skill-oriented/task-oriented) vs. education (general/broad/understanding-oriented). Education and being a generalist will reap large rewards, long term. So stick with it and take that class. Assembly is a very important foundation class that educates you, long-term....
Another rhetorical question I have is this: "Are you passionate for IT or is it just a high-paying (presumably) job?" If it isn't a passion of yours, find you passion and do it well. If it is, take Assembly and like it -- it'll help you appreciate IT, your computer, your high-level language, and give you a more educated view of the "soul" of your computer.
(They don't make you take Assembly at many/most schools for their health. It would be a crying shame to remove it from the required courses).