I'm currently studying engineering in Telecommunications and Electronics and we have migrated from assembler to C in microprocessor programming. I have doubts that this is a good idea. What are some advantages and disadvantages of C compared to assembly?

The advantages/disadvantages I see are:


  • I can tell that C syntax is a lot easier to learn than Assembler syntax.
  • C is easier to use for making more complex programs.
  • Learning C is somehow more productive than learning assembler cause there is more developing stuff around C than Assembler.


  • Assembler is a lower level programming language than C,so this makes it a good for programming directly to hardware.
  • Is a lot more flexible alluding you to work with memory,interrupts,micro-registers,etc.
  • 18
    Uhm ...welcome to new century. You'll like it in here. We have microcontrollers running .NET, Java, Linux, and even people using python to program PICs.
    – ZJR
    Mar 9, 2012 at 4:14
  • @ZJR How do you use Python to program a PIC? Which PIC?
    – detly
    Mar 9, 2012 at 4:43
  • 2
    @detly It's not full fledged python, just a subset of the core. A coat of python syntax over the controller functionality, if you want. pyastra is the first example I googled back out, but I kinda remember having read docs of a different one, that also did ATMELs.
    – ZJR
    Mar 9, 2012 at 4:51
  • 4
    To be honest, with the complexity of modern processors I would be surprised if many programmers could write tighter, more efficient assembler than a modern C compiler can generate anyway. I'd hate to try to program an EPIC architecture CPU in assembler for instance - Mel would be right at home with the Itanium. *8')
    – Mark Booth
    Mar 9, 2012 at 14:09
  • 5
    @ZJR This new century sounds exciting! I'm curious though, in what language was the .NET runtime, Java VM and Linux written in, for those microcontrollers? As in, what language was the actual microcontroller programming done in? Oh... C or assembler this century too...
    – user29079
    Mar 19, 2012 at 15:07

7 Answers 7


Here are some stack overflow answers that may help you (these are the the top response, accepted answers):


https://stackoverflow.com/questions/143561/is-there-a-need-to-use-assembly-these-days (for 10K users only), or Archive

  • Assembly is used in the earliest stages of the bootloader. When the CPU powers on the stack isn't available, and its tough to keep the C compiler from trying to save things to the stack. The bulk of the bootloader is nonetheless written in C, once the earliest initialization is done.
  • Assembly is used to write mutex locking primitives. It is essentially impossible to get a C compiler to emit memory barrier instructions at the required places.
  • Routines like memset() or memcpy() are often done in assembly. For example, I wrote a memset() with a large unrolled loop, which dynamically computes a branch address to jump into the middle of that loop for one final iteration. A C routine would have generated more code, taking extra I$ misses. Likewise, CPU instruction sets often include cache line load or other instructions which can dramatically speed up memcpy(), which the C compiler will not utilize.



  • ASM has poor legibility and isn't really maintainable compared to higher-level languages.
  • Also, there are many fewer ASM developers than for other more popular languages, such as C.
  • Furthermore, if you use a higher-level language and new ASM instructions become available (SSE for example), you just need to update your compiler and your old code can easily make use of the new instructions.


The last post below is a Stack Overflow post outlining a scenario which will show an assembly example that is faster than C (when performing the same function).


  • C is easier to program in, compared to Assembly. There are obvious reasons not worth rehashing.

  • Being easier to use, C allows you to write programs faster. Generally these programs are also easier to debug and easier to maintain. Furthermore, it's easier to manage large, complex programs in C.

  • Often times, code generated by a compiler is equally as good (in terms of speed and efficiency) as hand-written assembler - if not better.

  • C is pretty darn low-level, and it's rare that you'll want to go much lower. Having an added layer of abstraction is rarely a bad thing.

  • When you do need to go lower, you can use Assembly, otherwise you can use C.

  • You can write Assembly in C-code, but not C in Assembly-code.

  • 7
    I would say, may times you will see C compiler optimized machine code is better than your hand-written assembly code
    – user
    Mar 11, 2012 at 4:03
  • @crucified - this was already a common (and usually justified) claim in the mid to late 90s. A compiler applies optimisations reliably and systematically - not just when it notices the opportunity.
    – user8709
    Mar 19, 2012 at 18:09

A C program can be compiled to different microprocessor architectures.


we have migrated from assembler to C in microprocessor programming. I have doubts that this is a good idea

Fear not, nobody develops new programs in 100% assembler any longer. Nowadays, C can be used even for the tiniest, crappiest 8-bit architectures. However, knowing some assembler makes you a significantly better C programmer. Also, there are always some small detail or two in a program that need to be written in assembler.

