我希望我告诉你的话能够使你写出好的 Forth 。我可以证明。我已经证明了应用程序代码可以减少 90% ，在某些情况下可以减少 99% ，我可以做，但是需要一个案例一个案例地做。我一直找不到一般性的原理。

(Jeff) 我有一个问题是有关你 COLOR Forth 屏幕的。人们已经注意到你在屏幕上使用了很大的字体，但是只有较少的信息。它多少是由于你的视力？你每次看的时候有多少的信息受到限制？

(Chuck) 我对小字体越来越没有耐心，几乎不能阅读网页。直接去看那些字符模糊不清，戴上眼镜看，它们还是模糊不清。如果加大字体，这有时能够做到，有时做不到，会失去一些上下文。这是一个问题，可能对于大众中不断增加的群体来说都是一个问题。所以我尽量地使用大的字符，但是如果你把它们弄得太大，那你就会丢失信息。

现在一个用于设计幻灯片翻页的经典规则是你拾取一帧然后在其中放入一些主题，你不能在一张幻灯片上放太多的内容，否则你的听众就会糊涂，如果你使用太小的字符，人们就不可能阅读这些内容。

在 COLOR Forth 的情况下，我想字符也可能太大了。我可以一次在一个屏幕上得到 256 个字符。根据所使用计算机的不同，我可以得到 20x14 或者有时是 24x15 。这就足够了。在 256个字符中，我得到的信息大约与过去 1024 字节得到的信息一样多，因为我没有进行格式化，甚至没有任何的换行。在我的屏幕上充满字符。

一个原因是我想探究彩色字的价值，如果我有一些带颜色的字，那么不同的颜色将如何工作？我发现它们做得好极了，我不需要用定义字来格式化它们。当然，实际上并不好看，因为在屏幕的左边好象有一个红墙，如果你也使用这种方式，那就不一定非使用红色不可。

我觉得你在做一个网页时也应该使用这种哲学。在网页上放入尽量少的信息，只要能把你想告诉人们的事情说清楚就可以了，不要弄得费话连篇。另一方面是不要在页面上放一个索引。你只应该放入真实的信息，你需要把重要的信息加亮，你需要使它清晰和可读。

要改变我的字体比较困难。我使用 32x32 像素点。下一次我可以使用 24x24 像素点试一试。

这种格式的应用程序很少是一个屏幕。一个应用程序大约是 2 个或者 3 个屏幕长，这与我在一个上下文中为一个应用程序所写的代码相当。

例如，我有一个应用程序，它把一个特殊芯片性能的谱显示在屏幕上。这是一个漂亮的显示，对于把信息表示成可理解的方式是一个很好的练习和重要的方法，如果以后你有机会看到它的演示，那一定是很有趣的。

小的应用程序。应用程序不是适当的字，小的代码只做特别的事情，从来都不做通用的事情。

Jeff 使我想起了 Machine Forth 的另外一些概念。 Machine Forth 是一个我很愿意回忆的 Forth ，它使用在机器中构建的 Forth 原语来做一些事情而不是使用解释器版本或者宏定义来做这些事情。这些事情之一就是 IF 。

经典的 IF 去除留在堆栈上的东西，这在 i21 上实现并不方便，所以 IF 把它的参数留在堆栈上，于是你就不得不经常写类似 IF DROP 这样的结构，但也不总是这样，看起来似乎方便和不方便各占一半。它不再使用 DUP IF 或者 ?DUP ，也就是说有了这种方便性，就不用 ?DUP 了。 ?DUP 并不是个好词，它在堆栈上留下了不同数目的东西，做这样的事情很不明智。

IF

-IF

除了 IF 之外， Machine Forth 还有一个判断 -IF 。这个字用于测试 0 ，那个字只用于测试符号位。我想你可能经常需要根据一个数是正还是负的来进行决策。但它并不是以那种方式工作的。在 COLOR Forth 中，我甚至不关心它怎么使用。

在过去的二十年中，世界已经发生了明显的变化，但我想没有人能够预测出来，当我 50 年代第一次开始工作时，只有 7 台用于计算的计算机。那时的计算机总是用来解决又大又长的算术表达式。我们所做的因子化工作就是把这些事情因子化，使得这些不必重复计算，它就可以运行得更快，那就是 FORTRAN 语言的全部观点。这种传统甚至到了今天还在影响着我们。

我没有做过统计，但是我猜想今天的计算机，绝大多数都不是用来做计算的，而是在移动字节。如果你有一个浏览器，这个浏览器除了一次性地计算机屏幕的大小外，几乎不进行什么计算。查看一个数的符号的概念可能并不像我想的一样有用，几乎所有的数都是正数，并不需要查看它们的符号。基于同样的原因， Machine Forth 没有减法操作。我把减法处理成 1 的补码。

- one comp

