Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Learning Assembly Language Is Still Good

michael posted more than 10 years ago | from the atavistic dept.

Programming 667

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)."

cancel ×


Sorry! There are no comments related to the filter you selected.

Because you can kill any 2.6.x kernel (3, Interesting)

xiando (770382) | more than 10 years ago | (#9404037)

Assembly is great because you can kill any linux system [] you got ssh access to using assembly.

So What? (5, Insightful)

tomblackwell (6196) | more than 10 years ago | (#9404121)

Wow. You can crash a machine with assembly language.

That may seem impressive to you (especially if you're fourteen), but the fact is that exploits can be done in almost any language.

In other news, this doesn't have a hell of a lot to do with the posted article, either.

Re:So What? (4, Insightful)

Nasarius (593729) | more than 10 years ago | (#9404145)

It is a big deal when you can do it without root permissions. Running a webserver on Linux that allows clients ssh access? Oops, one of them can take down the whole box. You're right that it's not very on-topic, though...

Re:Because you can kill any 2.6.x kernel (2, Informative)

Nasarius (593729) | more than 10 years ago | (#9404128)

Interesting stuff. It's not clear whether it's the Gentoo patches or the move to 2.4.26 that fixes the bug, though. Hang on, I'll check...I run Gentoo, but always with a vanilla kernel.

Yep, it kills 2.6.6.

Re:Because you can kill any 2.6.x kernel (4, Insightful)

ceswiedler (165311) | more than 10 years ago | (#9404226)

From your link:

"This bug is confirmed to be present when the code is compiled with GCC version 3.3 and 3.3.2 and used on Linux kernel versions 2.4.2x and 2.6.x. It has been tested to work on, and crash, several lame free-shell provider servers."

If it affects all 2.4 and 2.6 linux kernels, I wouldn't call servers affected 'lame'. Especially free-shell provider servers. That's lame, testing a local exploit on a public shell server.

Re:Because you can kill any 2.6.x kernel (1)

Junta (36770) | more than 10 years ago | (#9404256)

That's 'l337ism' for you.....

Debugging (5, Insightful)

Ann Elk (668880) | more than 10 years ago | (#9404039)

Another reason: Sooner or later, you'll need to debug something without a source-level debugger. Knowing how to debug raw assembly language has saved my ass many times.

Re:Debugging (4, Funny)

dduardo (592868) | more than 10 years ago | (#9404078)

Microsoft not giving their employees access to the Window's source code eh?

Re:Debugging (1)

vontrotsky (667853) | more than 10 years ago | (#9404116)

Sooner or later, you'll need to debug something without a source-level debugger.


Re:Debugging (4, Insightful)

Ninwa (583633) | more than 10 years ago | (#9404284)

No, you can't exactly debug a fubar memory stack with just printf. Maybe in your hello world program, but not when things get complicated. :) Trust me, I know. I'm writing a rather large network application at the moment and somewhere along the line I must've overshot an array, but one mistake can ruin a whole application, and printf'ing wont help you.

Learning how to debug is just as precious to a programmer as learning how to code.

Re:Debugging (5, Interesting)

Tony-A (29931) | more than 10 years ago | (#9404146)


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.

hello (0, Troll)

Anonymous Coward | more than 10 years ago | (#9404041)

any one there ?

Why it's still good... (5, Interesting)

WilliamsDA (567274) | more than 10 years ago | (#9404042)

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

Schools not teaching assembly anymore (5, Interesting)

csimpkins (787236) | more than 10 years ago | (#9404051)

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.

Re:Schools not teaching assembly anymore (5, Insightful)

thegrassyknowl (762218) | more than 10 years ago | (#9404088)

I was fortunate enough to learn assembly on a few architectures. Admittedly all of them are microcontrollers (PIC, AVR, HC11), but it really does force you to understand how the machine is working.

Some of the more serious asselbly languages still scare the hell out of me though; have you ever looked at the assembly for the TI C6x DSPs? It took me quite a while to come to terms with something simple, and the C compiler can better use the 8 parallel execution units better than I can...

Re:Schools not teaching assembly anymore (0)

Anonymous Coward | more than 10 years ago | (#9404106)

It's a shame that schools are phasing assembly classes out of their computer science curriculums.

It's not a shame to me; I'm an ECE.

Re:Schools not teaching assembly anymore (4, Insightful)

dexterpexter (733748) | more than 10 years ago | (#9404251)

I am assuming you said this to be funny, otherwise it is indeed a shame.

ECE (especially those with a heavy electrical engineering lean) people deal with microprocessors. Motorola chips have special features that you can't access with most C compilers and thus it is necessary to know assembly.

Also, until recently, finding a good C compiler wasn't cheap. Now, of course, there are free ones.

Coming from an ECE program without a microprocessors class in which you apply Assembly will make you less competitive than the graduates coming from schools in which engineers are taught both practical assembly application, and high level languages.

Re:Schools not teaching assembly anymore (5, Interesting)

dsheeks (65644) | more than 10 years ago | (#9404126)

Knowing something about the low level hardware / machine instructions and what compilers do to translate high level languages definitely helps programmers make better programming decisions.

Given the rise of byte code environments like Java and .NET and the sophisticated tools available for working with them, I would think schools would do well to teach a class programming at that level. While obviously not a true assembly language, something like Java byte code is a lower level look at how programs really work, and since Java is highly portable you wouldn't have to worry about what hardware the students used like you would with an actual assembly language course. I still think doing some work with assembly and getting some exposure to hardware architectures is best, but this might be a reasonable alternative.

Re:Schools not teaching assembly anymore (2, Insightful)

etaylor (471392) | more than 10 years ago | (#9404274)

I would agree with that. I looked at an introductory computer science class that used Java. The first few weeks involved basic programming concepts. Then they would spend a week or two on multithreading, a week on file I/O, a week on inheritance, and so on. No wonder some of the students ended up being a little fuzzy on basic concepts, like how a computer executes one instruction after another...

Re:Schools not teaching assembly anymore (1, Informative)

Trigulus (781481) | more than 10 years ago | (#9404132)

Most of what I see come out of "computer science" curriculums including BS and MS are woefully unskilled and sloppy. You dont want these people touching assembly. I learned assembly without even realizing it as a child with a Radio Shack Microcontroller Trainer. One of those old kits with all the spring terminals except this one had a hex keypad to enter programs with. I can't find a link to the product its too damn old.

Re:Schools not teaching assembly anymore (4, Interesting)

Trigulus (781481) | more than 10 years ago | (#9404190)

AHA! I found it! I had the name slightly wrong. mputers/Tandy/uCptrTrain.html

Re:Schools not teaching assembly anymore (4, Insightful)

DaveAtFraud (460127) | more than 10 years ago | (#9404152)

I have to agree. I run into quite a few people looking for programming jobs who don't understand what the CPU has to do to execute their code. They do dumb things like multithread something that is CPU bound becuase they have no understanding of how what they write actually gets executed. Same thing with regard to data representation mistakes.

I'm not saying that everyone has to become a proficient assembly level programmer but I think a lot of people would be a lot better HOL programmers if they understood something about assembly language. I wonder how many Windows buffer overflow exploits are simply the result of someone not understanding that just because you can't express it in a HOL doesn't mean you can't exploit it from assembly code.

Re:Schools not teaching assembly anymore (0)

Anonymous Coward | more than 10 years ago | (#9404224)

Ahem. While I hated it at the time, I'm glad my computer science program [] has a class on writing an assembler and a virtual machine for a very simple assembly language as a prerequisite for declaring your major.

Re:Schools not teaching assembly anymore (0)

Anonymous Coward | more than 10 years ago | (#9404231)

This was forseen 10-15 years ago when schools started to phase out microprocessor electronics classes. Before the electronics classes were phased out assembly language was taught for two purposes: (1) as a basis to higher level programming, and (2) so that a programmer actually knew what happened to his or her data after the language got done with it (i.e. how a computer communicates with peripherals, RAM, etc). A very easy question I like to ask CS graduates is "What is the purpose of the control bus?" It tells you right away if they are factory-CS-program output or people who have an in depth understanding of how a computer works depending upon their answer.

don't bother........ (5, Insightful)

Anonymous Coward | more than 10 years ago | (#9404055)

Hate to say, but the kind of optimization you learn about by knowing assembly language is just not necessary for most programmers these days.

I learned programming in the 80's, and I did learn assembly language, starting with 6502 assembly. I would subconciously code my C so that it would produce faster code. Every block of code I wrote would be optimized as much as practical. My code was fast and confusing.

When coding Perl or Java I would keep in mind the details of the underlying virtual machine so I could avoid wasteful string concatenation or whatever. I cache things whenever possible, use temp variables all the time, etc., etc.

I've spent the last few years trying to UNLEARN this useless habit. There is just no need. And in highly dynamic languages like Ruby, it's pointless. You can't predict where the bottlenecks will show up.. almost every project I've worked on has either had no performance problems, or had a couple major performance problems that were solved by profiling and correcting a bad algorithm.

Stuff like XP and agile development have it right: code as simply as possible, don't code for performance, then when you need performance you can drill down and figure out how to do it.

To me a beautiful piece of code is one that is so simple it does exactly what it needs, and nothing more, and it reads like pseudo-code. Minimalism is the name of the game.

So my advice is, don't learn assembly language. Learn Lisp or another abstract language. Think in terms of functions and algorithms, not registers and page faults. Learn to program minimally.

On another note, the tab in my Konqueror for this article reads: "Slashdot | Why Learning Ass...". Heh. :-)

Re:don't bother........ (1)

rmull (26174) | more than 10 years ago | (#9404103)

Hear hear! There was something bugging me about this article and you've articulated it exactly. Coding for maintainability, clarity, and correctness is far more important than optimization. Increase in computer speed and size allows not only the luxury of additional features but more importantly the ability to work at a higher level and get more done.

far more important than optimization (4, Insightful)

exp(pi*sqrt(163)) (613870) | more than 10 years ago | (#9404166)

You know, when you're trying to get a game out the door that runs at 30fps and your competitor has a similar game running at 60fps because they coded their inner loops in assembly you begin to realize why optimization is important after all.

Re:don't bother........ (4, Insightful)

reallocate (142797) | more than 10 years ago | (#9404129)

Why does use of assembly preclude thinking in terms of functions and algorithms? Algorithms are the essence of programminmg; registers, syntax, etc, are just tools to implement algorithms.

Re:don't bother........ (2, Insightful)

dsheeks (65644) | more than 10 years ago | (#9404205)

Dead on. There are probably lots of people that learned something about assembly language and saw it as just a bunch of linear instructions. Good modular programming can be done at more than one level. Good, easy to understand design is critical, but performance can be critical in many situations. Besides, the point isn't to know something about assembly so you can make EVERY decision based on optimization, but so you can make the necessary optimization decisions in an informed way.

Re:don't bother........ (1)

Qzukk (229616) | more than 10 years ago | (#9404158)

then when you need performance you can drill down and figure out how to do it.

Or you hire someone who understands why certain behaviors yield performance, instead of sitting there and trying different things until you work something out that seems a little faster.

Re:don't bother........ (1)

mabinogi (74033) | more than 10 years ago | (#9404159)

I agree with most of what you said....but I'd still use a StringBuffer rather than a String for multiple concatenations...

There are some things which are just a good idea regardless....

Re:don't bother........ (1, Insightful)

Anonymous Coward | more than 10 years ago | (#9404185)

2 points:

1) Minimalism and assembly are not mutually exclusive. As you said, optimize at the end, and that optimization could be implemented with assembly.

2) You can't tell me you are not a better programmer because you know assembly. Yes, we don't need to think about machine architecture or vm design as much as we used to, but you can't tell me it's not extremely useful in the circumstances that we do.

The more languages you know, it changes the way you program. Yes, learn assembly, learn lisp, but also learn eiffel, haskell, objective-c and prolog too.

Re:don't bother........ (5, Insightful)

MBCook (132727) | more than 10 years ago | (#9404188)

I disagree.

I have seen FAR FAR too many students in my various college programing classes who think nothing of calling functions with 15 parameters and copies of large datastructures (not references) and other such things. I really think that assembly should be one of the FIRST things taught to future programmers. So many people I've run up against don't have any idea how computers work. Sure things are "mentioned" in classes, but so much is lost on them. Somthing as simple as "passing 2 things is much MUCH faster/easier than passing 10" don't get taught.

By passing 10 things, their job is easy. That's all they see. They don't know about registers (other than they exist and are sorta like variables on the CPU). So they don't know that to pass 10 things you might put some in registers but the rest will have to be passed in memory (which is slow) as opposed to puting everything in registers (if at all possible) which is faster (especially for simple functions).

The only problem with assembly is the catch-22 mentioned in the article: you have to do all sorts of "magic" to print out to the screen or read from the keyboard, which can be confusing. And it takes a while to get them up to the point where they can start to understand that magic. My school teaches assembly (sorta) on little 68HC12 development boards that have built in callable routines that perform things equivelent to printf and such, so there is little voodoo involved which is nice.

I'm not saying assembly is neccessary, but I DEFINATLY think it's important for programers to learn how things work under the compiler. I have seen FAR too many hideous bits of code that no one who understood the underpinnings of assembly would never dream of.

Try the games industry (5, Interesting)

Jack Porter (310054) | more than 10 years ago | (#9404194)

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.

Re:don't bother........ (5, Insightful)

Smidge204 (605297) | more than 10 years ago | (#9404202)

So basically you don't have time to do it right, but you might have time to do it twice?

Learning assembly isn't all about optimization, either. Being familiar with how the machine works right down to the core will make you a better programmer, peroid. Personally speaking, it also helps develop that zen like ability to "think like the computer", and that helps you program not just more efficiently but more effectively since you can think things out better. You can't tell me you're not a better programmer for having been exposed to it... it simply changes the way you think about the machine.

It can also be argued that "beautiful" code has no bearing on performance. It's also the kind of "Oh performance isn't an issue anymore" and "make te source code pretty" thinking that we now need gigahert+ machines with 128MB RAM just to write a goddamn letter... it's really quite sad that so many programmers just let their applications fill the hardware vacuum they think their users will have, or should have, just because they didn't take an extra day to think about what they're doing and write their code a little more efficiently.

it's a tradeoff (1)

Trepidity (597) | more than 10 years ago | (#9404270)

It's a tradeoff between maximally efficient code and simple code. Complicating matters further, in many cases what you'd think would be "maximally efficient" code isn't actually maximally efficient anymore, given that it's hard to predict what exactly is going to happen when your code is run through an optimizing compiler and then run on a pipelined CPU. In some cases silly optimization tricks C programmers who know assembly do actually slow down the code, because if they had written something simpler, the compiler could have optimized it, and the compiler knows better optimizations (or can compute better optimizations by looking at literally millions of different factors).

Optimization tricks are also notoriously brittle--they're clever hacks that solve a particular problem more efficiently than the straightforward solution. The problem is that if you want to change things, the trick may not work anymore, so you're stuck rewriting it, or often you end up with subtle bugs, because you relied on some clever hacks whose assumptions no longer hold.

And finally, "optimization" of the assembly-programmer sort often has negligible effects. If you actually profile, the biggest speed hits are invariably in a very few places. Most of your other "optimizations" are going to be making 0.001% speedups, if they even speed anything up at all (and sometimes they slow things down!). That's not only not worth it, it's detrimental to your application's development.

This is even more of a problem in higher-level languages. Lisp, Haskell, and other functional languages do all sorts of stuff under the hood to optimize things, and various scattered parts of your code can interact (if some redundancies are found that can be optimized away, even across modules) so premature optimization is generally a bad idea.

Re:don't bother........ (0)

Anonymous Coward | more than 10 years ago | (#9404234)

This is the same attitude that has given us applications that crash incessantly in windows...bloated software, well it has 3+ million lines of dead code but we are too busry to clean it up...The old well good enough argument. All I see from this attitude is bloated, unstable, slow applications.

Re:don't bother........ (4, Insightful)

Tony-A (29931) | more than 10 years ago | (#9404262)

To me a beautiful piece of code is one that is so simple it does exactly what it needs, and nothing more, and it reads like pseudo-code. Minimalism is the name of the game.

From an old fart who likes assembly language, total agreement.
Assuming the primary goal is performance, the blunt reality is that about 90% of the code is irrelevant as to impacting that performance. Any screweys in that code, particularly trying to "improve" performance, will have indirect deletorious effects on that performance.

Best, efficient or cheap (4, Insightful)

jimmy page (565870) | more than 10 years ago | (#9404062)

Come on - all that may be great, but what really matters is what gives the most bang(features) for the buck (cheapest)... and in the minds of the average CEO with 10 billion options this is done by outsourcing to the lowest cost provider (India, China, etc..) regardless of code training, language etc..

Re:Best, efficient or cheap (1)

csimpkins (787236) | more than 10 years ago | (#9404076)

And when that software breaks and costs them millions because it sucks, they'll come back to those that take the time to do it right.

Re:Best, efficient or cheap (2, Interesting)

Anml4ixoye (264762) | more than 10 years ago | (#9404093)

in the minds of the average CEO

Right. Because after reading that article, I thought, "Boy, if *I* was a CEO, this is how my guys would program everything." Actually, he says in there that writing everything in Assembly is not for every project.

So what's great about it is that if someone is looking to make a step to become a better programmer, this would be a good direction to check out so that you truly understand your code. If you are happy being a VB code jockey (or any code jockey for that matter) then rejoice! and don't take the time to learn Assembly.

Smaller code? We can hope... (4, Insightful)

dinodrac (247713) | more than 10 years ago | (#9404073)

Unfortunatly, I doubt that we are going to see many people switching to assembly language, but we can hope. I'd love to see a return to applications that were under 100K

Misuse of high level languages such as visual basic, as well as off the shelf components for everything, has led to a level of code bloat in todays applications that is inexcusable.

(note: off the shelf components and high level languages aren't inherently bad, just not always suitable for commercial applications.)

Also, given that modern optimizing C compilers can often optimize better than humans, it may make sense to embed critical sections of assembly into C code, and let the compiler optimize the rest...

Also, whatever happened to profiling? Has this become a lost art among developers? Time your code. See where it bogs down. Find the fat. Cut it out. Please.

This post brought to you by Save the CPU Cycles!

Re:Smaller code? We can hope... (5, Funny)

Jeffrey Baker (6191) | more than 10 years ago | (#9404108)

Fuck, I'd settle for viruses smaller than 400K! Of all things, you'd expect a virus to be lean and mean, but I guess the latest crops were made with Visual Virus .NET or something to that effect.

Re:Smaller code? We can hope... (2, Insightful)

mikael (484) | more than 10 years ago | (#9404183)

Also, given that modern optimizing C compilers can often optimize better than humans, it may make sense to embed critical sections of assembly into C code, and let the compiler optimize the rest...

In the past, I used to do a lot of assembly language programming, but would always end up being burnt by having to completely rewrite everything for a new CPU/graphics card. It's much more productive to write a generic algorithm in C/C++ and use the assembly output to identify where the optimisations can be made. In nearly all cases, I could restructure the C code to match the optimum assembler output.

TIME TO MARKET, even for free software (1)

Ars-Fartsica (166957) | more than 10 years ago | (#9404221)

Even in open source apps, getting something out there ready to play with is key. Actually this may be even more central to open source ecosystems than corporate development. Would you prefer that the Mozilla developers have taken the assembly route? They'd probably be well on their way to rendering the bold tag by now but thats about it.

Yes and no... (5, Insightful)

Daniel_Staal (609844) | more than 10 years ago | (#9404075)

While I learned assembly, and found it useful for learning to understand exactly how the machines think, I'm not sure I agree with his basic premise. Namely, that great code (code that is well designed for it's job, and easy to work with and under) is always the efficient code, in machine terms.

The machine thinks one way. A human thinks in another. Code that is well designed for easy updating, and extending, is code that is easy for a human to understand. If that is not the most efficient way for the machine to do it, that may be the price for 'great' code in this project. (The ideal balance depends on the project, of course. A kernel should be machine-efficient, for example.)

original title (1, Funny)

Anonymous Coward | more than 10 years ago | (#9404079)

"Why Learning Assembly Language Is Still Good and Why I Still Can't Get Laid"

Suprised there isn't a Visual Assemblers by now... (0)

Anonymous Coward | more than 10 years ago | (#9404080)


What ever happened to Intel's X86 Reference Manuals?

Intel Architecture Manuals (1, Informative)

Anonymous Coward | more than 10 years ago | (#9404232)

Here they are. []

Or you may prefer AMD-64, here [] .

I disagree (5, Insightful)

nacturation (646836) | more than 10 years ago | (#9404094)

Efficiency in terms of coding is a wonderful art and I think it's still applicable today. Kernel-level routines, games, drivers, etc. all benefit from tight coding in assembly language.

But let's be honest here. Computer Science 101: an efficient algorithm coded in an inefficient way will always beat out an inefficient algorithm coded by hand in 100% optimized assembly. 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. Also, the higher-level language you go, the better it is for security. How easy is it to introduce things like buffer overflows, array out of bounds, etc. errors in assembly? How easy is it to do that in Java, C#, etc.?

So yes, writing in assembly language is still good and has its places. But let's keep it to those places, shall we?

Re:I disagree (1)

Daniel_Staal (609844) | more than 10 years ago | (#9404137)

I feel I should mention assembly was the one class where I ever turned in a program that was my first draft, and that I had never tried running myself. (And yes, it ran for the teacher. I was not surprised.)

Now, my classmates could never quite seem to get theirs to work right...

Re:I disagree (0)

Anonymous Coward | more than 10 years ago | (#9404151)

output: ".dlrow olleH"

Re:I disagree (3, Interesting)

bendelo (737558) | more than 10 years ago | (#9404161)

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 [mailto] .

Re:I disagree (2, Informative)

no longer myself (741142) | more than 10 years ago | (#9404196)

I'll put my crudely coded Javascript quicksort algorithm against your finely honed 100% assembly bubblesort algorithm any day.

Depends on what you are sorting. Anyone will tell you that the quicksort algorithm works fastest when dealing with total randomness, but a properly designed bubblesort can quickly shake out a couple of minor swaps much faster than a quicksort.

Re:I disagree (1)

Junta (36770) | more than 10 years ago | (#9404244)

One aspect that bothered me about the assembly course I did was that the professor had the exact opposite beliefs. He felt that no C compiler could ever beat a hand crafted assembly program in terms of speed/efficiency. His absolute measurment of this? LOC. If the resultant assembly had more LOC, it was obviously inefficient as there were more instructions to execute. Discarded was the fact that his provided 'dramatic example' leveraged several loops in the assembly code and the C compiled equivalent had none... His response was that the unrolled loops did nothing but take up system memory and disk storage, and that though he could not prove it, he was sure the assembly program would complete the task first...

It's like learning any language (2, Insightful)

mark-t (151149) | more than 10 years ago | (#9404096)

Learning it is good, even if one never ends up actually seriously developing in it. It advances your ability to solve problems in a language independant fashion and equips you to be able to more rapidly model solutions to brand new problems, even in the languages that you may already know.

Re:It's like learning any language (0)

Jonah Hex (651948) | more than 10 years ago | (#9404263)

Anyone care to define these bits of language, I've seen at least something similar in the news/discussions about the new linux scheduler but I can't recall what the heck the notation means:
O(n lg n)

Jonah Hex

Exposure useful, mastery not needed (4, Insightful)

Ars-Fartsica (166957) | more than 10 years ago | (#9404097)

Developers smarter than you have spent decades building useful higher-level layers to speed up the development of complex code. You would be wise to leverage this incredible infrastructure for the 99.999% of projects that do not benefit from obsessively tweaking the finest details.

Knowing what assembly is and how it works is beneficial. Mastery of assembly is completely pointless for anyone outside of OS kernel, compiler construcution and embedded development...which probably means you. Your time will be better spent figuring out how to make Java programs 10% faster most of the time.

Re:Exposure useful, mastery not needed (1)

Sunnan (466558) | more than 10 years ago | (#9404175)

Developers smarter than you have spent decades

But if you want to become one of them?
There has to be (and will be) a new generation working on kernels and compiler tech.

Re:Exposure useful, mastery not needed (1)

Ars-Fartsica (166957) | more than 10 years ago | (#9404208)

But if you want to become one of them?

Build the next layer - semantic web tools, search engines, p2p networks etc. You don't need to rewrite the compiler or the OS - its done. You are free to move forward to the next layer, safely assuming you probably can't do a whole lot to vastly improve what already exists beneath.

desire to teach someone 6502 assembly language (4, Insightful)

pomakis (323200) | more than 10 years ago | (#9404102)

For some reason I have a strange desire to teach someone 6502 assembly language. I'm not sure why that is, and the rational side of me knows that I'm never going to find anybody who's even half-interested in learning it. I think that perhaps the reason I want to teach it to someone is that it'd be nice to experience someone else coming to the realization of the power of abstraction, the awareness that so much is possible using such simple building blocks. And yes, I strongly believe that knowing how to program in assembly language (and how it relates to the underlying machine language) makes one an instinctively better programmer. And it's frikkin' neat. It's like driving a standard versus an automatic. You become one with the computer.

If you want to teach somebody 6502 (1)

tepples (727027) | more than 10 years ago | (#9404280)

If you want to teach somebody 6502 assembly language, then find somebody on the forums at NESdev [] who's struggling.

how many people actually program in assembly? (5, Interesting)

Doppler00 (534739) | more than 10 years ago | (#9404112)

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.

Re:how many people actually program in assembly? (1)

exp(pi*sqrt(163)) (613870) | more than 10 years ago | (#9404192)

Game developers - especially console game developers.

In what other languages (5, Funny)

foidulus (743482) | more than 10 years ago | (#9404117)

can you get away with naming a source file org.asm?
* rim shot
I apologize.

Not just efficiency but correctness (3, Insightful)

jkabbe (631234) | more than 10 years ago | (#9404118)

I think there is more at stake here than just writing efficient applications. For one thing, writing proper multi-threaded code often requires thinking at the assembly level. Many of my coworkers who are all high-level-language-only programmer types couldn't understand (until I explained it) how the Double-Checked-Locking Java example was broken.

HLA?...nah. (0)

Anonymous Coward | more than 10 years ago | (#9404142)

He's just trying to promote his invented High Level Assembly language, which is no way proper assembly. Well, read his book and judge for yourself.

Re:HLA?...nah. (1)

exp(pi*sqrt(163)) (613870) | more than 10 years ago | (#9404182)

And this is at least the third time this has been promoted on /.

The best reason to learn Assembly (1)

GillBates0 (664202) | more than 10 years ago | (#9404148)

even *moreso* than efficiency, functionality and flexibility is that it enables you to delve into the innermost functionality of a computer.

Master Assembly, and you've mastered computer organization, computer architecture, compiler construction basics, logic, code optimization, and ofcourse programming (I may have missed a few).

It's no coincidence that every good programmer/compiler engineer I've met (I'm one too) has had a strong grasp of Assembly.

Sourcer, if you ever wanted to learn assembly... (0)

Anonymous Coward | more than 10 years ago | (#9404153)

from someone else's experience.

Sourcer []

Because (1)

dtfinch (661405) | more than 10 years ago | (#9404154)

You need it to work on the zsnes project.

Honestly, a fair understanding of assembly language may help you in the long run, despite the fact that you can probably go your entire career without using it directly, and that you're probably going too far most times you do use it. It's just part of knowing how a computer works.

As somebody who has done DSP algorithms (5, Informative)

earthforce_1 (454968) | more than 10 years ago | (#9404155)

Assembly language will always be needed to optimize certain types of algorithms, that don't translate efficiently into C. Try writing a FFT algorithm on C using a DSP, and compare it to what can be done in native assembly. The difference can be an order of magnitude or more. Some processors have special purpose modulo registers and addressing modes (such as bit reverse) that don't translate well into C, at least not without extending the language. Fixed point arithmatic operations are not supported in ANSI C either, but are a common feature on special purpose processors.

For low power/embedded applications, efficiency makes sense as well. Every CPU cycle wasted chips away at battery power. A more efficient algorithm means a smaller ROM size, and the CPU can either be clocked slower (can use cheaper memory and/or CPU) or put into a halted state when it isn't needed. (longer battery life) Coding small ISRs in assembly makes sense as well, as C compilers often must make worst case assumptions about saving processor context.

That being said, only a fool would try and re-write printf or cout in assembly, if they have a C/C++ compiler handy. Hand optimization is best used as a silver bullet, for the most computationally intensive or critical functions.

Even when you write in C... (1)

Archeopteryx (4648) | more than 10 years ago | (#9404160)

Even when you write in C it helps a lot, especially in the embedded systems field, to know what sort of code the compiler is generating. For example, say I have a i++; operation that I expect to use to set a semaphore - is that one operation, such as a Z-80's inc , or is that a lda, inca, sta operation that might be interrupted? This can matter a lot! And I have seen compilers which were inconsistent as to what sort of code they would generate for such an operation. This is just one example, but there are many more, and they can make a BIG difference.

Also, if you cannot read assembler, how are you ever going to figure out what strange compiled code, which has been stripped of its debugging symbols, is doing?

Not sure about his premise (2, Insightful)

r.jimenezz (737542) | more than 10 years ago | (#9404162)

I was lucky enough to be taught assembly on my undergraduate degree, but after five years of "industrial practice" I am not sure knowing assembly will help you write more efficient code, at least not in a modern business environment. IMHO, in these environments you depend too much on pre-existing tools (DBMSs, application servers, etc.) and *those* programmers may benefit from knowing assembly to enhance their work, not you.

Second, and perhaps more important, I think most of the performance issues in such environments stem from architectural, not algorithmical issues. Think J2EE, where if you are not careful enough you end up doing a round trip to the server every time you set a property in an object.

In a sense, he covers this in the article when he writes:

"This doesn't mean, of course, that a practicing engineer should sacrifice project schedules, readable and maintainable code, or other important software attributes for the sake of efficiency.

What it does mean is that the software engineer should keep efficiency in mind while designing and implementing the software."

But of course, most of his emphasis is on knowing how does the machine work. I ascribe more to modern thoughts considering efficiency (and other non-functional requirements, such as the maintenability also mentioned in the above quote) as architectural concerns, things that shape the architecture and that no amount of algorithm substitution and the like can fix if gotten wrong in the first place.

Embedded systems (1)

Jason1729 (561790) | more than 10 years ago | (#9404171)

I use assembly every day to program embedded controllers. There are compilers for them, but I often use controllers with a few hundred instruction words of storage space and a few dozen bytes of ram. Compilers just aren't efficient enough.


ProfQuotes []

Which Platforms? (4, Interesting)

buckhead_buddy (186384) | more than 10 years ago | (#9404180)

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?

Re:Which Platforms? (3, Informative)

Archeopteryx (4648) | more than 10 years ago | (#9404212)

I would start with an emulated 8-bit microprocessor or microcontroller, such as the Z-8 or the 68HC908. This way they can run the emulation on a platform they already have, and such devices, embedded within ASICs are the most likely target for a pure assembly effort anyway.

Just a couple of years ago I did a fairly large 68HC908 application for a housekeeping processor entirely in assembler.

Re:Which Platforms? (1)

Osty (16825) | more than 10 years ago | (#9404240)

The answer is simple -- use an emulator. That way, you don't have to provide hardware to your students, and you can use a nicer assembly language without worrying that you're actually using a x86. In short, the answer is SPIM [] , the MIPS R2000/R3000 simulator. The MIPS assembly language is nice and simple, with an abundance of registers that let you get going with simple apps early on. As complexity grows and the students learn, you can bring in the concept of pushing data onto the stack. It's free, and runs on Unix/Linux and Windows, so you don't have to track down a bunch of old R2000 or R3000 machines for students to use.

If the end goal is to be able to write immediately-applicable code, x86 would be the way to go. If the goal is to learn about assembly languages and concepts, the platform doesn't much matter (or if it does, only to the extent that the language and hardware should be easy to learn).

MIPS (1)

IshanCaspian (625325) | more than 10 years ago | (#9404246)

At Boston University they teach us on MIPS. It was actually one of the easier courses I took there, but maybe that's because I've done a lot more programming than the average BU CS student.

I would have rather bitten the bullet and learned x86, because I could actually USE that for something.

Custom Built Embedded Boards (1)

Rufosx (693184) | more than 10 years ago | (#9404248)

Just like I learned on in college. Ours were 6502 boards with a bunch of other stuff on them, like D/A converters and space to wire up more stuff. At that time we used Mac Pluses as the interface to program and load the assembly into the boards.

These are produced specifically as teaching aids and I'm sure they are still available. We built all sorts of stuff on the boards including traffic light controllers, elevators control and robot servo controls. Fun stuff.

Well.. (0)

Anonymous Coward | more than 10 years ago | (#9404184)

Well Bootloaders and ISR forced me to learn assembly. If you're going to do system programming then I'd highly recommend learning it. Otherwise I don't think its really nessacery.

Important ....because Randal needs to sell books! (0)

Anonymous Coward | more than 10 years ago | (#9404195)

The "Art of Assembly Language", anyone?

i agree (0)

Anonymous Coward | more than 10 years ago | (#9404200)

mov ax, assembly
learning ax
mov bx, good
is ax, bx

x86 aint what it used to be (3, Insightful)

mike260 (224212) | more than 10 years ago | (#9404209)

I have very fond memories of writing pentium-optimised asm...the rules were complicated enough to make things interesting, but still comprehensible.

Nowadays, the x86 ISA is just an API...god knows how the core actually executes instructions and in what order, which makes it very hard to optimise code beyond a certain point. You get more mileage from optimising memory access patterns and doing other such dull, dull, dull work. I get my asm coding fix elsewhere nowadays.

OS using assembly (1)

zymano (581466) | more than 10 years ago | (#9404211)

Checkem out.

menuetos []
Unununium Operating System []

Nasm is the portable type assembler. Pretty cool.

mother of OOP (0)

Anonymous Coward | more than 10 years ago | (#9404214)

just try to code assembly without functions. :)

uControllers + Assembly = Fun (1, Interesting)

Anonymous Coward | more than 10 years ago | (#9404220)

Got my education in mechanical eng. once upon a time but was able to take a course on uprocessor applications and then ucontrollers (8bit) for robotics. No high level language here. Just straight Assembly code to fit in 32K of memory. You'd be surprised how much you can fit in there. Programs were fast and had to be efficient and I learned alot about architecture, as much as a mech eng could of course.

It's tough to do well on some architectures (1)

tommasz (36259) | more than 10 years ago | (#9404225)

Assembly is a great idea when speed and compactness is necessary, but it's tough to do it well on some processor architectures, RISC in particular. A well-tuned compiler backend for those can probably out-code most (but not all) humans - and the more registers you have to keep track of, the bigger the gap. But even CISC (or CISC-like) architectures can be problematic. Consider branch prediction, to cite one example. As much as I loved getting down to the "bare metal" on the 6800 and 68000, I'm glad I can use something else today.

Obvious qdb reference (4, Funny)

revmoo (652952) | more than 10 years ago | (#9404228)

How does an assembly programmer commit suicide?
goto cliff


The problem with assembly... (5, Insightful)

jafo (11982) | more than 10 years ago | (#9404239)

Quoting: "the best implementations are written by those who've mastered assembly language".

I haven't read this book, but I'd hope that there would be some pretty good justification of the above statement. I suspect that it's not, though. First of all, who defines what the "best implementation" is?

As Knuth says, the first rule of program optimization is: "Don't do it". Trying to optimize a program when you're writing it leads to all sorts of problems including difficult to maintain code, increated time and budget required for the project, and often it's not even a hot spot anyway.

I used to be very concerned about using making my code fast, but have (over the decades) decided that making it obvious is much more important than speed, particularly in the initial implementation. Profiling allows you to concentrate on the 20% of the code that the program is actually spending 80% of it's time in, instead of guessing where the hot spots are going to be.

I've found that another benefit of using simpler code is that I'm more likely to throw away whole sections of simpler code and try radically different algorithms or mechanisms. More complicated code I find I'll try to just tweek instead of dumping wholesale. Randically different approaches can lead to 10x speedups where tweeks of existing code may give you 2x speedups, if you're lucky.

Don't get me wrong, I'm all for trying different approaches. I'm not sure I would have come to the same conclusion I have now if I hadn't spent quite a long time trying to write optimized code. It was a very different world back then, but I know I wasted a lot of time optimizing code that didn't at all need it. It was an experience though.


How can learning assembly not be mind expanding? (1)

exp(pi*sqrt(163)) (613870) | more than 10 years ago | (#9404241)

It's a different paradigm for programming. Every paradigm opens up new ways of developing software that can be applied to other programming languages.

Even if you never write a single line of assembly in your life there are times when you might need to understand the concepts - for example you might need to embed an interpreter for a language in your software and use a virtual machine. Before you do that it might be a good idea to know how people have designed real machines.

because.... (-1, Offtopic)

n4KdR4zr (138966) | more than 10 years ago | (#9404253)

its teh hardcore mad l33t. d00d.
goddamn that doesn't even make sense.

On a more serious note, it's also a great way to get laid. Duh.

"Take me now you l33t stud"

How are you supposed to pronounce the numbers anyway? I generally just throw them in the middle of words like "duh zero zero duh I we - sixteen - nt to the st - zero - rrr today" but my friends just give me strange looks.

My friends look at me funny no matter what I do anyway. It pisses me the fuck off. They just kind of sit there on my couch and stare at me kinda kreepy like for weeks at a time, untill the nieghbors start to complain about the smell. That's when I know its time to make soup. Mmm soup. Soup. Lots of soup. Soup.

Soup is almoast as much fun as sex, but it tastes better.

You can even take that quote and tell it to all [i]your[/i] friends and pretend you made it up yourself and have them laugh and laugh and laugh and think o what a clever guy he is, and I won't care, I'll just smile at you magnaminously and think attaboy sport i love you, almost as much as i love soup, but not quite as much as that because I don't love anything as much as i love soup except maybe sex which still isn't quite as good as soup, but is better than you. I'm a nice funny generous caring guy like that. You should get to know me. Come over some time and we'll have sex and make some soup. Itll be a great time. O yeah

The bottom line is I didn't have any friends or sex or soup untill I learned assembly and now I have all three. If thats not enough of a reason to learn than I don't know what is.
Will get naked for karma.

Learning Asembly from Hyde made me a better coder (2, Insightful)

John.P.Jones (601028) | more than 10 years ago | (#9404259)

I learned Assembly language programming from Randall Hyde using his monster tome (available online for free and in print) the Art of Assembly Language Programming.

What Randy Hyde taught me is that it is important for a beginner programmer to quickly learn what kind of instructions the high level code you write is being translated into, how basic machine organization works and how the compiler and OS figure into running your code. Writting Assembly is no longer important (thank goodness) however the process of LEARNING how to write Assembly is a crucial step in a well rounded CS curriculum.

When Randy Hyde taught x86 Assembly to us at UC Riverside it was the toughest lower-division class and the weeder for the people who shouldn't be computer scientists. Without that core people are making it to upper-division and performing very poorly in OS, compilers and architecture.

What I Learned From Assembly... (2, Funny)

Prototerm (762512) | more than 10 years ago | (#9404265) not to fear Binary Arithmetic. It's just like regular arithmetic -- if you're missing 9 fingers.

The fact... (1)

the_skywise (189793) | more than 10 years ago | (#9404269)

That somebody has to write an article to state this obvious point shows the sad state of programming that the 90's guerilla engineering training has brought us.

(You too can earn a 6 digit salary in computer programming after our simple 2 week course that guarantees certification!)

Knowing assembly is good (1)

Maljin Jolt (746064) | more than 10 years ago | (#9404272)

In past years, I noticed people who learned assembly previously are usually good C/C++ coders. I believe this is because knowing what machine really does at it's instruction level helps to imagine how it should be written in higher language. It is sad that Java and C# exists just because former visual basic people can't grasp a concept of a C pointer.

What makes assembly superior is a hardware where resources such as memory or cpu speed are very scarce: embedded devices. Microcontrollers. Either you need less energy, either you stuff there more functionality, in critical systems that counts.

Myself I began my coding experience on Z80, typing instructions on hexpad. Using own mind as an assembler, to this very day I remember 00 is a nop, C3 is jmp and C9 is a ret. Being able to do hex subtraction in head brought me great popularity in my first job, where reading cobol dumps from Univac mainframe was common daily task for programmers, usually trained in "higher" language only.

Even today, unlike bugs in other software, compiler defects could be found only with a good understanding of assembly language.

Assembly won't make logic die out (1)

Wienaren (714122) | more than 10 years ago | (#9404275)

Assembly will educate your logic and your ability to think like the very machine does. Compilers, in the long run, just fade out that close feeling for effective code and noone - ever - can convince me that a compiler can optimize code better than a good assembly programmer. Being an assembly junkie myself, having won all benchmarks ever, still dreaming about the CPU cycles saved when using a moveq instead of move.l, I think assembly never will die out. SMON, where are you. And O.M.A., I hope you rest in peace.

I program in assembly every day. (1)

the_rajah (749499) | more than 10 years ago | (#9404277)

It's still the best way to produce a program that runs fast and with minimal resources. I wrote my first assembly language program in 1964, probably before a lot of you folks were born. The bulk of my assembly language programming has been for various microprocessors going back to the Fairchild/Mostek F-8, a horrible chip set, but it worked and was relatively cheap at the time (1976). I've done a lot on 8085 and 8051 systems for agricultural control systems and elevator (vertical transportation) controllers which are still supported some 20 years after they were first designed.

If you understand assembly language, then you understand the intimate details of the system you are programming for.

"Do the Right Thing. It will gratify some people and astound the rest." - Mark Twain

knowing how the machine works if valuable (1)

jay2003 (668095) | more than 10 years ago | (#9404278)

Computing is all about layers. To be really good at the layer you work at, you need to know something about the layers above you and the layers below you. For C/C++ programming, this means having an understanding of assembly and how the operating system works. I've seen many bad implementations when progammers did not understand the consquences of what they were doing.

PowerPC assembly? (1)

An Anonymous Hero (443895) | more than 10 years ago | (#9404281)

The first milestone I achieved was the release in the mid-1990s of the electronic edition of The Art of Assembly Language. This book, along with the use of the accompanying UCR Standard Library for 80x86 Language Programmers, reduced the effort needed to learn assembly language programming.

OK, is there (should there be?) anything like this for PowerPC assembly? I'm aware of these web pages:

...but neither seems to mention anything quite comparable to Hyde's book.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>