I have learned file memory management and some very simple CPU assembly for manual memory manipulation. Still, I feel like there is a gap in my knowledge when it comes to modern, complex computers, OSs, and compilers. What I am wondering is what goes into the decision process to allocate a set amount of memory for different data types. On x86 systems, it seems that 8 locations of byte-addressable memory are allocated for pointers consisting of 48-bit addresses. Is the system of allocation similar to that of Linux's buddy system for files? Why 8 bytes instead of 6? Can it only split in half (limited to powers of 2) or is there a purposeful reason it goes for 8 bytes instead of 6?

I am wondering about the whole process. When you run a program and its program memory is loaded into memory alongside the compile-time set variables, I assume that the compiler has already previously decided based on the computer system how many memory locations to ask for for each variable data type. But how does it decide this?

  • Is there a reason this is being downvoted? I am not sure if I have done something wrong or if people just do not like my question. I have been searching for the answer to this for a while, but I cannot find a straight one anywhere. Jul 18, 2020 at 15:50
  • 1
    "but I cannot find a straight one anywhere." Did you consider that there isn't a simple and straight answer? Your quesiton turns out to be very broad. Jul 18, 2020 at 17:54
  • The hardware naturally works with sizes that are certain powers of 2, so the compiler writers tend to choose those sizes. The compiler writers publish the sizes of various data types with their implementation (for example, using some language defined data types like size_t).
    – Erik Eidt
    Jul 18, 2020 at 19:33
  • @infinity8-room Sometimes it is hard to tell why people downvoted because they did not bother to explain. But then again others may upvote just to cancel out the unexplained downvotes. Jul 18, 2020 at 19:46

3 Answers 3


It's not so much the compiler that decides, but the software developers creating the compiler. And they decide that based on what makes sense for the processor, and what customers (developers who use the compiler) want.

For example, if you write a C compiler for a 64 bit ARM processor, your types can reasonably be 8, 16, 32 or 64 bit based on the hardware. char = 8 bit is very customary. short must be at least 16 bit, and since you don't want to be unable to use 16 bit types, you make short = 16 bit. You definitely want a type that can hold pointers, so long long int = 64 bit. You are reasonably free to decide for int and long, but int = 32 bit has been very customary for the last 20 years at least (in other words your customers will kill you if int is not 32 bit). And long int varies between 32 and 64 bit, depending on the mood of the compiler developer.

  • That makes sense. So it is 8 bytes for a pointer at least in the setup i mentioned because even though the memory is addressed with just 48 bits it still allows for 8 bytes (compatible for 64 bit addresses)? Jul 18, 2020 at 17:36
  • 6
    Don't get fixated on the 48-bit thing. The processor uses all 64 bits, just only 2^48 addresses (actually 2^47 at the bottom of the address space and 2^47 at the top of the address space) are valid on current hardware; see e.g. Wikipedia for the details. Jul 18, 2020 at 19:18
  • 1
    100s of million of embedded process / year for the pass decades have use 16-bit int. "in other words your customers will kill you if int is not 32 bit" is simply not factual. Jul 18, 2020 at 23:31
  • "your customers will kill you if int is >32 bit"
    – Caleth
    Jul 20, 2020 at 7:51
  • @chux-ReinstateMonica and - surprise - most people don't write software for embedded processors!
    – user253751
    Jul 20, 2020 at 13:17

Some of the decision is made by the compiler (or its authors) based on performance. E.g. your target hardware might allow to address memory on 1 byte granularity but only with a performance overhead of multiple cycles if the it is not aligned to 8 bytes.
Not all the decisions about the memory layout are left to the compiler, if the compiler wants to produce binaries that can be linked with binaries produced by other compilers. Compilers will follow the Application Binary Interface (ABI) specific to the target platform in regards to memory layout, calling conventions and alignment.


It’s based on what the underlying architecture supports - if you look at the instruction set for x86, everything's done in terms of bytes, words (2 bytes), longwords (4 bytes), and quadwords (8 bytes). There just aren’t any instructions for dealing with 6-byte entities (at least none that I know of). It’s just easier to use a fixed size, even if you don’t use every bit.

There have been word-addressed architectures in the past where word sizes weren’t powers of 2, but they’re not so common anymore.

The old Motorola 68000 only had 24 lines on the address bus, but addresses were stored in 32-bit words. Programmers for the original Macintosh would sometimes store some additional data in those unused 8 bits to make the most of that precious 128k of RAM. Unfortunately, when the 68020 came out it had a 32-bit address bus, and all that code had to be rewritten.

  • That kind of bit-smashing is probably the reason the 64bit x86 despite only supporting 48 bit address space forces canonical pointers. They might want to expand sometime. Jul 25, 2020 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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