如果可以内联嵌套函数调用，为什么程序要使用调用堆栈？

为什么不让编译器采用这样的程序：

function a(b) { return b^2 };
function c(b) { return a(b) + 5 };

并将其转换为这样的程序：

function c(b) { return b^2 + 5 };

从而消除了计算机记住c（b）的回信地址的需要？

我认为存储程序并支持其编译所需的硬盘空间和RAM分别增加，这就是我们使用调用堆栈的原因。那是对的吗？

这称为“内联”，许多编译器在有意义的情况下将其作为优化策略。

在您的特定示例中，此优化将节省空间和执行时间。但是，如果在程序中的多个位置调用该函数（这并不罕见！），则会增加代码大小，因此该策略变得更加不确定。（当然，如果函数直接或间接调用自身，则不可能内联，因为那样代码的大小将变得无限大。）

显然，只有“私人”功能才有可能。不能优化外部调用者公开的功能，至少不能优化具有动态链接的语言。

您的问题有两个部分：为什么要有多个功能（而不是用其定义替换函数调用），为什么要用调用栈实现这些功能，而不是在其他地方静态分配其数据？

第一个原因是递归。不仅是“哦，让我们为该列表中的每个项目都调用一个新的函数”类型，还有一种谦虚的类型，即您可能同时激活一个函数的两个调用，并且它们之间还有许多其他函数。您需要将局部变量放在堆栈上以支持此操作，并且通常不能内联递归函数。

然后是库的问题：您不知道从何处以及多久调用一次函数，因此永远无法真正编译“库”，而只能以某种方便的高级格式将其交付给所有客户端，内联到应用程序中。除了与此相关的其他问题之外，您还完全丧失了动态链接及其所有优点。

此外，有很多原因即使没有可能也不能内联函数：

1. 不一定更快。设置堆栈框架并拆除堆栈框架可能是十几条单循环指令，对于许多大型或循环函数而言，它们的执行时间甚至不到其执行时间的0.1％。
2. 可能会慢一些。代码重复具有成本，例如，它将对指令高速缓存施加更大的压力。
3. 一些函数非常大，可以在许多地方调用，将它们内联到任何地方都会增加二进制代码，远远超出了合理范围。
4. 编译器通常很难完成非常庞大的功能。在其他所有条件都相同的情况下，大小为2 * N的函数所花费的时间超过2 * T，而大小为N的函数所花费的时间为T时间。

堆栈使我们可以优雅地绕过有限数量的寄存器所施加的限制。

想象一下，恰好有26个全局“寄存器a”（甚至只有8080芯片的7个字节大小的寄存器），并且您在此应用中编写的每个函数都共享此平面列表。

一个天真的开始就是将前几个寄存器分配给第一个函数，并且知道只花了3个，就为第二个函数以“ d”开头……您很快就用光了。

相反，如果您有一个比喻性的磁带，例如图灵机，则可以让每个函数通过保存正在使用的所有变量并将其转发到磁带上来启动“调用另一个函数” ，然后被调用方函数可以与许多函数混淆根据需要注册。当被调用方完成操作后，它将控制权返回给父函数，该父函数知道需要在哪里锁定被调用方的输出，然后向后播放磁带以恢复其状态。

您的基本调用框架就是这样，它由标准化的机器代码序列创建和删除，编译器围绕从一个功能到另一个功能的转换进行放置。（自从我不得不记住我的C堆栈框架以来已经有很长时间了，但是您可以通过各种方式来了解X86_calling_conventions中谁丢掉什么的职责。）

（递归很棒，但是如果您不得不在没有堆栈的情况下处理寄存器，那么您真的会很喜欢堆栈。）

我认为存储程序并支持其编译所需的硬盘空间和RAM分别增加，这就是我们使用调用堆栈的原因。那是对的吗？

尽管这些天我们可以内联更多（“更快的速度”总是很好；“更少的kb的汇编”在视频流的世界中意味着很少），主要限制在于编译器能够在某些类型的代码模式中展平。

例如，多态对象-如果您不知道将要处理的唯一一种对象，则无法展平；您必须查看对象的功能表并通过该指针进行调用……在运行时很简单，在编译时无法内联。

当现代的工具链已平整了足够多的调用者以确切知道obj的风格是什么时，它可以愉快地内联一个多态定义的函数：

class Base {
    public: void act() = 0;
};
class Child1: public Base {
    public: void act() {};
};
void ActOn(Base* something) {
    something->act();
}
void InlineMe() {
    Child1 thingamabob;
    ActOn(&thingamabob);
}

