在大多数现代系统中,堆栈增长的方向是什么?
我正在准备C中的一些培训材料,希望我的示例适合典型的堆栈模型。
C堆栈在Linux,Windows,Mac OSX(PPC和X86),Solaris和最新Unixs中生长什么方向?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
我正在准备C中的一些培训材料,希望我的示例适合典型的堆栈模型。
C堆栈在Linux,Windows,Mac OSX(PPC和X86),Solaris和最新Unixs中生长什么方向?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(9)
生长的优点是在较旧的系统中,堆栈通常位于内存的顶部。程序通常从底部开始填充内存,因此这种内存管理最小化了测量和将堆栈底部放置在明智的地方的必要性。
The advantage of growing down is in older systems the stack was typically at the top of memory. Programs typically filled memory starting from the bottom thus this sort of memory management minimized the need to measure and place the bottom of the stack somewhere sensible.
堆栈在x86上生长(由体系结构定义,pop增量堆栈指针,推动减少。)
Stack grows down on x86 (defined by the architecture, pop increments stack pointer, push decrements.)
在MIPS和许多现代 risc Architectures 没有
push
和pop
说明。这些操作是通过手动调整堆栈指针然后相对加载/存储值的调整后指针来明确完成的。所有寄存器(除零寄存器除外)都是通用的,因此从理论上讲,任何寄存器都可以是堆栈指针,并且堆栈可以以任何方向增长,程序员想要说,堆栈通常会在大多数架构上生长,可能是为了避免堆栈和程序数据或堆积数据增长并相互冲突时的情况。还有一个很好的解决原因 sh-'s答案。一些示例:MIPS ABIS向下生长,并使用
$ 29
(aka$ sp
)作为堆栈指针,RISC-V ABI也向下生长并使用X2作为Intel中的 堆栈指针8051堆栈长大了,可能是因为内存空间很小(原始版本中的128个字节)
您可以在
另请参见
In MIPS and many modern RISC architectures (like PowerPC, RISC-V, SPARC...) there are no
push
andpop
instructions. Those operations are explicitly done by manually adjusting the stack pointer then load/store the value relatively to the adjusted pointer. All registers (except the zero register) are general purpose so in theory any register can be a stack pointer, and the stack can grow in any direction the programmer wantsThat said, the stack typically grows down on most architectures, probably to avoid the case when the stack and program data or heap data grows up and clash to each other. There's also the great addressing reasons mentioned sh-'s answer. Some examples: MIPS ABIs grows downwards and use
$29
(A.K.A$sp
) as the stack pointer, RISC-V ABI also grows downwards and use x2 as the stack pointerIn Intel 8051 the stack grows up, probably because the memory space is so tiny (128 bytes in original version) that there's no heap and you don't need to put the stack on top so that it'll be separated from the heap growing from bottom
You can find more information about the stack usage in various architectures in https://en.wikipedia.org/wiki/Calling_convention
See also
在大多数系统上,堆栈成长,我的文章 https://gist.github.com/cpq/ 8598782 解释了为什么它成长。这很简单:如何将两个增长的内存块(堆和堆栈)放在固定的内存中?最好的解决方案是将它们放在相反的末端,并让彼此成长。
On most systems, stack grows down, and my article at https://gist.github.com/cpq/8598782 explains WHY it grows down. It is simple: how to layout two growing memory blocks (heap and stack) in a fixed chunk of memory? The best solution is to put them on the opposite ends and let grow towards each other.
它的成长是因为分配给程序的内存具有底部的程序本身的“永久数据” IE代码,然后是中间的堆。您需要另一个固定点来参考堆栈,以便使您成为顶部。这意味着堆栈会生长,直到可能与堆上的对象相邻。
It grows down because the memory allocated to the program has the "permanent data" i.e. code for the program itself at the bottom, then the heap in the middle. You need another fixed point from which to reference the stack, so that leaves you the top. This means the stack grows down, until it is potentially adjacent to objects on the heap.
该宏应在没有UB的情况下在运行时检测到它:
This macro should detect it at runtime without UB:
堆栈增长通常不取决于操作系统本身,而是在运行的处理器上。例如,Solaris在X86和SPARC上运行。 MAC OSX(如您提到的)在PPC和X86上运行。 Linux运行从我的Big Honkin'系统Z工作到A tuny小手表。
如果CPU提供了任何选择,则OS使用的ABI /呼叫约定将指定如果您希望代码调用其他所有人的代码,则需要做出哪些选择。
处理器及其方向是:
1802年,展示了我的年龄,这是用于控制早期班车的芯片(我怀疑,如果门打开,则根据其具有的处理能力,我怀疑:-)和我的第二台计算机, comx-35 (跟随我的 zx80 )。
pdp11详细信息从在这里,8051,来自在这里。
SPARC体系结构使用滑动窗口寄存器模型。在架构上可见的细节还包括一个在内部有效且缓存的寄存器窗口的圆形缓冲区,并在过度/下降时带有陷阱。参见在这里有关详细信息。 AS sparcv8手册说明保存和还原说明就像添加说明和还原说明一样。寄存器旋转。使用正常数而不是通常的负数会产生向上增长的堆栈。
上述SCRT技术是另一种-1802使用了一些或16位寄存器(标准呼叫和返回技术)。一个是程序计数器,您可以将任何寄存器用作PC,其中
sep rn
指令。一个是堆栈指针,两个始终设置为指向SCRT代码地址,一个用于呼叫,一个用于返回。 否登记册以特殊的方式处理。请记住,这些细节来自记忆,它们可能不是完全正确的。例如,如果R3是PC,则R4是SCRT呼叫地址,R5是SCRT返回地址,R2是“堆栈”(在软件中实现的报价),
sep r4
将设置R4成为PC并开始运行SCRT调用代码。然后,它将将R3存储在R2“ stack”上(我认为R6用于临时存储),向上或向下调整,在R3之后抓住两个字节,将它们加载到 R3中,然后做<代码> sep r3 并在新地址运行。
要返回,它将
sep r5
将旧地址从R2堆栈中拉出,在其上添加两个(跳过呼叫的地址字节),将其加载到R3和sep r3中
开始运行上一个代码。在所有6502/6809/Z80基于堆栈的代码之后,最初很难将头缠绕,但仍然以一种笨拙的方式优雅。芯片的最大销售功能之一是完整的16位登记册,尽管您立即丢失了其中的7个(SCRT 5,DMA 2,而从内存中断)。 的胜利实际上是非常相似的。
啊,使用R14和R15寄存器进行呼叫/返回,Z系统
Stack growth doesn't usually depend on the operating system itself, but on the processor it's running on. Solaris, for example, runs on x86 and SPARC. Mac OSX (as you mentioned) runs on PPC and x86. Linux runs on everything from my big honkin' System z at work to a puny little wristwatch.
If the CPU provides any kind of choice, the ABI / calling convention used by the OS specifies which choice you need to make if you want your code to call everyone else's code.
The processors and their direction are:
Showing my age on those last few, the 1802 was the chip used to control the early shuttles (sensing if the doors were open, I suspect, based on the processing power it had :-) and my second computer, the COMX-35 (following my ZX80).
PDP11 details gleaned from here, 8051 details from here.
The SPARC architecture uses a sliding window register model. The architecturally visible details also include a circular buffer of register-windows that are valid and cached internally, with traps when that over/underflows. See here for details. As the SPARCv8 manual explains, SAVE and RESTORE instructions are like ADD instructions plus register-window rotation. Using a positive constant instead of the usual negative would give an upward-growing stack.
The afore-mentioned SCRT technique is another - the 1802 used some or it's sixteen 16-bit registers for SCRT (standard call and return technique). One was the program counter, you could use any register as the PC with the
SEP Rn
instruction. One was the stack pointer and two were set always to point to the SCRT code address, one for call, one for return. No register was treated in a special way. Keep in mind these details are from memory, they may not be totally correct.For example, if R3 was the PC, R4 was the SCRT call address, R5 was the SCRT return address and R2 was the "stack" (quotes as it's implemented in software),
SEP R4
would set R4 to be the PC and start running the SCRT call code.It would then store R3 on the R2 "stack" (I think R6 was used for temp storage), adjusting it up or down, grab the two bytes following R3, load them into R3, then do
SEP R3
and be running at the new address.To return, it would
SEP R5
which would pull the old address off the R2 stack, add two to it (to skip the address bytes of the call), load it into R3 andSEP R3
to start running the previous code.Very hard to wrap your head around initially after all the 6502/6809/z80 stack-based code but still elegant in a bang-your-head-against-the-wall sort of way. Also one of the big selling features of the chip was a full suite of 16 16-bit registers, despite the fact you immediately lost 7 of those (5 for SCRT, two for DMA and interrupts from memory). Ahh, the triumph of marketing over reality :-)
System z is actually quite similar, using its R14 and R15 registers for call/return.
在C ++(适应于C) stack.cc :
In C++ (adaptable to C) stack.cc:
只是对其他答案的一个小补充,据我所知,这一点没有触及这一点:
让堆栈向下生长使堆栈中的所有地址相对于堆栈指针都有正面的偏移。不需要负偏移,因为它们只能指向未使用的堆栈空间。当处理器支持堆栈POINTER-RELAINGE地址时,这简化了访问堆栈位置。
许多处理器的说明允许相对于某些寄存器具有正义偏移的访问。这些包括许多现代建筑以及一些旧建筑。例如,手臂拇指ABI规定了堆叠式相关的访问,并在单个16位指令词中编码了正面偏移。
如果堆栈增长,则所有有用的相对于堆栈Pointer的偏移量都是负的,它的直观和方便不那么方便。它也与寄存器相关地址的其他应用程序不一致,例如用于访问结构的字段。
Just a small addition to the other answers, which as far as I can see have not touched this point:
Having the stack grow downwards makes all addresses within the stack have a positive offset relative to the stack pointer. There's no need for negative offsets, as they would only point to unused stack space. This simplifies accessing stack locations when the processor supports stackpointer-relative addressing.
Many processors have instructions that allow accesses with a positive-only offset relative to some register. Those include many modern architectures, as well as some old ones. For example, the ARM Thumb ABI provides for stackpointer-relative accesses with a positive offset encoded within a single 16-bit instruction word.
If the stack grew upwards, all useful offsets relative to the stackpointer would be negative, which is less intuitive and less convenient. It also is at odds with other applications of register-relative addressing, for example for accessing fields of a struct.