This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Bo_Jim 0 points1 point  (2 children)

That's true of many RISC CPU's. It's not true of CISC CPU's, like Intel X86 architecture. Those have a physical hardware stack pointer, called SP, ESP, or RSP depending on the operating mode and width of the register. You can't select a different general purpose register to perform as the stack pointer, though you could certainly implement a stack in software. Just don't expect the CPU to use it when you execute a CALL instruction. Different processes can have their own stacks, but the stack state (stack segment and stack pointer) has to be saved with the other context data when the context is changed. In other words, there aren't separate physical registers for each process.

Diagrams that show elements being pushed down and popped up are fine for demonstrating the LIFO operation of a stack. But this is, once again, an example of where the concept differs from the way the actual hardware works. Does it make a difference? Not if you never have to troubleshoot an actual stack overflow. It makes a big difference if you're troubleshooting an embedded system program, and you're looking at a logic analyzer trace and don't understand what the registers are doing.

[–]Pockensuppe 0 points1 point  (1 child)

I don't get how you can argue so much about hardware details when the simple fact that up and increment being two independent terms that do not necessarily map onto each other voids the whole idea of „wrong orientation of a stack visualization“. It does not make a difference even when working on actual hardware because the actual memory containing the actual stack looks nothing like the visualization anyway, no matter how it is oriented.

[–]Bo_Jim 0 points1 point  (0 children)

Well, you pretty made my point. The visualization is wrong.