这种做减法的方式并不方便。但是对于今天的应用来说，实现协议或者显示文本，算术运算是不需要的。一个计算机不应该为算术运算进行优化，我的计算机也不是。

另一方面，为了数据传输方面的优化，实现一个增量存取操作就很有用。地址是在任何计算机上都有的问题，但在 i21 上这是一个更特别的问题。在 i21 上，地址是一个 20 位的数，为了装入一个地址，你最好做一个文字常量的取，它可以取出 20 位的扩展字。需要一个附加的存储器装入周期，之后你可以进行存储器读取，这又需要另外一个存储器周期。所以地址的处理非常昂贵，你应该尽力使它最小。取加 (@+) 操作字对此有所帮助。你把一个地址放入地址寄存器中，然后它就存在那里。如果你执行 @+ ， A 将被增量，你就可以连续地读取后面的内容了。同样，你也可以存入一串东西。当然在需要的时候，你还有不进行增量的取 (@) 和存 (!) 操作。

在经典的 Forth 系统中并没有这些操作，我想在标准中也没有提及。它们导致了一种完全不同的程序风格。在 DO LOOP 的情况下，最有效率的事情就是把实际的地址作为循环参数，然后通过字 I 读出它，在循环内部进行对 I 的取 (I @) 。 DO LOOP 与地址一起工作，如果你做这些，如果你使用读加操作 (@+) ，那你就不需要 DO LOOP 了，你也不需要 I 了，你在循环中使用读加 (@+) 就可以每次读出不一样的事情，它们不同但是等效。你可以把一个转换成另一个，方便地读取那些地址在 A 寄存器中的东西。

在 MOVE 的情况下，你想把某些东西从存储器的一个区域移动到另一个地方，你就需要两个地址，因此作为地址的值存储在 R 寄存器中，因为只有在一个上下文中你才可能把地址放到 R 寄存器中，它有一个自动增量能力。所以我基本上有对于 A 的取加 (@+) ，对于 R 的取 R 或者存 R ，你可以有效地进行 MOVE 。

这就引出了另一个问题。 A 除了作为地址寄存器使用外，它还非常像一个局部变量，你可以在其中存一些东西，过一会儿再读出来。把它作为一个地址寄存器的原因和我使用它的原因是一样的，从字面上讲，它为地址访问提供了一个机制（ (@+) 。从程序员的角度看，它比放在堆栈上的地址更方便。但是如果你准备反复地访问这个寄存器，就必须把它放在一个你可以对它进行增量的地方。为了放置它你必须访问那个寄存器，如果你能够做到这些，你就可以使用这个寄存器做别的事情，就像你使用返回栈做别的事情一样。

不同之处是如果你把一些东西放到返回栈上，还必须记着把它拿下去，对于 A 寄存器就不用这样了。有人试着把 A 作成一个堆栈，使得你可以把一些东西 PUSH 进去或者 POP 回来，是不是值得这样做并没有一个明确的答案。肯定需要更多的指令去访问 A 。你希望 DUP A ？你需要 DROP A ？现在这种 A 的方式是最容易的。

我也许还需要一个寄存器称为 M ，可以在 40 位的乘法中保存一个乘数。但是我的系统中并没有足够多的乘法要做，所以这件事还没有成为现实。

但这样一个寄存器却引出了一个局部变量的问题。有许多关于局部变量的讨论，这是在你的应用中能够节省 100% 代码的另一个方面。我坚信局部变量不但没有用，而且很有害。

如果你正在编写需要使用局部变量的代码，那么你就是在写……非优化的代码？不要使用局部变量。不要出现新的语法来描述它们，不要出现新的策略来实现它们。如果你有局部寄存器你就可以使得局部变量很有效，但是不要这样做。它不好。它是错误的。

变量是必要的。 COLOR Forth 需要许多的系统变量，当你编辑某些东西的时候，光标位置变量也非常有用。当你回到光标位置的时候，因为变量的值还在那里，所以你就能够回到原来的位置。变量很有用，我没有看到任何只使用少数变量的情况，也没有看到使用瞬时访问变量的情况。

聪明、解释堆栈图、给一个字命名，这些都是练习。你可以进行所有这些游戏。我想 Forth 程序员可能用他们已有的工具进行了太多这方面的游戏，因为没有应用。如果一个 Forth 程序员能够更多地关注应用程序而不是更新工具，那就更好了。

对于我来说，一个应用程序就是 Web 浏览器。如果你无事可做，那就写一个浏览器。 Netscape 并没有完成这件工作，没有做到它应该能做到的样子、没有实现它应该有的功能，。事实上 Netscape 和 Microsoft 都从 Mosaic 那里借用了大量的东西，它们看起来就像是孪生的东西。如果还是用同一种语言编写的，那种语言就是 FORTRAN 。

写一个新的浏览器。这是一个很好的应用。它能够使你访问信息世界，我将在业余时间关注这个好应用。

感谢各位的收听。

评论