Follow Slashdot stories on Twitter


Forgot your password?

Is Assembly Programming Still Relevant, Today? 676

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? "
This discussion has been archived. No new comments can be posted.

Is Assembly Programming Still Relevant, Today?

Comments Filter:
  • Yes. (Score:3, Insightful)

    by bladx ( 816461 ) on Thursday March 22, 2007 @07:28PM (#18451677)
    It's good to know how things work underneath the hood.
    • Re: (Score:2, Insightful)

      by fm6 ( 162816 )
      Looking at assembly code tells you very little about how modern software systems work. Any more than sheet metal fabrication tells you how an airplane works. Ever hear the expression "can't see the forest for the trees?" With assembly language, you're focusing on the individual leaves!
      • Re:Yes. (Score:5, Interesting)

        by A nonymous Coward ( 7548 ) * on Thursday March 22, 2007 @08:24PM (#18452407)
        I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.

        (For the ignorant, it takes two string pointers and copies the second one to the end of the first one; this requires zipping all the way from the start to the end of the first string to find where said end is. It then helpfully returns the pointer to the beginning of the first string, the very parameter you passed in. Never mind that the new end of the first string would be very handy for the next strcat to that same string.)

        This programmer is generally good at what he does, but the idea that strcat is woefully inefficient is not obvious to him. Even after explaining it to him, yes he will avoid it, but he does not really understand why. He, and far too many other programmers, measure their program's "speed" in lines of code. Sure, they know that a subroutine call has to count those subroutine lines of codes as well, but they simply have no concept of the fact that some operations take longer than others, that there are better ways of doing simple things.

        I think every beginning programmer should have to spend a semester on some funky old z80, for instance, all in assembler, debugging in machine language, before they can call themselves a good programmer. The idea is not to get them skilled in z80s, but to give them a basic idea of how computers work.

        It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.
        • Re:Yes. (Score:5, Insightful)

          by Lehk228 ( 705449 ) on Thursday March 22, 2007 @08:48PM (#18452683) Journal
          i agree that everyone should have decent understanding of what's going on behind the curtain, though rather than focus on the what, i would prefer to see more experience with limited environments.

          as in your example, too many people code like the only platform is the multi-GHz PC.

          even a year doing tools in Graphing calculator basic will teach appreciation for not wasting cycles doing everything the lazy way, 'cause sure, you usiung strcat doesn't slow the system in a noticable way, but when half the processes running are using it, and using it in "hotspots" suddenly you need a new machine because it's just not fast enough.
        • Re:Yes. (Score:5, Insightful)

          by thecheatah ( 977630 ) on Thursday March 22, 2007 @10:07PM (#18453413)
          Wow, the first programming language I learned was z80 assembly :-). I use to make games for the ti86.

          here is a side scroller i made written all in assembly (includes animated screen shot)

 23280.html []

          The things I learned:
          1. 4mhz processor is REALLY fast!
          2. How the stack works.
          3. How absolute and relative jumps work.
          4. How to create "objects" and implement "methods"
          5. How the smallest variable, the register works.

          I have to say that after making games in assembly, I am actually disappointed in how well the current consoles handle them. I would expect them to be able to crazy things with the hardware they are given. That is also why I am interested in the ps3, it forces programmers to understand the underlying hardware.

          • Re: (Score:3, Interesting)

            I agree that console programmers probably aren't pushing their hardware as hard as possible- unlike PC programmers, they have the luxury of having the same equipment in every unit, so they really don't have an excuse not to learn the system's assembly at least enough to squeeze a few extra cycles out.

            Out of curiosity (i'm not trying to troll here), what about the PS3 makes programmers understand the hardware better than they need to understand the 360 or Wii hardware? I know they have the Cell Processor,
        • Re: (Score:3, Interesting)

          by grasshoppa ( 657393 )
          You are both right and wrong, in a sense. You are right that he should know what's going on under the hood. You are wrong in that he shouldn't use it. Program execution speed should ( almost always ) take a backseat to code readability. If the organization uses strcat, there is a very strong and valid argument why he should still be using it.
        • Re: (Score:3, Informative)

          by vux984 ( 928602 )
          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
        • by davidwr ( 791652 ) on Friday March 23, 2007 @12:52AM (#18454769) Homepage Journal
          In most programs, easy-to-read, easy-to-maintain code is worth a size and speed penalty of up to several times that of hand-optimized assembly code, and it's almost always worth a 0-50% penalty.

          This is particularly true for programs that
          • don't need to be shoehorned into memory or onto disk
          • spend most of their time waiting, not running

      • Re: (Score:3, Insightful)

        by BillyBlaze ( 746775 )
        Could you design an airplane without a basic knowledge of sheet metal fabrication? I think not.
      • Re: (Score:3, Insightful)

        by ivan256 ( 17499 )
        I hate to tell you but pretty much every "modern" system has components that are written in assembly. Some of us still know how to write low-level software, and that's a good thing, because otherwise all of your fancy "modern" languages wouldn't have a system to run on.
    • Re:Yes. (Score:5, Insightful)

      by smallpaul ( 65919 ) <paul.prescod@net> on Thursday March 22, 2007 @10:04PM (#18453399)
      My philosophy is that you should know the layer beneath the layer you program on. Let's say you're working on Groovy code which is half-interpreted and half-compiled on a JVM which is written in C, perhaps using JIT or perhaps not, running on a CPU. Nothing that you can possibly known about how registers work or how jumps work will help you to understand the performance of your program several layers up -- especially given that your program will run on several different runtimes optimized in several different ways on several different CPUs.

      But if you're going to program in Groovy then you should know Java and perhaps JVM IL. If you're going to program in C then you should know assembly. If you're programming in assembly then you should know about how CPUs will reorder your instructions etc. If you're building a CPU, then you'd better know physics.

      I really don't think that if you're writing an app in Rails/Javascript/SQL you are going to achieve any performance or debugging benefits by understanding assembly language. It's just knee-jerk to say that every programmer, no matter what they do day-to-day should be knowledgeable about assembly. The same effort expended learning about the layer UNDER your development environment would have a much better payoff. E.g. a Javascript programmer reading the Firefox source code (or at least benchmarking FireFox and IE on important operations). With each level deeper you go, you achieve quickly diminishing returns.
  • by madhatter256 ( 443326 ) on Thursday March 22, 2007 @07:29PM (#18451689)
    Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
    • Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
      In theory, you could just make your higher-level programming language's compiler emit C or C-- [] and then let the maintainers of GCC and other mid-level language compilers do the dirty work for you.
      • Re: (Score:3, Informative)

        by Surt ( 22457 )
        A lot of languages these days are emitting java .class (binary) and letting the VM do the work.
    • by KokorHekkus ( 986906 ) on Thursday March 22, 2007 @07:51PM (#18451999)

      Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
      To create - yes. To use as a programmer - no. You can still be a good programmer if you know the cost (in terms of resources) for the operations you choose to make use of. A higher level language will most likely give you a wider range of ways to solve a problem within the given limitations. But only if you actually know the computational characteristics of the system (as a whole) that you are using. Simply put you need to realise which operations are expensive and which are cheap from a total perspective.
      • Exactly. You don't need to be fluent in x86 assembly, but if you're completely ignorant of the inner workings of computer architecture, you're at a disadvantage to those who have been exposed to it and written, say, a bit of old MIPS assembly code.
    • No. You only have to generate code for another already-existing compiler. For example, this is how people use f2c. You can also write compilers that generate bytecode (some LISP compilers do this, as do many Java compilers).

      Now, if you were to ask "isn't knowledge of assembly language for a given microprocessor required to create a compiler capable of directly generating native code?" then the answer would be yes, because all the other possibilities have been excluded. Alternatively, if you asked "isn't q

  • by QuantumG ( 50515 ) <> on Thursday March 22, 2007 @07:30PM (#18451701) Homepage Journal
    Please remain ignorant of all lowlevel details of your deployment and development platforms.
    Please continue to treat both computers and the tools you use to program as magic black boxes.
    That way old dogs like me will still have a job.
    • Re: (Score:3, Insightful)

      by LionKimbro ( 200000 )
      Yes; Understand too, how the gates work, all the details of how the chips work, (the myriad chips your program may run on,) and have a good understanding of quantum mechanics, as well. Understand all the business supply chains, as well.

      Anything else, is just-- pshaw... Black boxing it.
  • Learning assembly programming is not terribly useful. Learning assembly language, however, is very useful. Reverse-engineering and debugging both make use of disassembly, and especially in vulnerability analysis, exploit writing, compiler writing, and similar fields, knowledge of assembly language is often critical. Assembly programming is only useful for optimizing short bits of functions, and it's my understanding that it doesn't help much or often.
    • by dgatwood ( 11270 ) on Thursday March 22, 2007 @07:51PM (#18452003) Homepage Journal

      That's a pretty fine line there. If you can understand asm well enough to debug such issues, I would argue that you also probably know enough to write it, or at least very nearly so.

      I would say that you need to know how to program in assembly language, though it doesn't really matter much which ISA you use---MIPS, x86, PPC, ARM, whatever. What matters is the ability to understand what's really happening at a low level so that you don't do stupid things in high level code that cause your machine to have a seizure.

      For example, once you understand that your CPU only has a limited number of registers, you'll understand why (on some CPU architectures) it is a good idea to limit the number of function arguments so that they can be passed via registers, and that you should put the arguments that you are most likely to use at the beginning of your prototype so that they have the best chance of already being in a register.

      • I've found that there tends to be quite a bit of difference between disassembled code and written assembly. Assemblers provide lots of features like labels and subroutine names that aren't found in disassembled code. Not only that, but you usually only have to be able to read disassembled code, which is generally easier than writing it.

        I like that example at the end, by the way. Very neatly sums up the good things about understanding low-level function.
  • by zeromusmog ( 260817 ) <> on Thursday March 22, 2007 @07:30PM (#18451709) Homepage
    Nobody has to learn assembly language anymore to create piddly things like compilers or program ultra-small devices or anything like that. You can do all of those things with Ruby on Rails now.
    • You laugh, but there are microcontrollers programmed in BASIC now. Sounds nice on the surface, lets kids get into programming and home users more easily create electronic devices, right? Unfortunately, the intro to electrical engineering course at Duke University trains kids in their use. The future of electrical engineering in America is people who program microcontrollers in BASIC. Isn't that a nice thought?
      • Re:easy as 1 2 3 (Score:4, Interesting)

        by FlyByPC ( 841016 ) on Thursday March 22, 2007 @09:38PM (#18453157) Homepage
        Not all of us. I'm majoring in EET/ComET at ODU (they didn't offer the pure EE via distance-learning) -- and we're required to learn PIC assembly at least.

        Granted, PICs are much MUCH simpler than anything running a modern OS -- but learning assembler, even on a simple device like a PIC, does teach a lot about how hardware and software integrate. Also, it's kind of cool to know that (for example) exactly 1,000,000 clock cycles after the program starts up, it will be calling *this* instruction, which moves the value in the accumulator to *that* register.

        I can't be the only one out there who finds this extremely refreshing after taking a course in Java (and learning about font objects, GridBagLayouts, and other things so far removed from "real" programming that they might as well call it a Fine Arts course), can I?

        Anyway, I wasn't really looking forward to learning Assembler -- until I got started and saw how powerful, elegant, and just plain beautiful it really is.

        PICs are cool toys -- 5MIPS ain't much compared to the latest and greatest Intel and AMD have to offer -- but when you consider that they'll run for days (weeks? months?) on a CR2032 cell, and cost under a buck apiece, they're very impressive. (Freescale MCUs, too -- although I don't yet know those quite as well.)
  • Making an accounting system why would you care?

    On the other hand I find myself needing to break into assembly once or twice a month - but I do embedded systems of one type or another

  • by CosmeticLobotamy ( 155360 ) on Thursday March 22, 2007 @07:31PM (#18451723)
    For good programmers, yes.
    • by Bogtha ( 906264 ) on Thursday March 22, 2007 @09:17PM (#18452979)

      I don't think that's the case. It really depends on what you want to do. Typical desktop applications don't need any assembly language, nor in-depth knowledge of how the CPU works. In fact, it's probably a bad thing to worry about things like this — premature optimisation being the root of all evil and all that. You don't want to put a lot of work into making your application 1% faster and then realise you've ruined your portability.

      In fact, these days, there's a case for even doing away with languages like C for a lot of desktop applications. With the speed of today's computers, if you can write your application quicker in a scripting language, it's a worthwhile trade-off for many organisations.

      Sure, if you want to work with operating systems or things like games where performance is critical, then knowing assembly will make you a better developer even if you don't end up using it. But most of the software industry is working at a level far higher than that, and if you are at that level and making your decisions based on what instructions the CPU is getting, then you're probably doing a worse job than somebody who is entirely ignorant of assembly.

    • by sterno ( 16320 ) on Thursday March 22, 2007 @09:49PM (#18453233) Homepage
      Frankly I think a good programmer is somebody who writes well documented and designed code. I don't think somebody's knowledge of the low level assembly programming necessarily helps with that. I'd rather somebody wrote somewhat inefficient code that I could read and, as needed, optimize, then have some spaghetti pile that nobody could understand but was lightning fast.
  • Yes. Even today, the popular libavcodec library (often seen in Codec-Packs) still has plenty of ASM code poured into it to make it faster.

    ASM code is also especially important if you are programming for a more limited platform, such as a GBA or Nintendo DS. ASM code can often be four times the speed of C code.
    • What you mention is spot on, but there's a specific reason that it's faster to do this. With the various multimedia ISA extensions, which are typically instructions designed to work with small vectors of 3-4 elements, nice speedups can be obtained... However, this functionality is not exposed in high-level programming languages, and it's usually not going to be generated by a compiler, either.

      Also, look at linear algebra libraries. They also use these short-vector instructions deep within the kernels. T
  • by Bin_jammin ( 684517 ) <> on Thursday March 22, 2007 @07:34PM (#18451753)
    Hire someone else to code in assembly.
  • Yes (Score:5, Informative)

    by Erich ( 151 ) on Thursday March 22, 2007 @07:34PM (#18451779) Homepage Journal
    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.

    • by jonatha ( 204526 )
      there are many people who would like to hire you. Including the group I work in.

      So when do I start?

  • Honestly... (Score:3, Insightful)

    by CyberBill ( 526285 ) on Thursday March 22, 2007 @07:35PM (#18451801)
    You really only need to know how to program assembly if you want to be a good programmer. If you want to be a crappy one, learn Java or C#, pretend pointers are magical, and be happy with your life. (I'm not saying those are bad languages, I'm just saying they're opposite from assembly)

    Also, a lot of embedded work is still done in assembly because with a lot of low-level industrial work having very precise clock-counts on everything is very important.
    • Re: (Score:3, Informative)

      by Lehk228 ( 705449 )
      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.
      • by tlambert ( 566799 ) on Thursday March 22, 2007 @10:49PM (#18453815)
        Answer to "What's hard about pointers?"...

        There are people who cannot grasp the difference between "a thing" and "a respresentation of a thing". In fact, there was an entire century where almost the entire school of French philosophers were unable to grasp that there was a difference.

        For pointers, it comes down to realizing that a pointer to memory is not the memory, it's a representation, and the real memory lives somewhere else: at the dereference of the pointer. And at that location it takes up real space. And so does the representation (but it's comparatively tiny).

        The ability to make this disctinction comes naturally when you've written assembly code of any complexity, since you've had to manage the memory yourself. But if you've never done that, or, worse, you've only ever programmed in languages which eschew pointers and try to pretend that their own internal implementations don't use them, even if they won't let you use them, well, then, you've got a conceptual problem. An that conceptual problem is going to be very hard for you to overcome.

        It also makes it very, very hard for someone to understand row-major vs. column major languages, or how you would link a program in one against a library in another, and be able to usefully communicate your data between the two. Or it makes it hard to understand the difference between "call by value" and "call by reference.

        If I'm interviewing someone, and it becomes clear that they need a "code interview" because some things don't add up between their banter and their resume, the first thing I whip out is a pointer problem.

        -- Terry
        • Re: (Score:3, Informative)

          by 4D6963 ( 933028 )

          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.

  • Very relavent (Score:5, Insightful)

    by Forrest Kyle ( 955623 ) on Thursday March 22, 2007 @07:38PM (#18451831) Homepage
    Well, given that the world runs on embedded systems, and will probably become more reliant on even greater numbers of even more complex embedded systems, I'd say assembler will be around for quite a while. However, in terms of game programming or something, it's probably not amazingly useful any more. It is my understanding that most of the API calls to advanced graphics libraries are about as optimized as they are going to get. Clearly you don't need it to write a medical billing application.

    I would not encourage universities to start pumping out CS graduates who have never seen assembly laguage, and don't expect it to phased out of the average Electrical Engineering curriculum any time soon.

    Frankly, I don't think it's a very good question. It's sort of like saying, "Given that we now have calculators and computer algebra systems that will do the math for us, is it really worth it to waste students' time learning the nuts and bolts of mathematics?" It has been my (limited) experience in software engineering that knowing how something works on a deeper level will almost always be an asset, and at the worst have no effect at all.
  • Glad I did (Score:5, Interesting)

    by linuxwrangler ( 582055 ) on Thursday March 22, 2007 @07:39PM (#18451843)
    I'm glad I took assembly. I've never "used" it in the traditional sense of writing an application other than in school, but understanding how things work "under the covers" (whether at the CPU, hard-disk or network level) has provided valuable guidance in day-to-day design and troubleshooting.

    I've worked with people with very focused high-level programming skills and found that while they could write mostly decent code, their code was also most likely to fail in production since they were completely mentally removed from concepts like disk-seek times or bandwidth constraints. Programmers with a deeper understanding of what actually happened when their code ran tended to make wiser programming choices.
    • I've worked with people with very focused high-level programming skills and found that while they could write mostly decent code, their code was also most likely to fail in production since they were completely mentally removed from concepts like disk-seek times or bandwidth constraints.

      I'm not a great programmer, but I've always had a good "sense" (for lack of a better word) about technical things. I worked a bit at a company doing mid to high level (V)FoxPro programming. They put me on the least desi
  • by softwaredoug ( 1075439 ) on Thursday March 22, 2007 @07:43PM (#18451897)
    One day won't there be little nanobots floating around with 512 bytes of memory and a 1 mhz processor that need to buzz around your body and eat up your precancerous cells? I imagine as things get smaller, the miniturization fronteir of computing nescesitates limitations in computing power and memory. This may necesitate a new generation of assembly programmers. Even today in the minituarization/embeddedness/realtimeyness world where many enjoy programming away in plain old C (like me) that knowing assembly is useful. First to look at the compiler's output and figure out what the hell its doing, second to just have a plain basic understanding (not necesarilly a detailed one) of what your C statements/operations/etc is probably turning into in assembly instructions.

    Another question, would assembly be more popular if it wasn't such a nightmare to write for Intel's x86 architecture? If we all had nice Motorolla PCs, would assembly be really cool?
    • Erk (Score:3, Funny)

      by Fross ( 83754 )
      One day won't there be little nanobots floating around with 512 bytes of memory and a 1 mhz processor that need to buzz around your body and eat up your precancerous cells?

      Now I'm picturing something like Alfred Hitchcock's The Birds, only with ZX81s.
  • Vote by replying with the following choice subjects:

    Yes, assembly rocks.
    No, assembly is stupid, old and out-dated.
    I married assembly, you insensitive clod.
    WIPO: (for example, I like to wipe asses with assembly.)
  • Yes (Score:5, Insightful)

    by Starji ( 578920 ) on Thursday March 22, 2007 @07:44PM (#18451911)
    Do you write drivers? Or do you need highly optimized algorithms? What about really low level firmware stuff?

    In other words, yes, there are good reasons for knowing assembly. Whether or not you'll actually use it is another matter entirely. Just depends on what you're working on.

    Actually I wouldn't be surprised if in about 10-15 years assembly programmers are in higher demand since none of the CS schools these days ever teach assembly anymore.
  • Definitely (Score:2, Interesting)

    I just got a SDK-86 to start learning it!
  • by grub ( 11606 )

    How do compilers know what to compile to? Magic? Imagine if all the assembly programmers died: who'd maintain & update compilers, embedded devices, many realtime instruments, etc. ?
  • If you don't plan to program in assembly language, but you'd like to learn what it's all about, just find one of the many introductions on the web and read it. There are no profound concepts to learn and nothing complicated to understand (unless you want to get into the details of virtual memory or exactly how multiple simultaneous interrupts are handled). You'll have it figured out in an afternoon. You won't be an expert, but it sounds like you've no need to be one. This is a short enough time that it's re
  • YES! (Score:5, Informative)

    by Bluesman ( 104513 ) on Thursday March 22, 2007 @08:05PM (#18452111) Homepage
    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! (Score:5, Informative)

      by Cyrano de Maniac ( 60961 ) on Thursday March 22, 2007 @09:50PM (#18453245)

      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.


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

    • The C Conspiracy (Score:4, Insightful)

      by jd ( 1658 ) <> on Thursday March 22, 2007 @09:51PM (#18453265) Homepage Journal
      There really isn't a language called C. It's just a bunch of assembler macros. :)

      Seriously, assembly is important for all the reasons you noted, but also for some others. If you know assembly, the chances are:

      • You know how to design the software, because you got sick of trying to debug in a disassembler
      • You know how to express the design cleanly - unclean assembly is longer, so takes more effort, and is murder to debug
      • You know how to add structure to the code, as it's easier to test and fix a small subroutine than a gigantic blob
      • You know how to avoid unnecessary structure, as exploding stacks is generally not a good idea
      • You know how to re-use code, as it is pure hell to repeatedly reinvent anything in assembly

      All software engineering, computer science and programming courses should start by requiring people to program a non-trivial application on an ARM processor, or something with an equally limited instruction set, in pure assembly. Why? Because then you get people who think, who program with care and forethought, who think of bloat not in terms of adding more RAM, but in terms of opportunities for bugs, glitches and gremlins. Sure, you'll get more dropouts. The computing world doesn't need more code monkeys, so it's no loss if they did. Who needs a society of half-baked, semi-literate coders?

      This is not elitism, because I'm not saying that anyone should be excluded from the profession. I don't think they should. What I do think is that society needs to make damn sure that the typical coder isn't the worst coder, which is what you get if people are trained to NOT think but to let the computer do the thinking for them. Windows may act like a HAL-9000 at times, but trust me, it isn't remotely capable of anything resembling thought. A bad design or a poor implementation will not be rectified by some magical intelligence in the machine, because there isn't any.

  • Does a web developer need to know HTTP? Does a network programmer need to know the details of TCP/IP? Does a Window's application programmer need to know the ins and outs of the WIN32 API, event handling, processes, threads, handles, GDI, DirectX and others? Does a Flash programmer need to know anything about the SWF file format?

    In general, does any programmer need to know low level details of the technologies they use given that they have high level libraries and abstractions to work with? The answer,
  • I'm a computer engineering student in our second year (share the year with EE,E,COMMS,ROBOTICS) we had to program a 8031 ( it taught me alot on how a Microprocessor and Microcontroller works, this year I've done a software programing module which was a breeze because I'd been forced to learn proper memory management had already delt with concurrency, interupts and other little tricks OS's do.

    Also this year we've been learning VHDL those of us who worked hard l
  • ... for the additional insights. It is also relevant if you plan to work on a small embedded platform were the size and speed gains may be huge. THe insight especially will allow you to understand advanced stuff. Granted, with the quality of most code produced today, obviously most programmers do not have the additionsl insights you can gain from using assembly language. But then, most programmers seem to even fail at basic algorithmics.

    It you take pride in your skills and want to refine them, lear one asse
  • One thing... (Score:3, Informative)

    by petrus4 ( 213815 ) on Thursday March 22, 2007 @08:25PM (#18452419) Homepage Journal
    ...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 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 [] 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 [], which is an entire (small) OS including GUI written completely in either 32 or 64 bit asm.
  • While I have not written any assembly since college, I am really glad I know it. As an engineer who works in C/C++, sometimes it is really helpful in debugging to see what is happening at the assembly level.

    So, I would definitely recommend at least being acquainted enough with assembly so that you can semi understand a listing.
  • I've said it before: the lowest code owns. Also true: he who codes the lowest owns.

    See Reflections on Trusting Trust []. It should be required reading of every programmer.
  • by starseeker ( 141897 ) on Thursday March 22, 2007 @08:43PM (#18452609) Homepage
    I have always wondered what would have happened if the idea of using Lisp as the assembly language of a machine had actually taken off. If I understand the Lisp machines correctly, they were actually "lisp on the metal". Given the flexibility and power of the lisp language it would have been very interesting to see what the evolution of the Lisp Machines would have been, had they proved viable in the long term.
  • by Distan ( 122159 ) on Thursday March 22, 2007 @08:44PM (#18452619)
    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.
  • by quantaman ( 517394 ) on Thursday March 22, 2007 @09:50PM (#18453249)
    I realize that assembly is very useful to know and can be useful in certain instances.

    But writing in assembly has always given me the same feeling as eating rice with a single chopstick.
  • by DoctorPepper ( 92269 ) on Thursday March 22, 2007 @10:21PM (#18453569)
    Communicating in Morse code. It's a pain in the ass to learn, but when you do, you find the rewards more than justify the effort spent.

    Also, it's good to remember that Assembly language is just one more tool in a programmer's tool box. I wouldn't write throw-away scripts in Assembly language, just like I wouldn't use C. I'd probably use Perl, Python or shell script, as necessary. When you need to hand-tune that algorithm to get that last little boost in performance, being able to drop down to Assembly language can save the day. Too bad it is a dying art.

    On another note, I agree with the other posters that said learning Assembly language allows you to learn the hardware better. 8086 Assembly language was my second language (after BASIC), and I used it for several years, until I started using Windows and found it was much easier to write a Windows program in C :-)
  • by nadador ( 3747 ) on Friday March 23, 2007 @12:01AM (#18454427)
    As a marketable skill, assembly won't get you anywhere. There are a handful of places were knowing a specific assembly language is a prerequisite (boot loaders, deeply embedded applications, etc.) but these are just a fraction of the overall job-space for software engineers. Most software engineers never mess with assembly; they are, in fact, afraid of it and think that it's evil.

    Given all of that, assembly language *is* the hardware/software boundary. It's where all of the fancy abstractions from CS dissertations meet reality. Understanding computer architecture is a huge asset as a software engineer, and to properly understand how software and hardware interact, you have to learn at least one assembly language. There is no alternative. For most people, it is an unpleasant experience, but the payoff is enormous. The learning process that you undergo while learning assembly will change the way that you see your software and will help you understand why your code is so slow and how to make it fast by design.

    I have one last point. When you tell a potential employer about the low-level stuff that you know or work that you've done, your assembly skills are a proxy for understanding how hardware works (at least to interviewers with half a brain). If their software needs to run fast, they'll be happy that you understand the deep magic of hardware.

    (Incidentally, I think that the fraction of software jobs that require an understanding of hardware and knowledge of assembly languages, linker internals, etc., are the only fun ones and the only ones worth having. So I learned MIPS, ARM, PowerPC, and TMS320C6 assembly, and they have all served me very well because I don't have to refactor C# for a living.)
  • by Alioth ( 221270 ) <no@spam> on Friday March 23, 2007 @06:46AM (#18456291) Journal
    I'm building my own computer (no, not getting some random PCI cards and plugging them into a motherboard), but designing a simple Z80 system for fun.

    If you want to mess around with this sort of thing, you cannot avoid writing things in asm. I've got this far: -Project-Pages/Image19.html []

    - having laid out a double sided PCB, and got everything shoehorned onto a 160x100mm 'Eurocard' sized motherboard.

    However, I've also retargeted the z88dk (Z88 Development Kit, originally designed for the Cambridge Z88 portable computer) to my Z80 board because while it'll be best to have all the low level stuff done in assembly language, writing things that use floating point will just be ten times faster to write in C.

    But even if you never intend to hack hardware, it's still important to at least be familiar with assembly language - if only to know why unchecked buffers are bad. If you've ever written a program in asm and accidentally overwritten the stack and tromped all over your return address, you fundamentally understand why this is a bad thing. We've got into a whole world of hurt because many programmers didn't understand this.

We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission