Questions tagged «stack-oriented»

我们都知道并喜欢函数调用通常是使用堆栈来实现的。有框架，返回地址，参数等等。 但是，堆栈是实现细节：调用约定可能会做不同的事情（例如，x86快速调用使用（某些）寄存器，MIPS和跟随器使用寄存器窗口，等等），优化甚至可以做其他事情（内联，帧指针省略，尾调用优化..）。 当然，许多机器（如JVM和CLR这样的VM，以及带有PUSH / POP等的x86等实际机器）上都存在方便的堆栈指令，可以很方便地将其用于函数调用，但是在某些情况下，这是可能的以不需要调用堆栈的方式进行编程（我在这里考虑的是Continuation Passing Style，或者消息传递系统中的Actor） 因此，我开始感到奇怪：是否可以在没有堆栈的情况下实现函数调用语义，或者更好地使用不同的数据结构（可能是队列，或者是关联映射？） ，当然，我知道堆栈非常有用。方便（它无处不在的一个原因），但是最近我碰到了一个使我感到奇怪的实现。 你们是否知道是否曾经用任何语言/机器/虚拟机完成过这项工作？如果有的话，有哪些显着的区别和缺点？ 编辑：我的直觉是不同的子计算方法可以使用不同的数据结构。例如，lambda演算不是基于堆栈的（函数应用程序的想法通过简化来体现），但是我正在查看一种真实的语言/机器/示例。这就是为什么我要问...

19 virtual-machine  semantics  stack-oriented  continuation  tail-call 

使用基于堆栈的语言进行垃圾收集（GC）有什么需求？使用Forth或RPL（在HP计算器上）这样的语言，是否需要进行垃圾收集？ 我认为，由于输出是从堆栈中弹出的，因此没有任何需要。我想念什么吗？

16 garbage-collection  stack-oriented 

我最近承担了编写基于堆栈的编程语言的任务。但是，在开始设计语言之前，我认为阅读和尝试现有的基于堆栈的语言是一个好主意。 这把我带到了这篇文章的主题。我正在阅读有关Forth的Wikipedia文章，Forth是一种使用后缀样式表达式的基于堆栈的语言。在文章中，我看到了以下语句： Forth的灵活性使静态BNF语法不合适，并且它没有整体编译器。扩展编译器只需要写一个新词，而不需要修改语法和更改基础实现。 据我了解，在Forth术语中，“单词”一词基本上与“子例程”同义。鉴于此，上述说法似乎很奇怪。为什么在Forth中创建新功能的能力会导致Forth的正式语法不合适？为什么需要为定义的每个新子例程重新编写语法？在环境中写一个新单词如何构成扩展编译器？上面的陈述似乎类似于说正式语法不适合Python，因为您可以定义新函数。 实际上，我决定尝试为下面的Forth的一个简单子集编写BNF样式语法： program ::= stmt+ stmt ::= func | expr func ::= ':' expr+ ';' expr ::= INTEGER | word word ::= ('+' | '-' | '*' | '/' ) 上面的语法似乎涵盖了Forth语句的有效子集，并且似乎很难扩展到涵盖Forth语言中的所有有效语句。此外，如果编译器的解析器实现了上述语法，我将看不到如何扩展该编译器。编译器只会在其环境中添加任何新词。仅环境被更改。似乎以上来自Wikipedia的摘录似乎正在将构成编译器（不会更改）的下划线代码与编译器的环境（确实会更改）进行混合。 总而言之，为什么福斯（Forth）定义新词（子例程）的敏捷性不适合书面语法？

10 compiler  syntax  grammar  stack-oriented  forth