I can tell that C syntax is a lot easier to learn than Assembler syntax.

Yes the syntax is easier, certainly. However, learning the whole C language with all the annoying details is far more complex than learning all the details of a particular assembler. C is a much larger and wider language. But then again, you might not need to learn all the details.

C is easier to use for making more complex programs.

Indeed, C provides mechanisms for modular program design, such as encapsulation and local scopes/local variables. And C has a standard library, plus an enormous amount of resources written during the past 30 years. And most importantly, C is portable.

Learning C is somehow more productive than learning assembler cause there is more developing stuff around C than Assembler.

C has plenty of pre-made functionality, libraries and resources, so there will be less re-inventing of the wheel. But apart from that, your statement is subjective. I believe it is a matter of personal preference.

For example, I am an experienced C programmer, occasionally programming C++. I find myself far less productive in C++, because I don't know that language as well as I know C. But just because I feel that way, it doesn't necessarily mean that programming in C is more productive than programming in C++. An experienced C++ programmer would surely have the opposite opinion.

And there are many aspects to "productive". A very important aspect is maintenance time, and especially the time it takes to fix bugs induced by maintenance. C is far easier to maintain than assembler.

Assembler is a lower level programming language than C,so this makes it a good for programming directly to hardware.

Hardware programming can be done directly in either language. The only things you can't do in C are accessing stack pointers and condition registers etc, of the CPU core itself. So if by hardware programming you mean talking with your own CPU, then yes, assembler allows a bit more than C. If you mean accessing external hardware, then assembler holds no benefit over C. But perhaps disadvantages, as it is often harder to write generic assembler code for a particular external device, than generic C code.

Is a lot more flexible alluding you to work with memory,interrupts,micro-registers,etc.

This is not correct. C allows you to do all of that too, although you might have to rely on compiler-specific C code such as the interrupt keyword.

In the end, you need to know both languages to program MCUs, with emphasis on C.

  • In what way is the whole C language more complex than some of the more arcane machine languages? Having done both, I think C without the libraries is considerably less complex. If you're referring to the C Standard Library, you need something like that in assembler, also, to do anything useful. C may be a larger and wider language, but you don't need to know it to the same level of detail. a = b[i] + c; is a lot less complicated than instructions to load b[i] (which takes computation) and c into registers (which must be made available), add, and store. Mar 19, 2012 at 17:08
  • 1
    @DavidThornley The more you learn about C, the more you realize how complex it is. Do you know all the hundreds the cases of undefined/unspecified/impl.-defined behavior? Do you know all the implicit type promotion rules in detail (integer promotions, usual arithmetic conversions)? All the peculiar rules and syntax regarding type specifiers? All the various forms of static/dynamic multi-dimensional arrays, including array pointers (not to be confused with pointers to 1st element of an array) All the features of C99 and C11? And so on.
    – user29079
    Mar 19, 2012 at 20:04
  • 1
    @Lundin: What's important about C is that you're able to ask all of those questions and find concrete answers. Compilers conforming to the standard are required to document how they behave for the 62 (not "hundreds") implementation-defined behaviors. Assembly's sheer simplicity makes it a bring-your-own-lunch proposition, which in turn offloads the complexity that C deals with onto your own code. I could counter your argument by asking how many floating-point libraries have been written in assembly for any given architecture and why their behavior is implementation-defined.
    – Blrfl
    Mar 19, 2012 at 21:05
  • 1
    @Lundin: 62 is the number of compiler-defined behaviors listed in section 4 of the GCC manual. Leaving out what's library-defined makes for an apples-to-apples comparison since there's no standard library for assembly. The requirement to document is the first sentence of §J.3. GCC and the handful of commercial compilers I've bought or used since C89 was ratified (Intel, Sun, IBM, Portland Group) document, so your "most" that don't bother can't call themselves conforming. Speaking of standards, how's assembling x86 written with Intel syntax on an assembler with AT&T syntax work out for you?
    – Blrfl
    Mar 20, 2012 at 11:28
  • 1
    @Lundin: My car's great, thanks. The steering wheel, accelerator, brake, clutch and turn signal stalk are all in standard places, have standard behavior and the other controls are all clearly marked with ISO-standard symbols. All of the implementation-defined things like the entertainment system, HVAC, nav, cruise control, etc. are documented in a fat book in the glove compartment. Assembly is like my 1973 Plymouth: there wasn't much to it, but in raw form it wasn't anywhere near as capable as what I'm driving now. Assembly is the same way; the complexity comes in what you add to it.
    – Blrfl
    Mar 20, 2012 at 14:21

