在这里，我找到了一个用 Java 实现的简单 Forth 解释器。
但是，如果我想使用它，我不明白它的意义？
Forth Interpreter 的优势是什么：
- 如果 JVM 执行的最终编译代码仍然是“字节码”，我们的 Forth 解释器会做什么？
- 它有助于编写高效/紧凑的程序吗？
- 我会在 Forth 中编写代码，然后解释器会将其转换为 Java 吗？
你的意见...
问问题
4779 次
7 回答
5
页面上的作者描述为实现 FORTH 的一个子集并适用于其他应用程序；据推测，它旨在为应用程序提供脚本功能。系统不太可能通过吐出 java 或 JVM 字节码来工作；它几乎可以肯定使用用 Java 编写的解释器。
传统上，FORTH 解释器可以在非常小的内存占用中实现。我知道有人在 COSMAC 上实现了一个，核心解释器有 30个字节长。面向堆栈的字节码也非常紧凑，因为它不需要指定操作数的位置——它只是从堆栈中读取并将结果存放在堆栈顶部。这使得它在嵌入式系统圈子中很受欢迎，其中解释器的小开销被程序逻辑的紧凑表示所抵消。
这些天它不那么重要了，因为机器往往更大，尽管 digitalross对仍在使用 FORTH 的其他情况提出了一个很好的观点。
于 2009-09-12T20:26:40.630 回答
4
它有助于编写高效/紧凑的程序吗？
这是值得商榷的。
我相信 FORTH 的人会告诉你它很快。但我怀疑在用 Java 实现的 FORTH 解释器上运行的 FORTH 程序的执行速度是否会与直接用 Java 实现的等效程序的速度一致。首先，JIT 编译器在优化 FORTH 解释器方面的表现不如普通 Java 版本那样好。
如果“紧”是指“使用更少的内存”，我认为差异将是微不足道的。请记住，在“FORTH in Java”和“plain Java”两种情况下，您都拥有 Java JVM 的所有内存开销。这可能会淹没 FORTH 代码密度与等效编译 Java 代码密度的任何比较。
于 2009-09-13T03:29:12.993 回答
2
不是字节码翻译器
你的问题的答案是：“见下文，有点，不是”。
它只是一个接受一些输入并产生一些输出的程序。输入是一个 Forth 脚本。除了一些非常重要的系统之外，实际生成字节码的情况很少见。jRuby、Clojure、Scala .. 像这样的大型系统确实会产生字节码。
然而，您的 Forth 解释器可能就是这样：一个恰好用 java 编写的脚本解释器。它接受的输入是一个程序，所以你最终会得到一个很好的双重间接执行。Forth 通过字节码解释器执行，通过 CPU 上运行的 jvm 执行。
现在，如果你在 CPU 模拟器上运行它，或者在 Forth 中编写一个解释器，你可以使它成为三重间接的。（从某种意义上说，它已经是，因为您的英特尔 CPU 在执行大多数x86 操作码之前会将它们转换为微操作。:-)
无论如何，关键是用像 java 这样的静态语言编写的程序可能想要接受一些复杂的用户输入并执行它，或者程序的作者可能有更容易完成的事情，这使他能够用java和for来写。
您应该考虑所有这些，直到您理解为止。
于 2009-09-12T19:41:44.847 回答
2
它确实允许您编写高效/紧凑的程序。部分是因为定义定义词（在编译时执行的词）的能力可以有效地定义领域特定语言（DSL）。Forth 还鼓励重构（否则堆栈的东西会变得难以理解......），因此代码会很紧凑。
于 2009-09-12T20:15:22.273 回答
1
7th恕我直言，与 JVM 上的任何其他 RPN 语言相比，它更接近 April 的原始设计。有一个带有行号和代码美化器的编辑器。“interpiler”和带有词汇/当前/上下文的字典有一个匹配的实现。有条件地，大多数与硬件相关的字（用于存储到特定内存地址或从特定内存地址获取）都丢失了。无论如何，任何用于在 JVM 上计算内存的词都是毫无意义的。在第 7 节中对第4 种语法进行了一些有用的补充：
- 帮助这个词
- 7、面向对象
- 有一个类似 perl 的模式匹配
- 复数和数组是语言的一部分
- 一种可重定向/不可操作的机制，可选择将输出发送到堆栈或控制台并防止执行文件 io 字，例如。在测试时
于 2018-05-19T16:38:19.727 回答
0
类似 FORTH 的解释器的主要优点是它的交互性——意味着我输入一个单词并立即得到响应。如果它首先需要一个中间步骤来生成文件或其他东西，那么这个优势就没有了。第二件事是POL （Problem Oriented Language）方面：语言必须是可无缝扩展的。所以，如果一个 FORTH 相似的语言不能编译新词，它就毫无价值。
于 2018-08-08T17:17:52.020 回答