I have read couple of embedded projects and in all of them the bootloader is written in Assembly instead of C. IS there any reason for this?
-
1That is a question better suited for the Programmers Stack Overflow site, rather than Stack Overflow directly. – AntonH Feb 23 '16 at 22:18
-
I've written 3 bootloaders in C. 0 in assembly. Easier to maintain. [Example tight code](http://stackoverflow.com/q/17070973/2410359) – chux - Reinstate Monica Feb 23 '16 at 22:21
-
2@AntonH please do not recommend cross-posting to another site. If a question truly is better-suited elsewhere and there is no direct migration path, flag it for a moderator to migrate (this question would not do well on Programmers). Please read: **[What goes on Programmers.SE? A guide for Stack Overflow](http://meta.programmers.stackexchange.com/q/7182/22815)**. – Feb 23 '16 at 22:22
-
Probably written by an oldschool retired programmers. And no-one knows how it works, so keeping it as is. – Eugene Sh. Feb 23 '16 at 22:25
-
1I don't see why this is marked as opinion-based. He asked if there is any reason for writing the bootloader in Assembly. As the answers below indiciate, there are reasons for at least part of it to be so. – Kurt Stutsman Feb 23 '16 at 23:06
-
How come this question is opinionated? I've reported my pure observation. – doubleE Feb 23 '16 at 23:53
-
It's not opinion-based, it's architecture-based and yes, you can 'use C' for certain values of highly-bodged, architecture-specific crt startup library with assembler setting up the initial stack pointer etc. – Martin James Feb 24 '16 at 00:03
-
Without that, running C code with no available data and no available stack is err... 'problematic'. – Martin James Feb 24 '16 at 00:04
-
C bootstrap sure, almost has to be, bootloaders are generally in C. – old_timer Feb 24 '16 at 00:12
-
bootstrap/bootloader/whatever. On embedded, that is probably going to mean the same, especially if the 'normal' app code is supplied direct from flash, rather than being loaded from a disk system. – Martin James Feb 24 '16 at 00:15
-
@MartinJames: Cortex-M can be written in C completely (with minor restrictions on features for the startup code). So, yes, it is very well opinionated and often left to speculation why some code still is written in Assembler. – too honest for this site Feb 24 '16 at 13:39
-
@dwelch: Not necessarily. See Cortex-M. – too honest for this site Feb 24 '16 at 13:40
-
I am very well versed in the cortex-m you still have to have something that creates the vector table. you may have some hidden or other "magic" that someone has setup for you to fill in that table but that is easiest to do a a small bit of assembler. After that true the hardware conforms to the calling convention and it does the minimal bootstrap so long as you dont want to conform to the C standard (dont use .data or assume .bss is zeroed). – old_timer Feb 24 '16 at 15:04
-
the magic done for you is likely done in asm, with it that easy why try some other solution (writing an elf object directly, etc) – old_timer Feb 24 '16 at 15:06
-
the magic can be done without asm, and that is true for every platform not just the cortex-m. One could hand write machine code, and write a tool to directly write an object file to cover the bootstrap task. So you could argue that no target/platform "requires" assembly language for the bootstrap. But why go to that effort when the existing tools (cortex-m or otherwise) are already there and so easy to use? – old_timer Feb 24 '16 at 15:41
2 Answers
Often at least the entry point stub, and possibly the transition to the real kernel, need to be written in assembly because they involve control-transfer/calling-convention constraints that are not representable in C. For instance if the boot loader needs to initialize the stack pointer to point to ram before the stack is usable, this cannot be represented in C without awkward compiler extensions. However it's generally possible to keep the amount written in asm very small and isolated to these types of boundaries. If the rest of the bootloader is written in asm too, it's usually a sign that the author has poorly assessed the costs (maintenance, bugs, etc.) vs benefits (possibly smaller size).

- 208,859
- 35
- 376
- 711
-
FWIW, the cortex MCUs don't really need anything in assembly. The core takes the first word of the vector table and uses that as the stack pointer. It then jumps to the second word. From there, you can pretty much do everything in C (even write task switching kernels) – Russ Schultz Feb 24 '16 at 01:17
-
@RussSchultz: That is not fully correct. You talk about Cortex-M. Cortex-A and R are still more the older way (I wish they were not). For Cortex-M, you can write all code in C by using CMSIS intrinsics, you are not C compatible out of reset. Simple reason is global variables are not initialised as mandated by the C standard. So, the initial code (startup code) cannot rely on this, but has to setup the RAM variables properly for the fully compatible C code (i.e. `main` or whatever the main entry point is called). – too honest for this site Feb 24 '16 at 13:36
-
@Olaf I won't argue that it's completely ready for C or C++ , but you can write the startup code in C if you want. You just need to know that global scope variables won't be set up unless they're const (at least with the Keil tools, check with the behavior of the tools). Not many people write the startup code, though, since it's provided by the tools and chip vendors. – Russ Schultz Feb 24 '16 at 14:28
-
@RussSchultz: I did not say the opposite. But Cortex-AR still need assembler (or special function entry/exit code from the compiler) for e.g. interrupt handlers. For instance their vector tables might still contain code instead of pointers to the handler like C-M has. And the question is clearly about that startup code, excluding that is quite useless for this question. Note I very well stated that for C-M, you can write all in C (with few exceptions, e.g. static variables not initialised). and that code you very well sometimes have to adopt. – too honest for this site Feb 24 '16 at 14:35
To make it as small as possible. You don't want the bootloader taking up all the space you could be using for your actual program, and in some chips the memory space reserved for the bootloader is relatively small. Such small programs are still a viable target for hand-optimization in Assembly.
You could probably get pretty close in C though.

- 63,558
- 9
- 127
- 159