Where does binary go in a computer? When you turn the computer on it points to the bios and runs through it. I get that. Then it loads data off something ( disk, flash, etc. ). But where does it go? Does the binary go in ram? Does that mean if my program is 2mb and ram is 32mb I can only address 30mb? I mainly want to know so I can tell how big my bin can be.

I'm just a little confused on this issue. I know it's platform specific. But in general where would it go, and in general what document would I look at to check this information?


With the processors used for embedded devices, there are three possibilities:

  1. The processor executes the code directly from flash/ROM. In this case, the code doesn't take any RAM away from the system at all. In this setup, the RAM and flash/ROM are typically mapped to different portions of the address space that the processor can address, so the maximum size of your binaries is bounded by the physical amount of flash/ROM you have and the total amount of memory (RAM + ROM) needed by your software is bounded by the addressing capabilities of the processor.

  2. The binary is copied to RAM and there is no virtual memory available. In this case, the binary does take RAM away from the system and the software will have that much less memory to work with. The size of your binaries is bounded by the physical amount of RAM you have and the total amount of memory (RAM + ROM) needed by your software.

  3. The binary is copied to RAM and there is virtual memory available. This is similar to the second option, with the main difference that the amount of RAM is seemingly increased by copying parts of it out to secondary memory (flash, SD card, hard-disk, etc.). From a memory point-of-view, such a system is comparable to a desktop computer.

The datasheet for the processor should state if it supports execution directly from flash/ROM. The datasheet for the board you are using should state how much memory and of which type the board has (it might also mention if the processor can/will execute the code directly from flash). The documentation of the OS you are using should mention if the OS provides virtual memory capabilities. The large OSes (Linux, WinCE, etc.) typically do.

  • +1, especially for point 1, which I forgot to mention in my answer. – Doc Brown Jul 14 '14 at 13:12

Does the binary go in ram?

On most systems: yes. Though on many today systems there is an additional abstraction layer between the physical RAM and the RAM your processor "believes it has" - it is called virtual memory, as the other answer already pointed out. So if for example your machine has 32MB of physical RAM, but 64MB of virtual memory, as soon as the running programs need more than 32MB in total, the operating system tries to "swap out" least recently used areas of the physical memory to disk, and loads memory which needs to be accessed immediately from disk again into physical memory. For your program (including other programs on the machine) it looks like as if there are 64MB of physical ram, besides the fact that things become a hell lot slower when crossing the 32MB boundary often.


Assumed your program has a code size of 2MB, and your system has only 32MB of memory (either physical with no virtual mem, or 32MB of virtual memory), this leaves 30MB for anything else - working space for your own program, as well as code and working memory for any other processes or programs running at the same time.

in general what document would I look at to check this information

The amount of physical RAM is typically documented in your systems hardware documentation (and also in advertisement catalogues, but I would actually not recommend to take these as a serious reference). The amount of virtual RAM can typically be parametrized in the system's settings. And if you want to know how much RAM your program can really use for itself, you have to inspect a running system with some kind of systems monitor and see how much physical or virtual memory is still free when there are no other running processes besides the ones of the operating system.


Your program can get as big as the virtual memory on your system. To get a more specific answer, please give more specific information. Are you just interested? Struggling with an embedded system? Doing homework?

  • Not everything has virtual memory. At boot, virtual memory is not initialized, so although this answer is not wrong, its not always right. – mattnz Jul 14 '14 at 7:59

The bios runs off of a rom, it initializes the dram, enumerates the pcie, and a number of other things.

The bios then finds your or some program on the boot device, copies that to ram and runs it there.

the basic answer is yes if you have 32mb and your program is 2mb then there is 30mb left for heap and stack.

Virtual memory solutions first have to be set up and managed, but assuming that is being done it is possible to access the limits of the virtual memory space, or the media that is used behind the virtual memory space (hard disk, etc). If your program is running off of the disk loaded by the bootloader, then you dont have virtual memory unless you implement it yourself so you are limited to the 32mb in your example.

Depending on how you write your code, globals vs locals, heap usage or not determines how much of that 32mb you can dig into with your actual binary, you will need some stack but the more local variables you use and the smaller and more nested your functions are the amount of stack usage can go way up. That can be offset with globals but that can also chew up your ram quickly as well (these would likely be counted in your "binary" and be a known quantity vs stack which is fairly dynamic although can be somewhat computed).

Your Answer

