ASM堆栈使用情况

Question

As far as I understand it, the stack can be used store data when you need to implement function or just run out of registers to use. The question I have is what piece of memory is the stack that is being used generally. I am getting the impression that this is dependent on the prefetch process and other factors. Also at what point is the stacking being loaded back into RAM.

Answer 1

Every process has threads and every thread has a stack. Each process has its own space called Process Address Space. The threads allocate their stack in this process address space. This space is a virtual space, meaning say a process gets 4 gb of process space, it might not always be on the RAM. It might be paged out to secondary memory when other process need RAM. Basically, you can assume that stack is a piece of memory managed by the OS by moving between secondary memory, RAM, cache etc, to optimize for best read/write times.

I have mostly worked on windows and the above statements hold good for windows. I am unsure about other operating systems.

Answer 2

Yes, the stack is used when you need temporary storage. that could be as simple as storage for the duration of a function, or as mentioned when you run out of registers and need to evict one to repurpose it.

Dont get caught up in too much more than simply understanding how the instruction set/hardware works. Generally called push and pop, these instructions generally take a register, usually a dedicated stack pointer register, which contains and address in ram. When a push happens the address in that register, the stack pointer, is used to write/push that data into ram and the stack pointer register contents, a ram address, is adjusted accordingly. This all done by hardware based on using that instruction. Pop the other way, ram is read based on the stack pointer address and flavor of pop instruction, contents of ram are placed somewhere based on the flavor of pop instruction and the stack pointer register contents are adjusted accordingly.

What ram address is used and why? Which is what I think you are asking. Well that is up to the system designers usually, the folks taking ram in a system and dividing it up between program, data, heap and stack. Often you see that if you have a single linear chunk of ram you are working with the lower (address) portion of that ram has the program itself, the instructions, just on top of that is the data used by that program, then the remainder of the memory is this no mans land. From the bottom of that memory toward the top is often where the heap lives. The compiler doesnt know how much heap is needed for mallocs, only the programmer does. The stack often begins at the top of this open space and grows down, each thing you push on the stack is pushed onto the bottom of the last thing you pushed on the stack and it grows down. There is a very real risk of the stack and heap colliding and that is the job of the programmer (usually, some languages/compilers burn a lot of extra code to try to prevent it if you ask). So generally the stack is co-located with the heap which is next door to the data and bss areas. Certaily this is not always the case, in some embedded systems you have your program in rom, and data and heap (if you are brave/crazy enough to use heap in an embedded system) are in a section of ram, and the stack might be in a separate section of ram, not next to the data/heap ram. maybe because that ram is faster for example. A good example of this is the gameboy advance, there is a 256K memory that is off chip and slower for general purpose and an on chip internal 32k that is much faster that is a good place to put your stack (and speed critical code). the rom containing the program itself (with some hardware accelleration to make it not painfully slow). Sometimes you have processors like the 6502 where the stack instructions operate on a specific area of ram only, 256 locations I think at address 0x200 or something like that, designed into the hardware that way. On chip not off. some processors like the ARM in ARM mode, dont have a stack pointer, any register can be used, and there isnt a push and pop, they are aliases for a flavor of general purpose load and store instructions. By convention a particular register is often reserved/used by the compiler as the stack pointer, but it is not required like it is for other processors. Granted other arm instruction sets like thumb and thumb2, to reduce the instruction size remove the general purpose nature and hardcode the conventional r13 as the stack pointer, so for those modes you dont have a choice, you get r13 and you dont use a general purpose instruction you specifically use the push and pop instructions.

Take all of this and place it in the windows or linux or other multi threaded/tasking operating system world. Nothing changes, the processor does not re-purpose its instruction set just for an operating system on the fly, you get the same set of instructions no matter what software you are running on that processor. What the operating system does is us an MMU, to make each program have the illusion of having a relatively small fixed amount of memory where the program space, data space, heap and stack live. The MMU gives the programs the illusion of all having the same address space, all programs for example may think that their program starts at address 0x8000, you cant have all programs live at one address, 0x8000 is a virtual address, the mmu maps it to a physical address and each program has a different set of physical addresses. When the operating system switches to the next task/program/thread it saves your stack pointer and the other registers, and loads the registers for the next program (tickles the mmu) and gives it some time on the processor, where it also thinks it has its own flat memory space with program space, data space, heap and stack.

The bulk of understanding about a stack is looking at the instruction set. The rest of the story is how is the address the stack pointer is chosen which can vary based on the platform, operating system and compilers. In a lot of cases the linker script or link process has a user defined rule for that. You as the programmer/user may not realize you are in control of that as you probably just use the compiler default, but for the popular compilers (well linkers) you have the choice to change it.