0

I have a stupid doubt about something related to memory. My doubt is: Why in memory, the higher addresses are considered in the "bottom", and the lowest addresses are considered in the "top"? Im going to explain in more detail:

The stack memory starts in high addresses and grows to lower addresses. So far this is what I understood, but why does the stack grow "up"? Why are the lower addresses located in the top of the memory?

I've seen various, contradictory memory structures: ones which consider the lower addresses at the bottom of the memory, and ones which consider the lower addresses at the top of the memory. Does it depend on the processor?

Thank you in advance.

creeperspeak
  • 5,403
  • 1
  • 17
  • 38
victor26567
  • 129
  • 9
  • 1
    Where have you seen it said that memory addresses are like that? Stack is a different thing than memory in general – Sami Kuhmonen Jan 12 '18 at 21:56
  • Have you ever noticed how mathematicians and programmers draw a Tree? The root is always on top. – H H Jan 13 '18 at 07:51
  • Why do you ask? What kind of program are you coding? In what programmming language? On what computer and operating system? Why does that question matters to you? If you code in C, it is generally an unimportant detail... – Basile Starynkevitch Jan 14 '18 at 08:14

1 Answers1

0

It depends upon the instruction set architecture and the ABI. They both influence the organization (and growth direction) of the call stack.

Usually the call stack grows downwards, but there have been ISAs where that is not the case (see this). And some ISAs (e.g. IBM serie Z mainframes) don't have any hardware call stack (then, the call stack is just an ABI convention about register usage).

Most application software (e.g. your game, word processor, compiler, ...) are running above some operating system, in some process having some virtual address space (so in virtual memory).

Read some book on OSes, e.g. Operating Systems: Three Easy Pieces.

In practice (unless you code some operating system kernel managing virtual memory) you care mostly about the virtual address space (often made of numerous discontinuous segments). On Linux, use /proc/ (see proc(5)) to explore it (e.g. try cat /proc/$$/maps in your terminal). And notice that for a multi-threaded application each thread has its own call stack. Then "top" or "bottom" of the virtual address space don't really matter and don't have much sense.

If (as most people) you are writing (in any programming language other than the assembler) some application software above some OS, you don't care (as a developer) about real memory, but about virtual memory and resident set size. You don't care about the stack growth (it is managed by the OS, compiler, ISA, ... for the automatic variables of your code). You need to avoid stack overflow. It often happens that some pages (e.g. of your code segment[s]), perhaps those containing never used code, never get into RAM and stay paged out. And in practice most of the (virtual) memory of some process is not for its call stack: you usually allocate memory in the heap. My firefox browser (on my Linux desktop) has a virtual address space of 2.3 gigabytes (in more than a thousand of segments), but only 124 kilobytes of stack. Read about memory management. The call stack is often limited (e.g. to a few megabytes).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • why the downvote? – Basile Starynkevitch Jan 13 '18 at 06:38
  • One, because "it depends" doesn't require five paragraphs and a dozen links (esp when fully 80% of those links are only tangentially related to the question if at all). And two, because in all that rambling, you didn't give an example of a hardware call stack growing upwards -- the one category of example that would disprove the false premise inherent in the question. (And three, because there is in fact a good reason for call stacks growing downward, in the cases where they do -- but you didn't see fit to mention it, and thereby totally avoided actually answering the question.) – cHao Jan 14 '18 at 01:26
  • @cHao: feel free to provide your better answer. I'm impatient to read it. – Basile Starynkevitch Jan 14 '18 at 08:02
  • I would, if the question weren't already closed as a duplicate. But the answers to the duplicate provide some explanation. – cHao Jan 14 '18 at 13:48