在上面的代码中，编译器可以选择从InlineMe到act（）内部的任何内容，保持静态内联，也不需要在运行时触摸任何vtable。

但是在对象的什么味道的任何不确定性将会把它作为一个离散函数的调用，即使相同功能的其他一些调用被内联。

这种方法无法处理的情况：

function fib(a) { if(a>2) return fib(a-1)+fib(a-2); else return 1; }

function many(a) { for(i = 1 to a) { b(i); };}

还有是语言和平台有限或没有调用堆栈。PIC微处理器的硬件堆栈限制为2到32个条目。这产生了设计约束。

COBOL禁止递归：https : //stackoverflow.com/questions/27806812/in-cobol-is-it-possible-to-recursively-call-a-paragraph

禁止递归确实意味着您可以将程序的整个调用图静态表示为DAG。然后，您的编译器可以针对每个调用该函数的位置发出一个函数副本，并以固定的跳转而不是返回的形式进行调用。不需要堆栈，只需要更多的程序空间，对于复杂的系统可能会很多。但是对于小型嵌入式系统，这意味着您可以保证在运行时不会出现堆栈溢出，这对于您的核反应堆/喷气涡轮/汽车节气门控制等而言是个坏消息。

您需要函数内联，并且大多数（优化）编译器都在这样做。

请注意，内联要求被调用函数是已知的（并且仅在被调用函数不太大时才有效），因为从概念上讲，它是通过重写被调用函数来代替调用。因此，您通常无法内联未知函数（例如，函数指针-包括动态链接的 共享库中的函数 -可能在某些vtable中作为虚拟方法可见；但是某些编译器有时可能会通过非虚拟化技术进行优化）。当然，内联递归函数并非总是可行的（某些聪明的编译器可能使用部分求值，并且在某些情况下能够内联递归函数）。

还请注意，即使很容易实现，内联也不总是有效：您（实际上是您的编译器）可能会增加太多的代码大小，以至于CPU缓存（或branch预报器）的工作效率降低，从而使程序运行慢点。

^{我有点侧重于函数式编程风格，因为您对qestion进行了标记。}

请注意，您不需要任何调用栈（至少从机器意义上来说是“调用栈”表达式）。您只能使用堆。

因此，请看一下延续，并详细了解延续传递样式（CPS）和CPS转换（直观上讲，您可以将延续闭包用作分配在堆中的经过验证的“调用框架”，它们类似于调用栈；那么您需要一个高效的垃圾收集器）。

安德鲁•阿佩尔（Andrew Appel）写了一本书“ 用连续进行编译 ”（Build with Continuations），旧的纸垃圾收集比堆栈分配要快。另请参阅A.Kennedy的论文（ICFP2007）续编，续

我还建议阅读Queinnec的《Lisp In Small Pieces》一书，该书中有几章与延续和编译有关。

还要注意，某些语言（例如Brainfuck）或抽象机（例如OISC，RAM）没有任何调用功能，但仍然是图灵完备的，因此（理论上）您甚至不需要任何函数调用机制，即使这非常方便。顺便说一句，一些旧的指令集体系结构（例如IBM / 370）甚至没有硬件调用栈，也没有推送呼叫机器指令（IBM / 370只有分支和链接机器指令）

最后，如果您的整个程序（包括所有需要的库）没有任何递归，则可以将每个函数的返回地址（以及实际上已经变为静态的“本地”变量）存储在静态位置。早期的Fortran77编译器在1980年代初就这样做了（因此，当时编译的程序没有使用任何调用栈）。

内联（用等效功能替换函数调用）可以很好地用作小型简单函数的优化策略。可以有效地权衡函数调用的开销，而只需付出很小的代价就可以增加程序大小（或者在某些情况下完全没有代价）。

但是，如果内联所有内容，则依次调用其他函数的大型函数可能会导致程序规模的剧增。

可调用函数的全部要点不仅是程序员，而且是机器本身，都是为了促进有效的重用，并且包括诸如合理的内存或磁盘占用空间之类的属性。

物有所值：您可以拥有无​​需调用堆栈的可调用函数。例如：IBM System / 360。当在该硬件上使用诸如FORTRAN之类的语言进行编程时，程序计数器（返回地址）将保存在函数入口点之前保留的一小部分内存中。它允许可重用​​的函数，但不允许递归或多线程代码（尝试递归或重入调用将导致先前保存的返回地址被覆盖）。

正如其他答案所解释的那样，堆栈是件好事。它们有助于递归和多线程调用。尽管可以编码任何使用递归的算法而无需依赖递归，但是结果可能更复杂，更难维护且效率可能更低。我不确定无堆栈架构是否可以完全支持多线程。