发信人: TwoO@nctu_csie_bbs (O-O), 信区: programming
标  题: Re: Forth为何不流行?
发信站: 交大资工天龙新闻社 (Sun Apr  3 01:29:49 1994)
转信站: cis_nctu!bbsroute!news.csie!nctubbsgate!nctu_csie_bbs!TwoO

C++/ASM/Win Master (william@cis_nctu) wrote:
>> 各模块间要有一致的传递界面，最理想的是什么？  答案是 Stack。
> 在 PC 上, 有些 compiler (如 Watcom C, BC+ 3.1 以后) 就提供“缓存器传参数”
> 以提高效率。而许多 RISC 更是如此。

这种 "缓存器传参数" 的方式虽然对高级语言的移植性没有影响，但程序设计师在混用其它语言时却要付出额外的心力去掌握及确定 compiler 的行为特性。以最简单的混用汇编语言来说，你必须知道 compiler 固定或甚至动态的用哪一个缓存器来传哪个或哪类的参数，有些甚至是文件中也没有说明的。  而且当你换一种 compiler 时，这些规则可能又变了（尤其是那些文件中没有说明的）。
例如，BC++ 中将 object 的地址放在 SI 里传送，这永远不会更改吗？ Watcom C/C++ 又用什么来传这类的值呢？

这种作法虽然加快执行速度，却有可能加重 compiler 的负担（同时也使愈短愈好的发展循环又更长了），并且也失去了〞一致性〞。  另外还可能额外地增加程序设计师的负担（这负担不仅沉重，也不是每个程序设计师都能负担得起的）。  程序的速度并不代表一切。

> 所以我质疑的是: Forth 在“原始程序”层次就极度仰赖 stack operations,
> 不知这样是否自然? 这是以 programmer 的角度来看的; Forth 在 implementation
> 上, 是否也真的高度仰赖 stack? 会不会降低效率? 还是说 Forth私底下会自动
> 像 compiler 一样, 为个别的机器做个别的最佳化处理? 这是以低阶角度来看的。

Forth 本身是以 stack machine 的方式在运作，如果你觉得 stack 自然，Forth 就自然。  :-)

现今大多的 CPU 和一般的高级语言是属于〞互为因果〞的关系。  Forth不同于一般高级语言，因此在与一般高级语言相辅而生的 CPU 上，难免有点绑手绑脚。  但是在此类 CPU上，其速度却仅次于汇编语言（可参考Forth 有关书籍的 benchmark），所以你大可不必担心是否降低效率（其实，不论你用那种语言，程序的效率大部份是操在你自己的手上。  Forth让你更有效率地发展程序，但是，该是你自己的，你还是得自己掌握）。

至于 Forth 系统对个别系统的最佳化则取决于建立或移植的人。  如果你硬要用缓存器来传参数，也没人拦得了你，顶多只能认为那没有〞Forth精神〞而已。

> 如果我们用的是 Forth hardware 或 firmware, 就像 Lisp machine 那样的
> embedded, 我不怀疑它的效率。但如果是在传统的机器上, 所有你提到的那些

如果我没记错，第一个 LISP 系统是用 Forth 写的。  Forth 也有他自己的 CPU (NOVIX)，该 CPU 的〞汇编语言〞就是 Forth。  只要是 stack machine，Forth 就可以〞如鱼得水〞、〞有如天助〞。

> operand 的部份都是 CPU自己处理, 不劳最后的执行档费心 (当然, compiler
> 会累些, 但以现在的技术而言, 这也不会“太”费事) , 所以执行档可以近乎该

传统语言的 compiler 实在占掉太多的发展时间，对一大块一大块的测试方法（否则你要花更多的时间去等 compiler），我更是感到相当厌倦。  :-(

> 机器的全速执行。而如果语言不利用这些现成的资源, 而硬要自己处理, 造出一
> 个 runtime virtual machine, 是否会产生 overhead?

依目前的 Forth 系统来看，Forth 在这方面做得还不错，否则也不会在一般的处理器上只输给汇编语言（请注意，各个 Forth 系统间仍可能会有极大的速度差异 ... Forth 系统的建构方式实在太多了）。

>> 习惯靠左开车的人对靠右开感到不适应。  这还只是习惯的问题，两着间并无
>> 好坏之分。  但若因为习惯而错过了更好的东西，那就不值得了。
> 的确。不过高阶的语言不就是希望语言适应人, 而非人去适应语言?

你的习惯是由你所学过的语言而养成的，并不是你天生的。  当你去学 LISP、PROLOG、Parallel Programming、Data Flow ...... 时，你的习惯也是会渐渐的养成或改变。

我倒觉得各个高级语言是为了解决某类型问题或做某种应用，而产生的。

> 我知道 Forth的语法也可改成 infix等等, 但不知道这会不会影响 runtime 效率?

只是 interpreter/compiler 必须做点修改，Forth 还是以 stackmachine 的方式运作，runtime 效率又怎么会受到影响呢？

> 有人以 Forth做出 OO, 我知道, 但还是和 C++ Eiffel 等等相去甚多。
> 近代程序型语言多要求 static scope, 但 Forth?
> 其它的地方待我想想...

这些东西也是为了需求而生的。  谈到 OO，我自己认为只要加强 abstractdata type 就可以了，但是与他人一起写程序或为了他人便于修改时，我却会完全依照 OOD/OOP 来写程序。  因为，OO 对我也许没有多大用处，但对
他人却可能大有帮助。

Forth 对这类问题也有体认，他承认自身的〞不完整性〞，给你增修的空间及能力（也因此，Forth 是最具变动性的语言，也就难以定出标准）。  当使用 Forth 的人需要某种东西的时候，他就可以在将其加到 Forth 上
（Forth 的〞延伸性〞）。  而且，由于〞语言与系统合一〞，更使得增修的工作变得直接、容易。  用 Forth，你不必老是等待别人。

> Forth 在 develop 上的成就无庸置疑。但如同我前面所提的, 我质疑的是
> final runtime。

还是那句话，Forth 只输给汇编语言。  :-)

> 软件生命周期不能只考虑发展阶段呀!

软件生命周期中和程序设计师有关的有那些？  只有发展阶段和维护（增修），其实也是 design -> coding -> test，不是吗？  你也认为 Forth 在这上面做得很好。  至于其它如新观念的导入、推广、销售 ... 等，又有那种语言能帮你呢？  （不过当你需要某种东西，而别的语言无法支持时，你却可以轻易的修改你的 Forth 来满足你的需求，而不用等别人出新的 compiler）。

凡事都有其精神所在，取舍之间，得失之别，全在自己。

评论