You have a good question, but be prepared for some additional complexity, because some of these things relate to the bare transistor in the processor on which the code is running ...
I decided to fail, trying to condense it into 4 types.
- global storage
- code storage
- local storage
- dynamic storage
The code repository should be quite simple, so I just complicate it a bit: a cluster of thoughts translated into a fragment of a procedural language, now called a “function”, is translated into a sequence of machine instructions.
Those that need to be extracted and executed by the processor should be located in ROM or RAM ... defining the storage area of the code. Even if a function is called several times or even recursively, there is only one instance of its code.
(don't interfere)
A global data warehouse is RAM in which all declared variables not in a function become available (only one instance for declaration), as well as those declared as static (in a function or from a function). These include absolute (or quasi) addresses.
Constants may or may not get their own ROM storage area ... its specific compiler / optimization.
The local storage of the function is a bag for passing arguments / returns and local variables (declared in it, therefore, only visible to it), and each function call requires a separate package so that each call gets an individual context.
Usually (there are unforgettable exceptions) we use the Call-Stack mechanism to create several local storage areas that each function call generates. This is becoming increasingly uncertain, but you will find that it is a stack frame that grows in DEcrementing memory addresses.
Thus, local storage is where the compiler function call code (automatically made for you) places the arguments for the functions, the placeholder returns for the called function, the return address of the calling function, and everything is non-static (and optimized for internal use of registers). One for each call. The function code referenced by these local variables and arguments will ... err .. refer to the latter via the Stack-Pointer plus the offset, the CPU register, which indicates the current end address of the stack frame (how could the function code know the memory addresses in otherwise?).
A function call involves setting up a local storage, eventually copying arguments into it (pushing the stack) and initializing some local objects, and then switching to a functional code. Return - copy the return value of the called function to the caller's function. Local storage, destroying the local storage of the called F, placing the stack pointer at the end of the previously folded local storage package and moving to the saved address of the next caller's instruction (pulling things out). Done.
Looking at a snapshot of the memory of one process C, you can see a stack with several storage areas with a lower layer that will block growth and compression after the function call / return template executed by a specific program.
Dynamic memory is usually managed by malloc and free: the keepers of a growing packet of memory block addresses that you access with pointers. This forms the erroneously named heap area (because over time, you will most likely get a Swiss cheesse, not a bunch).
These pieces of memory can be used for any purpose, and the task is to make sure you do not forget to free them, otherwise over time you will "leak" into the call stack (it is easy to see how destructive it will be).
Using malloc / free managed memory requires a little extra discipline, but it is very useful to avoid huge global or lost global storage (in situations where a function needs to process a bunch of data and can be called several times or a large piece of data that very rarely should be remembered).
The area of dynamic memory is usually sandwiched between global and stack ... Some built-in compilers allow you to specify the size of these two.
Malloc and free are not the only ways to manage dynamic memory, and I'm currently using a home-made backlink allocator that does not require free (). Non-discriminatory code and no leaks .... yaayy!