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

Yes

[Erich]

If you're good.

If you know DSP, are adept with fixed point arithmetic, know a bunch of fun tricks [hackersdelight.org], 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:Unless your compiler emits C

[Surt]

A lot of languages these days are emitting java .class (binary) and letting the VM do the work.

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 [ucr.edu] it should get you started.

One thing...

[petrus4]

...that learning assembly will teach you is that a libc is really a convenience, rather than a necessity. If you know what you're doing you can accomplish pretty much anything either via system calls directly to the kernel, or by writing your own asm functions for various things (print, etc) and then simply calling *them* via includes. If you end up writing your own asm includes for things you'll still get some bloat, but I can guarantee you that it will be an order of magnitude less than using glibc. There are times when that can be valuable...like if you're needing a system which will fit on a floppy or usb stick, or for an older system with less ram etc.

I strongly recommend checking out asmutils [sourceforge.net] if you want examples of asm programs that actually do something useful. Some of these (such as ls and the basic httpd) are less than 1k in size.

You might also be interested in Menuet [menuetos.net], which is an entire (small) OS including GUI written completely in either 32 or 64 bit asm.

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.

Re:Honestly...

[Lehk228]

what the fuck is it with pointers that is so difficult?

i'm a novice coder and people constantly bitch about how hard pointers are, so when i read what they actually are(this was quite a few years ago) I went back a few times thinking i must have missed something "....surely there is more to it than that...." i thought to myself.

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 [drpaulcarter.com]. 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

Re:My take on how to learn x86 ASM

[Anonymous Coward]

Could you elaborate on your mention of Windows having DOS-style interfaces please? The Win32 API lives in kernel32.dll which acts as a shim, redirecting calls through to the native api (ntdll.dll if you're on an NT system). DOS interfaces? What the hell are you on about?!?!

Windows doesn't have a flat memory model? Are you on crack, or are you running Windows 3.1?

Madness.

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.

Steve Gibson seems to feel it's worthwhile

[Kevoco]

from http://www.grc.com/smgassembly.htm [grc.com]
Huh? . . . Windows in Assembler?

Am I sick? Perhaps. Am I a dinosaur destined for early extinction? Yeah, probably. But I truly love programming. It's what I do. It fulfills me and sustains me . . . and I'm never in a hurry to "just be done with it." I can't stand sloppiness in my work, so for me that means writing the smallest, tightest, fastest, most economical computer programs possible. And THAT means authoring Windows applications in Assembly Language.

Though the rest of the world may argue that they're more "productive" (when measured by hard disk space consumed per second), I stand by the principle that: "Small Is Beautiful".

Re:You should not learn it..

[gripen40k]

I'd have to agree with you there, and electrical engineers have to know everything from the ground up; microelectronics, digital logic, computer architecture, assembly, and finally programming languages. All of them have their uses, and when building even basic control circuits you have to use pieces of them.

For example, if I were to build some kind of light controller, I could use... microelectronics knowledge to use a BJT that drives a LED via a microcontroller. The microcontroller uses its analog to digital converter to test some voltage that in turn controls the output to the BJT. I can use some logic circuits to have serial input from a computer to control/program the microcontroller. The computer is programmed in C++, the microcontroller in assembly (or C if you have the neat-o compilers).

Even if pure software people may not have to use it, and therefore think it's irrelevant, assembly is still a big part of the picture when it comes to the nitty gritty parts of electronics design. I've used the C compilers for the PIC microcontroller and they are nice and all, but don't do anything efficient at all, don't support any power saving states, and generally needlessly use up memory. They are great to use to do preliminary design, then you can go in and do some bit hacking if you want your controller to run as fast and as cheaply as possible.

Re:oldskool

[Anonymous Coward]

It sets the video mode to 0x13 (320x200, 8-bit color), shows the mouse pointer, and exits.

Re:easy as 1 2 3

[afidel]

RIT, they have a fab on campus =)

Re:Yes.

[vux984]

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.

Just have your friend write a strcat() himself using C, and he'll learn where/why its inefficient. (Or he won't and he's just dense.) Either way knowledge of assembler or lack thereof isn't the issue.

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.

You don't need to understand the dangers of lugging or redlining in terms of the mechanics of what is happening its enough to know that either leads to 'big engine problems' and to avoid them. That the mechanics involve engine strain, overheating, misfiring, etc is superfluous.

Its easy to feel lugging with just a bit of experience and even a complete neophyte knows what redlining looks & sounds like. From there on, its enough to know to avoid both.

Re:Yes.

[ekstrom]

An example: A few days ago I had to explain to a very competent desktop programmer, who was doing the unfamiliar job of writing test C code to be ported to an MSP430 embedded processor, that taking an integer modulo 1440 was a bad idea. The MSP430 has no divide instruction, so the modulo had to compile to a division subroutine made of subtractions, tests, and shifts. In this case there was a way to code the overall task that evaded the need for the modulo. When doing embedded C on a processor of that size (still a lot bigger than a PIC) I ALWAYS look at the compiler output when I am writing anything where I care about either size or speed of execution.

Re:All's quiet

[that this is not und]

There's no 'PIC C Compiler' for the PIC10F200.

It's basically a little grain of rice if you buy it in the surface mount package.

A fairly powerful little grain of rice at that.

Re:My take on how to learn x86 ASM

[NoNickNameForMe]

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.

I teach Assembly Language Programming, and for that reason I refuse to teach it on x86 because most available books are using 16-bit (DOS/BIOS based) x86 code. Unfortunately learning 32-bit x86 is a much bigger jump (conceptually) for newbies, I'm not sure it can be done in one semester to students who never had Assembly exposure before.

Ideally, I'd like to use ARM as the reference assembly language for teaching. It's reasonably clean, and has a sufficiently large code base (i.e., PDAs, embedded systems) to be worth the while to learn. I'd love to find out what books are availble for learning Assembly Language Programming on ARM though.

Re:All's quiet- Assembly still relevent

[Douglas Goodall]

As a guy who kept programming in assembler for many years after C was around, I would point out that BIOS code is often written in assembler becauses it is so low level and it gets used a lot, or at least it used to. Now days the operating systems take over most of the hardware after the system comes up, but in the original IBM PC, the BIOS provided the interace layer to all the hardware.

Re:All's quiet

[Mekius_]

There's no 'PIC C Compiler' for the PIC10F200.

Uhhh...yeah, I'm gonna have to go ahead and disagree with you on that one...http://ccsinfo.com/devices.php?page=devices [ccsinfo.com]

Re:All's quiet

[ncc74656]

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.

.. LDX #$40
]1 BIT $C030
.. LDY #$18
]2 DEY
.. BNE [2
.. DEX
.. BNE [1

That'll give you one cricket-like chirp. Throw some more loops around it to make it repeat with the right cadence. :-)

(Remove the dots...they're there only to get the columns to line up.)

Re:Answer to "What's hard about pointers?"...

[4D6963]

I hate to think of pointers as a "representation" of something. (Disclaimer : I'm a C and ARM ASM coder) When I learnt Pascal I thought that to call it a "representation" was utterly confusing. Just call it an address, because that's what a pointer is, it's as simple as that, it's an address, it's so simple.

Re:YES!

[CrankyOldBastard]

Motorola has some nice development kits. They feature a 68xx or 68xxx processor, a small amount of ram ,a monitor rom, a hex keypad, a 7 seg LED display and an RS232 port. Not very expensive and you can put your fingers into everything.