In high school (way back in the late 80’s) I took several courses on programming focusing mainly on Pascal, Basic, and Fortran. I remember my teacher saying that these were fine to play with but if I were serious about learning to program that I needed to learn Assembly. He said that the fastest, best, games and applications were all programmed in this language (and he said it would always be so since this was the “native” language of the computer). Is that still the case? Are there people out there rendering Half Life 2 or Empire Earth in a long series of ones and zero’s? If not does anyone use this language anymore?
Typically a good C++ compiler will do at least as good as an intermediate assembly programmer in terms of speed. Assembly is still used for embedded development and for optimizing small bottleneck segments in big programs, but 99% of modern software is written in a higher level language.
I don’t think that back in the late '80’s most “serious” programming was done in assembly language. This is an unmanageable approach for large projects. It’s also non-portable (it’s processor-specific). It was used then, and is used now, mainly in certain specialized applications.
By the way, programming in assembly language does not mean programming in ones and zeros. You write much more human-readable strings, and a program–the assembler–translates them into machine code for you.
Only person I’m aware of that does any significant assembly programming now is Steve Gibson, perhaps best known for “Spin Rite” a data recovery tool.
For the other 99.9999% of the programmers, C++ seems to do the job nicely.
An assembly language course is a requirement for a Computer Science major at some universities (North Carolina State being one of them). This course is also the reason that I’m no longer majoring in Computer Science…
I would say that the main value of an assembly language course to most people is that it teaches you how computers really work. It’s something that every serious programmer should see, even if he or she will never program in it in the real world (and most won’t).
Being able to write assembly isn’t all that important these days, but there’s a definite value in being able to read it.
I have a BS from University of Michigan in CS 1979. Way back then you didn’t necessarily need to take a course just in assembly programming but the OS course required assembly programming (I also took a 1-credit mini-course in IBM 360 assembler).
Learning assembly language programming is essential to a broad-based CS education, but most programmers never use it on the job. But it is invaluable for understanding how computers and high-level languages work. Assembly is a little like chess. It’s really easy to learn all the moves, but takes a lot of experience to master.
I would agree with other posters that a well-optimized C compiler can probably give you all the performance you really need almost all the time.
Ain’t any of you guys played with microcontrollers at all? (If you haven’t, get one–they’re fun).
Assembly language is still pretty common when you’re working on a PIC or an AVR.
This comment is wrong in a few ways 
It’s not the “native” language at all. It’s still a compiled language, it is just extremely low level, where the strings used relate to op-codes in the processor, which is why it is not as portable as higher level languages. I studied (read: stumbled through) an Assembly unit doing a CS degree and while I’ve never used it since, it did allow me to learn a LOT about how a processor works, and gives you the building blocks of information to understand higher level languages. A few languages also allow you to insert inline assembly code to further optimise some operations within the higher level language, I think C/C++ both do this and plenty of others do also. I think a lot of games would use optimised code in this method for specific graphic routines, but not as the general language.
It’s still useful for accessing processor-specific features that can’t be accessed from a high-level language. There are also processors that are too primitive or weird to have a decent high-level language.
There are places where knowledge of assembly is important, even if you don’t actually “write” in it.
At the top level, if I know that a certain processor can only do a 32 bit fetch on a 32 bit boundary, and that if the address is on a 16 bit boundary the compiler will turn it into 2 16 bit fetches, I can make sure that the 32 bit long fields in my structures are all on the proper alignment, and make my program more efficient without actually writing out the 32 bit fetches in assembler.
It also helps clear misconceptions on what is more efficient and what isn’t. There are people who think that:
for (i = 0; i < j && k!=0; i++)
{
etc
}
Is more efficient than
for (i=0; i<j; i++)
{
if (k== 0)
break;
}
simply because the latter “has another if in it”, despite the fact that when both examples are compiled they each have the same number of conditional branches.
The other reason why you need to know assembly is when you’re debugging pieces of your program that you don’t have the source to (like OS library files), and you have no other choice.
Of course, some people really do have to know how to write well structured assembly language code. Compiler writers, for one.
These are the reasons why Assembly is still required for a college CS degree.
-lv
I’d never consider writing a whole program in assembly. A rule of thumb is that the CPU spends ~90% of the time executing ~10% of the code. Writing that ~90% in assembly would be foolish, even if modern compilers didn’t approach the code quality of the best of assembly language programmers.
Even for the critical 10%, I’d have to think long and hard before dropping to assembly. In my experience most optimizations are the result of changes in data structures and algorithms made possible by deeper understanding of the problem gained by the experience of writing the first version. If I had written that first version in assembly, I might be able to squeeze out 10% or so, but with better algorithms I’ve managed several orders of magnitude. Only if that 10% is still too slow would I go for an assembly implementation of the best algorithm I’ve come up with so far.
Assembly code I’ve written is stuff like low-level interrupt and exception handlers for a proprietary OS, integer division (for an embedded CPU without a divide instruction), one’s complement checksum (for TCP and IP), and implementations of the str* and mem* functions for several processors (just for fun).
Beyond the responses already given, here’s another ‘personal experience’ to offer:
The professor I took my assembly language programming course from (in 2000) was teaching the course as a part time job. Their full time job was assembly language programming for one of the major airlines. IIRC, it was mostly dealing with databases. Yes, I’d say that eaking out every bit of performance is neccessary when dealing with objects hurtling through the air… (Note: they didn’t go into much detail about exactly what they did.)
<< General System Error: Please sacrifice a goat and two chickens to continue. >>
From what I know of airline systems, some large commercial carriers use ancient home-grown systems for ticketing, logistics, tracking, etc, and many have had problems with slow system response times, especially in ticketing systems. If you own the database then of course you can tweak the low-level code, but this isn’t an optimal use of anyone’s time. I think most would prefer to go to newer commercial systems; for example I know Delta has already migrated to SAP.
Anyway, to get back to assembly, for most people it would be a waste of time to build software in it. But being able to read assembler code can help you spot problems.
I personally write quite a bit of assembly code. I design hardware and software used for industrial controls. I write a lot more C than I used to, but there are some places where most of the work is still done in assembly. In the past year, I’ve written driver level stuff for a proprietary operating system that was mostly in assembly, and have written quite a bit of assembly code for embedded microprocessors.
Games back in the days of the XT may have been largely written in assembly, but by the time the 386 came out most of the source was in C++ with only the time critical parts done in assembly. These days even the rendering loops in 3-D engines are mostly done in C++. You’re not going to find much assembly source in a typical PC application. These days though, almost everything has a microcontroller in it. Your microwave, coffee pot, oven, washing machine, and even your car all have microncontrollers in them, and most are programmed in assembly.
I am an assembly programmer myself, not by profession but by recreation. Most of the stuff that I’ve done in assembly was just to stay up on my skills. One project was a program that finds prime numbers, and I was going for speed to see how fast I could make it. I got it to run significantly faster than the C version. Another program was an emulator, which needs speed and simply makes the most sense to write mostly in assembly. (I never finished it though.)
Assembly has to be used partly in operating systems and in lib files in C/C++. The compiler itself could be written in a higher language though, unless it’s the first one made for that platform. It’s not nearly as common a language as it used to be, but it’s still absolutely necessary in some applications.
Nothing of value to add, but I can still recall that C9 is a Return on the Z80.
I work in embedded software development, and I write assembly.
Not a lot, mind you. Compilers are, in general, way better at it than programmers. But sometimes you just have to write something that’s very small and/or quick.
As a scientist I needed to learn and use assembly.
Specifically, I was working on developing a scientific instrument, a balloon-borne X-ray detector system for astronomical observations. This instrument needed a microprocessor to get data from the analog-to-digital converters, format the data into a telemetry format and send it to the transmitter. For a simple task like this it makes no sense to use an embedded Linux system or the like. All we needed was a Z80 microprocessor (the same processor used in the Tandy TRS-80 and the Texas Instruments TI-85 calculator) running a tiny assembly program (a couple thousand lines, maybe less).
I imagine most “microprocessor controlled” appliances and electronic devices have such simple processors programmed in assembly.