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? "

Comments

Yes

[Erich]

If you're good.

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.

YES!

[Bluesman]

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.

Re:YES!

[Cyrano de Maniac]

So you'll have to learn an architecture. Intel 386 is a great place to start...

Choke. Cough. Laugh. Thanks a lot, now I have to clean soda off my keyboard.

While the rest of your comment is pretty much spot on, this advice is, frankly, absurd. x86 has one of the most convoluted, non-orthogonal, legacy-laden instruction sets and list of constraints of any architecture, ever. Introducing someone to assembly programming via x86 is sure to warp their brain, and will certainly send the vast majority of people running away, never to revisit the idea. You might as well recommend Malbolge, Intercal, Brainf*ck, or Befunge to them -- it'll result in the same reaction.

If you want to introduce yourself to assembly language programming, start with something sane and simple. To that end, you can't get much simpler than the Motorola 6800 family of processors. Then, step up to something with a richer instruction set, such as the Motorola 68000 family. After having a good grasp of those a person will have correctly oriented their brain to take on more complex but sane architectures, such as MIPS or Alpha. For a challenge after that point, I'd highly recommend IA64 (i.e. Itanium) -- which introduces some really complex ideas, but implements those ideas in a sane and consistent manner. It might be worth learning a DSP processor assembly language (such as the TI TMS320 series) before IA64, to get a handle on concerns regarding explicit parallelism.

Only after learning a number of well-designed instruction sets and architectures such as those should you even consider exposing yourself to x86 and (most likely) the PC architecture. At that point you'll have built up enough intellectual rigor in your approach to assembly programming to survive in the Lovecraftian realm of programming for this architecture. If you're lucky, you'll realize just how truly terrible the instruction set and system architecture are, and avoid programming in x86 assembly whenever possible.

Seriously, I'd even recommend IBM 360 mainframe assembly ahead of x86 for an initial learning experience. Please don't start with x86, it will rot your brain.

Brent

P.S. Yes. I have programmed and/or debugged programs in every assembly language mentioned above. x86 rates dead last.

Re:How to get started?

[p7]

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.

Yes, in some lines of work

[Distan]

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.

My take on how to learn x86 ASM

[MannyMax]

I spent some time last summer doing exactly this, learning x86 assembly language. Granted, I tried to emphasize a specific area that may or may not be important to you (fast, high-accuracy scientific floating-point), and I already had a passable familiarity with assembly from C dumps, but that just meant I could skip large chunks of many of these references -- they're still good stuff. Some of my opinions on how to go about it:

• Don't use Windows. Seriously. Don't. I'm a Windows geek at heart; I know Linux OK and can use it happily on a daily basis, but I'm really at home in Windows. I have been for 15 years. And it's the absolute worst way to learn ASM you can possibly come up with. The problem is that Windows is built on DOS, and in assembly that really shows. Not in the sense that it behaves like DOS -- it doesn't -- but all the interfaces were clearly designed in the DOS era, and few have been updated. Linux, in contrast, has the perfect environment for learning assembly: the system calls are easy to make, reasonably well documented (the documentation is actually pretty bad, but it's better than Windows' -- it exists.), and it's got all the things you'd expect of a modern OS, not all of which Windows always has (like a flat 32-bit address space for everything!). Even 64-bit Linux has no trouble running even pure 32-bit assembly programs once you get the linker flags right.
• Don't use as (or gas, GNU as). If you must, stay the hell away from AT&T syntax, as's default, since no one but as ever uses it. Make sure you learn the standard Intel syntax (like MASM uses) or a very close approximation (NASM or FASM). as used to only accept AT&T syntax, but now it's got a command-line option to accept Intel syntax; honestly, I prefer NASM's slightly simplified, streamlined Intel syntax. They're very close to each other, close enough that once you know NASM syntax you can read Intel syntax no problem. FASM is similar to NASM, and another decent place to start.
• Use NASM. It's free and open-source. It works. Its no-frills approach is perfect for assembly, and a real breath of fresh air compared to convoluted messes like AT&T syntax. The only downside to NASM is that it's 32-bit-only at the moment; this isn't too big a problem, because almost all existing tutorials teach 32-bit anyway (and all the migration guides for 64-bit ASM assume you know 32-bit). If you want to graduate to 32-bit later, there's FASM, which is free and close enough to NASM that you'll have no trouble.
• Stay the HELL away from old 16-bit code in any form. It's ugly. It's obsolete. It's just not worth your time. Of course, using the 16-bit registers is fine when they're the appropriate tools for the job, but seriously, any tutorial that mentions segmentation? Just say no. You'll thank me for this later.
• Don't put too much faith in the Art of Assembly books. In my opinion, they just aren't that good. They were first written in the 16-bit era, and it shows in far too many places. They're also very DOS/Windows-centric, even the Linux version (also not that good), and learning on Linux is much easier with a native Linux tutorial, like this one:
• Get Paul Carter's NASM tutorial. It's nice and low-level, explaining all the basics from the ground up. It does assume you know C, and it does use libc for a lot of the dirty work, but you can always do it the way I prefer and build everything from the ground up with pure ASM and system calls. I figure that if you're going to use C, just write a C-program and call an assembly function or two. If you're going to write it all in ASM, write it all in ASM. There are lots of nice tutorials out there for doing either (calling ASM from C or pure Linux ASM); google "linux assembly tutorials".
• Get the official manuals from Intel and AMD. They are the single best references out there. Yes, get both co