Depending on how embedded you need to go, C is going to produce large, slow programs. Which will noticeably increase the cost of that portion of the product. It might be a drop in the ocean for the overall product or might radically change the product. Yes, some might say that the software development and maintenance efforts are cheaper, again that can be true or false, if that deeply embedded and aiming for a part that low power, small, and inexpensive you are not talking about a lot of code. That code is mostly specific to that vendor or that specific chip so being in C has zero portability benefits, you have to rewrite fore each target anyway. With the cortex-m series from ARM we are just now starting to be able to have C compete with asm, not that folks havent been using C or other higher level languages in their embedded products, but they have done it at a cost.

The C vs ASM debate, professionally, always boils down to write it in C and use ASM where you can justify it. And you can justify it. In the embedded world there is performance and size.

You have to include the target in this discussion. Although many have used C with Microchip (the older pics, not the pic32 which is mips) at a huge cost, it is a dreadful instruction set for compilers, very educational and interesting instruction set but compiler unfriendly. msp430, avr, arm, thumb, mips, all good for compilers. 8051 also bad.

Even more than the language the tools. Esp in those cases where worrying about code development and management are an argument, you need tools to be there today and tomorrow. Having a single source tool, even including a single gcc mod, managed by one group, is risky from a business perspective. You likely to find more than one assembler, and anyone worthy on being on that team could whip up an assembler in a weekend (so long as the assembly you write is not ghee whiz directive and macro happy). For both asm and C you would want to use open source tools (or your own in house tools) where you stand a better chance, even if it means using a virtual machine to run a 10 year old linux distro, of having tools available for the life of the product.

The bottom line, again, use/learn/teach both C and asm, start with C and use asm where you can justify it.

  • These arguments sound old-fashioned to me. If you are using a modern compiler that was written in the past 10 years, then I believe you will have a hard time to write an assembler program that is significantly more effective than a C program. Unless perhaps, you are using some 30 year old dinosaur architecture like PIC or 8051, then you will have a slow program no matter what you do...
    – user29079
    Mar 19, 2012 at 15:53
  • It is quite trivial to fix slow assembly generated by the most modern gcc and llvm. The 4.x gcc produces slower, less efficient code than the 3.x series (for some targets, at least the ones I have evaluated, ARM for example). I think it is important to dispell the notion that the compiler is doing better than humans because it isnt. And even when it does it only does it when the human knows what they are doing. "know your tools" if you want to use them effectively. Start with C and use ASM when needed if you can justify it...
    – old_timer
    Mar 19, 2012 at 17:28
  • Since gcc is open source, it is a strange beast. Maybe that particular port is poorly made. All code optimizations must be done for the specific platform, that's not a trivial task. It would be more fair to compare the performance of manual assembler versus a commercial compiler for that platform.
    – user29079
    Mar 19, 2012 at 20:11
  • gcc is multi-target so it does a pretty good job on average but not a great job for any particular target. And that is what is expected. but your point about a modern compiler, past 10 years, etc. Just doesnt hold, compilers are not getting better as far as code produced they are getting better as far as languages and targets and features at the cost of code produced. The notion that any modern compiler makes the best code possible is simply false. Very true that on average is MUCH better than hand coded assembler, hard to make any decent sized project in asm better than C
    – old_timer
    Mar 19, 2012 at 22:08
  • which is why most folks say use C until there is a problem then hand repair the problem in asm if you can justify it. do you really need that small bit of performance gain, is that really where your performance problem is, do you want to maintain this code with asm in it, will you continue to check each future compiler to see if its output repairs or reduces your problem to an acceptable level, etc.
    – old_timer
    Mar 19, 2012 at 22:10

For assembly there's an unavoidable compromise between code maintainability and performance. You can write easy to read/maintain assembly, or you can write highly optimised code; but you can not do both.

For C, the compromise doesn't quite disappear, but it's far less noticeable - you can write easy to read/maintain C that is reasonably well optimised.

An excellent assembly language programmer will be capable of beating the compiler almost all of the time, but most of the time they will deliberately choose to write easy to read/maintain code instead; and therefore an excellent assembly language programmer will be beaten by a compiler most of the time.

The smart way is to use both assembly and C (instead of only assembly or only C) - e.g. use C for parts of the code where an excellent assembly language programmer would've chosen to write maintainable/slow code, and use assembly for the remainder (where "highly optimised and hard to maintain" is actually justified).

  1. Relatively good for programming efficiency.
  2. It is easy to program using c language rather than using assembly.
  3. C language can be quite faster than assembly language.
  4. It is possible to write assembly in C code but not C in assembly code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.