stack没有必要解释它是什么heap,关于它是如何工作的以及函数中的变量会发生什么的材料已经绰绰有余,但是在花了一些时间之后,我注意到实际上没有足够的材料来说明程序时如何分配内存是第一次推出?当程序编译并准备构建时,此时已经计算出启动和运行所需的最小内存量,而程序本身在stack新区域中占用了一块内存?我可以有一个公开的答案或描述这个的好材料吗?
最初是如何为程序分配内存的,分配在哪一部分?
stack没有必要解释它是什么heap,关于它是如何工作的以及函数中的变量会发生什么的材料已经绰绰有余,但是在花了一些时间之后,我注意到实际上没有足够的材料来说明程序时如何分配内存是第一次推出?当程序编译并准备构建时,此时已经计算出启动和运行所需的最小内存量,而程序本身在stack新区域中占用了一块内存?我可以有一个公开的答案或描述这个的好材料吗?
最初是如何为程序分配内存的,分配在哪一部分?
有什么问题?翻译器知道所有对象的大小。当函数进入时,分配一个所需大小的堆栈帧,并在其中放置局部变量。堆中对象的大小在翻译时或执行时也是已知的。硬件堆栈随着您的工作而增长。并非所有函数都在特定启动时被调用(好吧,程序并没有按照用户的意愿通过这个分支),因此硬件堆栈可能因启动而异。一般来说,启动时的栈是不分配的,只知道栈顶,然后知道怎么走。有时会出现堆栈溢出(又名 stackoverflow)。:-)
UPD1:
而且还有一个编译栈。这是机器没有硬件堆栈的时候。然后翻译器和链接器分析代码以确定哪些函数调用谁,并将堆栈放在 RAM 中,以便堆栈帧在调用时不会重叠。不知何故,我使用了来自 Tasking 的 C 编译器(或 Cale,我现在不记得了)用于英特尔的第 51 个单晶。这台机器有一个 5 或 10 字节的硬件堆栈,仅用于中断。因此,对于实际的程序,只是在那里制作了一个编译堆栈。而且,顺便说一句,打了很多电话,一切正常。只对不在任何地方调用的中断处理函数发誓。他们不得不打电话,但在运行时从来没有工作过。
在这样的架构中,堆栈实际上是在翻译和链接期间计算和分配的。但是现在不时髦了,硬件资源很多,所以没有人在翻译阶段算栈和堆。