这是一个创建于 4190 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。
我个人的思考是，这样做
- 不需要额外存大小了（比较指针是否到0来判断是否满）
- 也许可以保护数据？（因为有段寄存器）
不知道大家是如何考虑的呢
我个人的思考是，这样做
- 不需要额外存大小了（比较指针是否到0来判断是否满）
- 也许可以保护数据？（因为有段寄存器）
不知道大家是如何考虑的呢
 |
1
013231 2013-07-07 02:56:14 +08:00  1
棧向低位增長, 數據入棧後棧頂地址變得更小, 自然是減法.
|
 |
2
detailyang 2013-07-07 08:59:34 +08:00 2
蛋疼...栈往向下长 堆往上长 = =
cat /proc/pid/maps |
 |
3
timonwong 2013-07-07 10:43:28 +08:00 2
体系结构不同而已，也有往上长的，说个还算比较常见的： 8051
|
 |
4
breeswish OP |
|
5
detailyang 2013-07-07 11:42:58 +08:00
@breeswish 楼主...我也不懂为什么这样设计栈
|
|
6
timonwong 2013-07-07 11:55:20 +08:00 1
@breeswish
有一定历史原因，对于统一编址的结构（现在考虑古老的8086，最大8KiB的线性寻址），PC如果从0开始，栈放哪儿呢,2K,4K，然后保留给程序代码的地址空间要多少？如果代码只用了128字节，栈底从4K往上长，那就有一大堆内存给浪费了。 |
 |
7
lldong 2013-07-07 12:07:40 +08:00 1
This enormous 64 bits worth of address space is divided up into two areas: The stack and the heap. The stack is an area set aside high in the address space (typically high, anyway; in practice it can be just about anywhere) for the use of subroutine calls and local variable storage. The stack always grows downward; as the amount of information on the stack increases, the address of the top of the stack decreases. On older systems with smaller memory models, it was possible for the stack to grow too far downward and collide with other areas, but while it's still technically possible for this to happen, other things would go wrong long before a heap collision (in particular, the stack would run off the edge of its allocated memory pages and cause a protection fault). The CPU has a few instructions specifically designed for manipulating the stack, though they often go unused in favor of more efficient methods in modern code. You can think of the stack as a moderately large chunk of memory allocated by the system at the launch of your program.
The heap effectively consists of every area of memory that is not the stack; memory from the heap is allocated at runtime by the system for the process' use. The heap contains the stack, in fact, though they are usually considered conceptually separate. All of your executable code is loaded into a section of the heap, as well as copies of any libraries your executable links to. Note: These are not actually copies, as it would be ridiculously inefficient to copy every library for every loaded process, but it's easier to just think of them as copies until you have a good grasp of virtual memory. Memory allocated by your process during its execution also comes from the heap. http://www.mikeash.com/pyblog/friday-qa-2011-12-16-disassembling-the-assembly-part-1.html |
Select Language