请教一个有关虚拟内存的问题

javacool

楼上的意思 我明白 我的想法是 我的变量i是在中间声明的 所以他会不会是在函数调用后，在运行中才压栈， 这样它的地址就会发生变化
这边 我又换了一种写法 这次用不同函数调用次数来改变栈的大小这次证明了我的想法
以下是代码
#include <stdio.h>;

void fun()
{
        int k=15;
        printf(" %d\n",&k);
        k++;
}

void fun1()
{
        int j = 0;
        fun();
        j++;
}

void fun2()
{
        int c=0;
        fun1();
}
void main(int argc, char **argv)
{
       
        if(argc == 1)
                fun();
        else
                if(argc == 2)
                   fun1();
                else
                   fun2();
}
每次根据输入参数次数不同 调用不同数目的函数
的到的结果是
$test
1244924
$test  12
1244836
$test  12 23
1244748
每次参数k的地址（虚存地址）不同 且随着栈的增长（函数调用的增多） 参数K的地址变小

zjBahamout

补充一下，分配局部变量空间是在执行你的函数代码段之前完成的。这一点很重要

zjBahamout

nod

调用者：
是先压栈参数，然后调用call，最后调整esp出栈。

javacool

嗯 楼上的说的有道理 再问一下
在函数中部声明的参数 编译后的代码也还是在进入函数代码端前就已经分配好的 还是 局部变量是栈中一个固定的区域运行时动态分配的（该区域不受push eax操作的影响）
这两种方法都可以解释 一开始代码中i变量地址不变的问题

aero

继续建议看C语言编译后的汇编代码，尤其是一般的函数框架。

win_hate

这个问题取决于编译器的实现，可以有两种做法：

1、见到局部变量后再分配。
2、计算一个函数所有局部变量占据空间的总和，一次分配。在函数运行过程中不再为局部变量做栈的调整。

第一种方法效率低，但容易实现。第二种方法效率高，但实现起来麻烦一些。gcc 在默认情况下，使用第二种策略。 至于vc，可以作如下观察：

1. 
   
2. #include <stdio.h>;
   
3. 
   
4. void main(int argc, char **argv)
   
5. {
   
6. int x;
   
7. int count = argc;
   
8. int y;
   
9. while(count >; 0)
   
10. {
    
11. __asm
    
12. {
    
13. push eax;
    
14. push eax;
    
15. push eax;
    
16. }
    
17. count--;
    
18. }
    
19. {
    
20. int i = 1; //在堆栈中分配i的空间
    
21. printf ("%p\n", &x);              <====
    
22. printf ("%p\n", &count);       <====
    
23. printf ("%p\n", &y);     <====
    
24. printf("%p\n", &i);    <====
    
25. }
    
26. count = argc;
    
27. while(count >; 0)
    
28. {
    
29. __asm
    
30. {
    
31. pop eax;
    
32. pop eax;
    
33. pop eax;
    
34. }
    
35. count--;
    
36. }
    
37. }
    

复制代码

0012FF7C
0012FF78
0012FF74
0012FF70

显然是预先分配好的。

win_hate

原帖由 "javacool" 发表：
int count = argc;
while(count >; 0)
{
__asm
{
push eax;
push eax;
push eax;
}

此外，请注意 (count >;0)   的值总为 1

converse

>;>;1、见到局部变量后再分配。
我认为应该都是全部分配的吧，毕竟c不是解释执行的，编译器扫描代码的时候就会标记出哪些是局部变量然后一起分配好空间。

win_hate

比如

1. 
   
2. f()
   
3. {
   
4. 
   
5. ...
   
6. 
   
7.         { 《== local block
   
8.                 int i;
   
9.              ....
   
10.         }
    
11. 
    
12. }
    

复制代码

可以在进入 local block 时拨动栈指针，分配空间，离开块时把指针拨回去。相当于把 {} 看成不用跳转的函数。

我不清楚是否有编译器如此实现，但看上去十分可行。

这跟解释执行是不同的，指令都在编译时固定下来了。

win_hate

更正：

我仔细想了一下， 上面所说的 第一种 策略其实是十分糟糕的，原因在于：
{} 与函数 有一个很关键的不同：

1. 
   
2. f()
   
3. {
   
4.         int  i;
   
5.         ..........
   
6.         { /* local block */
   
7.                  int j;
   
8.                  ..............
   
9.          }
   
10. }
    

复制代码

如上代码，变量  i 在  local block {} 中是可见的，也就是说，我们可以在
{} 中访问，修改 变量 i。这种情况在函数调用中不会出现。考虑到 local block
中可能会嵌套多个局部块，如果移动了记录栈的指针，将使得追踪各层局部变量的值变得很困难。如果这样，还不如一开始就 figure 出将要使用的空间，一次分配出去。

这个策略虽然糟糕，但却是可以实现的，因为  {} 块的个数总是可以预先知道，小心地把栈的变化记录下来就可以了。实际使用的编译器肯定不会使用这个策略。