Are there major differences between assembly language and higher level languages when it comes to coding and/or managing projects? Obviously it takes more statements in assembly language to carry out a particular operation than in most other languages, but are there differences that affect how a project needs to (or should) be run based on targeting assembly language (specifically x86/x64 assembly language)?

To the extent that there are differences between assembly language and other languages, it seems reasonable to guess that at least some of these are advantages for the other languages. Can anybody point out specific disadvantages of assembly language, and ways to mitigate those disadvantages?

One specific example would be staff availability. Has anybody had trouble finding experienced assembly language programmers, and if so, what steps can be taken to mitigate this problem?

  • Why would anyone write a complete project solely in assembly language today? Or are you asking about a mixed-language environment, which is how assembly is typically used today? Jul 25, 2011 at 21:07
  • 6
    Note that there are areas of non-[PC|web|enterprise] programming, where Assembly is predominant or very popular. I'm talking micro-controllers, industrial automation or robotics. Sure, there are high level languages in these areas too, but you see Assembly a lot.
    – Mchl
    Jul 25, 2011 at 22:05
  • 1
    @Mchl: Aren't these projects made in C (or even C++) and possibly assembly? I would have guessed that it's very uncommon to use assembly exclusively. Jul 31, 2011 at 18:14
  • 1
    Actually in industrial automation you can meet a whole branch of languages that simply do not exist outside of that field. Part of that comes from differences in hardware (Harvard architecture as opposed to von Neumann architecture we're so used to). as well as from history of making these controllers accessible for electricians, who were used to work with switches and relays. That's how LD (en.wikipedia.org/wiki/Ladder_logic) come into existance, which is actually a graphical interpretation of assembly. See the linked article for some more languages used in automation.
    – Mchl
    Jul 31, 2011 at 21:02
  • 2
    I've got a small installer that I support now that's in assembly. It was as easy to write in assembly (with Windows API) as anything else, so why not? I've also got a credit card swiper interface written in assembly. Started in high level languages, but had so many difficulties getting it to work that I rewrote in assembly to get better control of all the bits flowing... Jan 14, 2014 at 19:23

6 Answers 6


Yes - but not often.

In one sense, assembly is really just a proxy for machine language, so of course you can do anything in assembly that you could with a higher level language.

The opposite is not always the case. For instance, a few years ago, I worked on an ARM CPU that had some funky opcodes for changing graphics states that could only be used from kernel mode. They would have no direct equivalent in a higher level language, and I'm sure the function in the Linux kernel driver for changing those states included some assembly.

On microprocessors back in the '80s and into the early-mid '90s, if you had some code you needed to run really fast, you'd often write it in assembly, because a skilled human could easily write more optimized assembly than most C compilers could generate. Some early Mac programs were written entirely in assembly, and they were astonishingly fast for the era. Even without writing the whole program in assembly, I certainly did my share of optimizing inner loops in C via embedded assembly.

But things started changing in the mid-1990s. CPUs began including features like pipelining and branch prediction, so the most efficient instruction ordering was not always obvious to a human. Worse than that, the most efficient ordering varied among CPUs in the same family; for instance, PowerPC compilers typically offered target switches for G3, G4, and G5 series. The same object code would run on all of them, but it would run on one of those series more efficiently.

Since then, instruction ordering has gotten progressively more complicated, especially on the more architecturally complex CPUs like x86, PowerPC, and SPARC. (I believe ARM is still pretty simple that way.) A big added factor is code size - code that uses more CPU cycles but can remain in the CPU cache will often run much faster than code that uses fewer CPU cycles but triggers slow memory fetches. The major modern compilers can do a far better job of optimizing code on those CPUs than a human reasonably can.

I haven't found a good reason to write assembly in at least 15 years. I think in 2011, the main uses for assembly would be:

  • To read disassembly dumps when debugging, which I occasionally do even today.
  • Dealing with non-standard CPU features, like that funky graphics mode.
  • Compiler writing - it provides an intermediate, human-readable format to translate higher-level languages into.
  • 1
    And even your reason #3 is starting to disappear with compilers targeting either a high-level compiler framework like LLVM, nanojit or libjit or something like JVM, CIL, Parrot, Rubinius or Neko bytecode. Jul 26, 2011 at 1:16
  • It's still sometimes necessary to do a bit of SSE2 in graphics/video work. Although benchmark against TBB/OMP first! Jul 26, 2011 at 1:18
  • @Martin: OMP is orthogonal to SSE2. (assuming good data layout practices)
    – rwong
    Jul 26, 2011 at 11:45
  • @rwong - but the process is still, 1, discover it's too slow. 2, hope OMP/TBB speeds it up enough. 3, resort to hand writing SSE2 version! (in order of pain) Jul 26, 2011 at 17:40
  • 3
    As an example, the entirety of Roller Coaster Tycoon was written in assembly (minus the graphics which were done in c) and was amazingly powerful for it's time. Hundreds of individual AIs acting independently, almost seamlessly, when most game had a few 16x16 pixel sprites doing predefined motions. I always like to use that to show the power of assembly.
    – Ampt
    Jan 16, 2014 at 14:47

Try programming a microcontroller for a "small embedded" - a car alarm remote, a phone battery monitor, a keyboard controller, fan speed regulator, without using assembly.

While the border moves, there is always room for assembly.

15 years ago your bicycle odometer was mechanical, a microwave oven was in analog circuitry, TV remote was in digital circuitry, Sat TV tuner was written in assembly, a phone firmware was in C and a computer applet was in Java.

7 years ago a microwave oven was in digital circuitry, a TV remote was written in assembly, TV set-top box was written in C, your phone ran Java-based UI.

Nowadays, a bicycle odometer is in digital circuitry, a microwave oven gets firmware in assembly, a TV remote has firmware in C, TV set-top box runs Java, your phone got Linux.

Wanna bet the next 7 years? As more technology gets more advanced control languages, assembly gains new grounds, and it will keep getting them. Look at what is done today with mechanical or analog circuits. You can bet assembly there in a few years. Your light switch? Your water tap? Your kettle? Your toothbrush?

There will always be a new device, appliance, toy, common-life item to be programmed in assembly.

  • 3
    good answer. How many folks would rather pay twice as much for something that the batteries last half as long just because java or something was used as the development platform? Look at groupon and all the other ways folks look to save money, look at the green movement saving resources. Why drive the cost and power up on all embedded products just to avoid assembly?
    – old_timer
    Jan 12, 2012 at 22:57
  • 1
    You forgot to add that now computers run Javascript (Chromebooks). To me that progression is pretty sad but true.
    – Hawken
    Jan 6, 2013 at 2:55
  • As of 2017, CIA gets into your TV running Linux, signals from Java running on car keys can be spoofed, anyone can connect over WIFI to C++ firmware of a dildo camera, a toothbrush got a remote exploit in 2013, but luckily still earphones with noise cancellation created in assembly work. Although assembly loses position as top-level controller of anything, moving into sub-components instead. Your window blinds already run Java, but that Java control board talks to blinds motor controller that runs with assembly.
    – SF.
    May 16, 2017 at 9:05
  • It's going the opposite direction as well. Why does my washing machine need Bluetooth? Via 14 internet hops and 3 giant service providers I get a notice that my laundry is done. Great. Until I get a domestic servant, it will still have to wait until I get home.
    – JS.
    Jan 28, 2021 at 22:48
  • @JS. You still bought it over a model without the feature? Then the feature fulfills its role correctly.
    – SF.
    Jan 28, 2021 at 22:56

I'm basing this primarily the assemblers I've used -- primarily MASM, NASM, and (to a lesser extent) TASM. Some of the later versions of TASM had (have?) some features to support OO, but I haven't used them much, and I'm not trying to comment on them.

First: most languages have moved toward a structure that's at least somewhat tree-like. Whether object oriented, or object-based, or exactly what, there's quite a bit defined about the relationships between different parts of a system. There's also quite a bit to "protect" one part of a system from accidental "meddling" but other parts (even though the protection can usually be bypassed if you want to). By contrast, assembly language is relatively "flat" -- most of the relationships between the code (and data) in different parts of the system are established primarily by documentation and to a lesser extent naming conventions.

The result of this is that it's often much easier to couple code much more tightly than would be ideal. The requirements that drove the choice of assembly language to start with (higher performance, smaller size, etc.) often reward this as well -- by bypassing approved interfaces and such you can often get code that's smaller and faster (though not usually a lot better in any dimension). The language and tools themselves do much less to restrict what you do (good or bad), which places a much greater burden on the managers to prevent problems. I wouldn't say it's qualitatively different, but quantitatively it is -- i.e., management has to work to prevent problems either way, but in the case of assembly language it generally takes more (and often tighter) guidelines about what is or isn't acceptable.

Mitigating this is largely a matter of more careful guidelines, more guidance from more experienced personnel, and more specific, carefully enforced naming conventions.

Staffing is something of a problem. The problems I've encountered, however, where not primarily the ones I expected. Finding guys with a bit of a "fighter jock" personality who were happy to jump into assembly language code was fairly easy. Most did quite a reasonable job, despite an almost total lack of prior experience in using assembly language.

The difficulty I encountered was in finding more senior personnel -- people who could keep the project under at least some semblance of control, and weren't completely accustomed to languages that would provide (and largely enforce) the guidelines necessary to keep the code reasonably maintainable and understandable.

Looking back, I may have been/caused some of the biggest problem in that respect. I can see two sources of problems on my part. First, by the time of the project I'm thinking of, I'd been coding primarily in higher-level languages for quite a while, and using assembly language only as a last resort. As such, when I did use it, nearly every possible trick to gain performance was not only fair game, but expected. Second, back when I had worked on some systems written entirely (or primarily) in assembly language, it was under some rather iron-fisted project managers. At the time I'd been relatively young, and quite frankly resented the way they'd run things, so tended to do the opposite. In retrospect, what they were doing really was important, and not done just because they were old and inflexible (which, I'm pretty sure was how I saw things at the time).

  • I have fond memories of TASM and Orca/M assemblers =) Jul 26, 2011 at 4:11

in my opinion assembly as a development platform may not be relevant for everyday use. the main reason for this opinion may be because the amount of computational power that is removed from a given process Versus the amount of development time needed to optimise the same given process usually is not worth the time and energy (there is a specific term for this.. it sounds like man/hour or something..please edit if you know what i speak of..) there are the obvious exceptions mentioned above but as far as mainstream programming goes assembly is not used often.

this being said..assembly is still relevant today when learning programming in the context of software engineering studies,it teaches what a low level programming language looks like feels like and behaves. i'll go on and give the example of what we use in class these days. we use the pep/8 assembly that is developed by Stanley Warford (Pepperdine University USA) and its open source software given here. mainly used because it virtualizes the cpu and shows the memory contents while stepping through the code while it's running (quite useful for learning,debugging).

So depending on your usage assembly may or may not be relevant in my opinion.


I think you're asking "are trucks still relevant if we have cars?". I mean, assembly has a very wide range of applications but not as wide as high level programming has, the same way that there are much less trucks than cars.

In fields like optimization of algorithms, you can use directly processor registers for improving images/video processing algorithms.

In fields like cryptography you can use it in the same way.

In new processors with new architectures (remember when Cell microprocessor was released), for sure they had to write boot loaders and so on in assembly (and with old processors too, but long time used processors have a very stable ground and is difficult to improve it).

And many more examples could be given, so it depends in the field you company is focused, if your company is dedicated to web/mobile development, is very likely that you don't need it, but if your company is focused in microcontrollers, embedded systems, etc. is quite probable that you need it.

And staff availability, it depends on, I guess that if you ask in Intel, Qualcomm, ... they must have a large assembly programmer's list (is like if you ask at your workplace "how many truck drivers are around here?" I think not much, but it doesn't mean that there aren't in other places. What happens if you ask "how many car drivers are around here?").


If you really really want to know why learning assembly is the best bet. Here are reasons.

  1. No need to learn assembly, if you are going to do programming on visual basic and that MS stuff.
  2. No need to learn assembly, if you have to make no serious microcontroller gadgets.
  3. No need to learn assembly, if you have a real estate of memory at your disposal while working on microcontroller (god helps you while interfacing the memory with microcontroller)
  4. No need to learn assembly, if you do not want god like power over your microcontroller / microprocessor.
  5. Not knowing assembly is like knowing iceberg. You can seen 25% of what yours and your micros capability and 75% you will never know or understand
  6. Try running Kolibris OS completely written in Assembly !!! Have you seen an OS which boots up in less than 5 second and application start running with in 1 sec of mouse click.
  7. Modern compilers have general purpose functions in backend and hence final code generated would be heafty compared to Assembly.

Assembly is like the Natasha Romanoff of Avengers. It's a charm and magic. First, it will bite you but trust me you will never forget the taste.

  • 1
    this doesn't seem to offer anything substantial over points made and explained in prior 5 answers
    – gnat
    Jul 6, 2015 at 4:23