博文
Forth 这个东西(14)(2005-08-05 15:42:00)
摘要：发信人: TwoO.bbs@csie (O-O), 信区: programming
标 题: Re: Forth v.s. 软件工程
发信站: 交大资工天龙新闻社 (Tue Apr 26 16:38:54 1994)
转信站: cis_nctu!bbsroute!crosspost
Paladin (PaladinMu.bbs@bbs.cis.nctu.edu.tw) wrote:
> FORTH 语言本身对于软件工程中所谈到的问题, 如模块化,
> 耦合, 结构化等, 使用什么方式来达成呢?
> FORTH 有 OOP的 extension, 但是我想问 FORTH是否使得
> OOP 的实作更容易.
模块化 --- 你可能找不到比 Forth 更模块化的 language。一个 word 就相当于一个 function；一个词汇就相当于一个 library。
结构化 --- 和一般高级语言差不多，只是写法有点不同。
其它的我自认了解不多，请知道的人回答一下。
--------------------------------------------------------------------------------O-O (二轮族) ---> 我想买一台装 PPC，执行 OS/2 的摩托车
==============================================================================
发信人: Alpha@miluku (<< 魔 符 >>), 信区: programming
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: 交大电子_BBS (Wed Apr 27 12:15:14 1994)
转信站: cis_nctu!bbsroute!miluku
......
Forth 这个东西(13)(2005-08-05 15:40:00)
摘要：
发信人: william (C++/ASM/Win Master), 信区: 'programming'
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: 交大资科_BBS (Apr 26 08:50:07 1994)
==>[Author]: TwoO.bbs@csie (O-O) on board 'programming'
> 问题是 ...... 在 Forth CPU 上，高级语言(Froth) 等于 汇编语言(Forth)；
> 但是在〞其它芯片〞上，通常 高级语言 不等于 汇编语言。
> 你希不希望写程序时有高级语言的方便迅速；执行时则有如纯汇编语言写成般地
> 快速、有效率？
最近看了看 ANS Forth 规格, 想请问一下：
1. PC 上有无合乎 ANS Forth 的 implementation? F-PC 似乎还没有, polyFORTH还没仔细摸。
2. ANS Forth 中看到一些 catch, throw 之类的东东, 好像和 C++的 exception handling 差不多。有没有人试过?
3. 在 asm中发展新程序, 有个头痛的地方：常会当机, 所以在 run 或 debug 之前,往往都会先 save 程序, 以免一当机心血就泡汤。不知在一般的 Forth环境中,有无对于“当机防护”做较好的处理? 因为我知道 Forth有低阶的一面, 在 Forth中夹杂 asm也是常事, 若是在 run之前都要把 words 先存起来 (Forth 会自动将words 存到dictionary FILE 吗? ) 的话, 似乎不太亲切。
------------ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ≡ 何陋居 ≡ 圣人, 吾不得而见之矣... 论语‧述......
Forth 这个东西(12)(2005-08-05 15:39:00)
摘要：发信人: syc@cc.ntu (Shiau Yong-Ching), 信区: programming
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: National Taiwan University (Mon Apr 25 11:54:32 1994)
转信站: cis_nctu!bbsroute!crosspost
Daemon of Andromeda (lmy.bbs@bbs.cis.nctu.edu.tw) wrote:
> 我没学过 Ada, 不了解其架构与堆栈框建置. 但 C 至今为何没听说 (可能是我孤陋
> 寡闻) 类似的商品化 CPU, 我想可能有根本上的困难.
有啊，好久以前 (一两年前) 杂志上曾经报导过 AT&T 有发展 C chip 的计划 (忘记它的名字了，不过他的锋头大概被最近的芯片大战抢光了)
===================================================================
发信人: Drifter@Maxwell (我和周慧敏生日同一天), 信区: programming
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: 台大电机 Maxwell 站 (Mon Apr 25 13:09:10 1994)
转信站: cis_nctu!bbsroute!Maxwell
> epilog, prolog等, 都是 overhead. 用 forth chip 时, 这些问题都被消除, 你可以
> 这样想, 该chip 的machine language 就是forth, 这些 overhead 在芯片设计时就
> 被消除. 此外, 该芯片最多可以并行三个 machine instruction (尤其是返回指令
> EXIT) 一般高级语言用function call 虽可以增加模块化, 却增加了进出的 overhead,......
Forth 这个东西(11)(2005-08-05 15:37:00)
摘要：发信人: lmy@cis_nctu (Daemon of Andromeda), 信区: programming
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: 交大资科_BBS (Apr 25 09:30:44 1994)
转信站: cis_nctu
==>[Author]: william@cis_nctu (C++/ASM/Win Master) on board 'programming'
> 对时序要求如此严格的场合, 应该都是用 asm 吧? 毕竟高级语言也不是万能的。
> 即使是 Ada, 在做 embedded system 时还是要动到 asm。
不见得, 我以前的论文是有关语音辨认的辨认速率问题. 再怎么要求 real-time也没有人会想用 asm. 除非是 critical function, 像我学弟就 K了 DSP32 的 asm,拼了命写了一个. 在没有良好的发展系统上, 这样做非常痛苦. 但若是有良好的发展系统, 相信我, 语音辨认的 algorithm 用 asm 去 implement 一样不是一件很聪明的作法. 即使我们最新的方法以将浮点运算数目从 1百多万/每字 降至 数万余/每字,用 DSP32 仍只能勉强 real-time, 但仍然不会去尝试用asm 来 implement 全套系统.目前仍然是用 该芯片的 C cross-compiler. 但其compiler最佳化不是很好. 如果能有高级语言能达成速度不输 asm, 那不是大家的希望吗?
> 这是自然的, 用各 CPU 的母语来写程序, 自然最好。没听过在 Lisp machine 中的
> C 程序能拼过 Lisp 的。
> 问题是：若是在非 Forth chip 里, Forth 该如何避免这种 overhead? 我很感兴趣。
我的意思不是这样比, 我的意思是用同样的频率 (这代表了目前的芯片及高频电路技术), 以及同样的 BUS 架......
Forth 这个东西(10)(2005-08-05 15:35:00)
摘要：发信人: lmy@cis_nctu (Daemon of Andromeda), 信区: programming
标 题: Re: 大发现!! FORTH 无所不在!!! :))
发信站: 交大资科_BBS (Apr 24 10:53:46 1994)
转信站: cis_nctu
==>[Author]: mr814305@g814305.hung.ab.nthu (Hong-Yung Lee) on board
> 我不知你们的 real-time 定义如何, 但我隔壁化工所室友的整套蒸馏塔监控程序,
> 就是用 QBASIC 写的. 这提供你们一个参考.
我相信 BASIC 来应付蒸馏塔监控程序没有问题. 因为该系统的瞬时及稳态响应的变化速率应该在 BASIC 能够应付的能力之内. 但如果更快的系统, 可能连 C都无法应付, 而须用汇编语言. 数字控制有一个基本要求, 你的取样及处理频率, 必须大于 2倍的系统自然频率以及外加驱动频率, (也就是受限于 Nyquist rate 的取样定理) 否则系统将无法 stable, 或是 steady state error 会太大.
用高级语言在最佳化的瓶颈就是许多缓存器被用掉去 keep 一些 virtual machine的状态, 如堆栈框, loop count等, 导致最佳化时自由缓存器不足. 还有堆栈框的epilog, prolog等, 都是 overhead. 用 forth chip 时, 这些问题都被消除, 你可以这样想, 该chip 的machine language 就是forth, 这些 overhead 在芯片设计时就被消除. 此外, 该芯片最多可以并行三个 machine instruction (尤其是返回指令EXIT) 一般高级语言用function call 虽可以增加模块化, 却增加了进出的 overhead,C++ 的 inline 虽有部分效果, 却无可避免的增加 size overhead, 对 program......
Forth 这个东西(9)(2005-08-05 15:34:00)
摘要：发信人: OhiYooo@cis_nctu (pie), 信区: programming
发信站: 交大资科_BBS (Apr 23 02:32:47 1994)
==>[Author]: johnchen@csie (Chien-Hung Chen) on board 'programming'
> pie (OhiYooo.bbs@bbs.cis.nctu.edu.tw) wrote:
>> 也许只有像 NOVIX FORTH chip 这么快速的 CPU 才有足够的能力, 和速度
>> 对这么快速扫瞄 (1 KHz) 的 ion beam 做最佳的 "实时" 控制吧!! :)
>> 下次进去 NDL FAB 做实验时, 不要忘记多看 E220 几眼哟!!! ;-)
> 我不是 NCTU E.E. 的同学, 但我想看一看那一台 ion implanter (VARIAN E220)
> 不知道可否有机会亲眼目赌 NOVIX FORTH chip 它的风采!?
> 因为我手头上就有 NOVIX FORTH chip的板子, 总是不晓得该把它用在何处!?
在 Varian E220/E500 ion implanter 中, 我想会使用 FORTH chip 的主要原因, 除了他速度快之外, 另外一个原因是 因为整个主计算机的控制程序是用 FORTH 写的!! 所以为了方便, 当然是用 FORTH chip 来做最重要部分的控制啰!!
:)
对了!! 整个 ion implanter 是个庞大且复杂的系统, 好好玩哟!!! :))
我想我们可以利用 FORTH chip 在物理化学的研究仪器上!!
我以前是作物里实验的研究生, 当时我们 set-up 实验室就曾遭遇到困难...
我们主要是要去测量一些核子反应所产生的事件, 记录并计算之!!
但是核反应事件发生的时间约为 1e-6 秒, 使得事件发生的频率太快!!
界面的......
Forth 这个东西(8)(2005-08-05 15:32:00)
摘要：发信人: TwoO@nctu_csie_bbs (O-O), 信区: programming
发信站: 交大资工天龙新闻社 (Sat Apr 9 11:28:53 1994)
Open Firmware (IEEE P1275 启动韧体标准) 的设备接口〞不仅提供让适配卡独立于 CPU 之外的机制，同时依赖一种语言来达成这个目的 ---Forth。〞 因此可以预期的是，有些为适配卡或主机板写 ROM program的工程师必须开始学习 Forth。
〞目前，Apple、IBM、Motorola、及 Sun 已带头跳上 Open Firmware的列车〞。 IBM 为 PowerPC-based 兼容系统定义了 PReP 规格，而〞PReP 策略目标之一就是要支持开放韧体 (Open Firmware)；IBM 将其 PReP 兼容系统的启动码放入快闪式内存 (Flash ROM) 的理由之一，就是为了将来可以容易地升级到 Open Firmware 标准。〞 另外
，〞PCI 的适配卡只读存储器规格将 Open Firmware 的 FCode 定为一项可行方案，也是唯一能真的独立于 CPU 之外的可行方案。〞
当 Open Firmware 成为业界标准时，其本身也会成为 Forth 发展史上重要的里程碑。
==================================================================
发信人: Alpha@phoenix (- 蓝 苹 果 -), 信区: programming
发信站: 交大资工凤凰城信息站 (Sun Apr 10 11:08:52 1994)
> 有那位高手, 能不能介绍一下 OOP FORTH ? :) key point 在那呢??
让我们来炒热这个话题吧!
OOP FORTH 见过的大致有三种方式, 只有一种是在 PC 上看到的, 可能是因为8088 的分段实在太龟了, 又缓存器太少......
Forth 这个东西(7)(2005-08-05 15:29:00)
摘要：发信人: johnchen@csie.nctu.edu.tw (Chien-Hung Chen), 信区: programming
发信站: 交大资工 News Server (Wed Apr 6 13:24:38 1994)
Hi, all Forthy :
我觉得 Forth很流行呀! 我自己本人就有各种不同版本的 Forth Systems.Super8, Z80 eforth, 8051 Forth, 68K forth, and NC4000. 不过, 我接触 Forth 这么久以来, 我发现使用它的人愈来愈高竿, 用得越多, 越是
绝口不提 !
像我应用 Forth 来发展 8051 的系统. 我绝对跟别人说是用 Assembly 写的, 免得他人问东问西的 !!
======================================================================
发信人: lmy@cis_nctu (Daemon of Andromeda), 信区: programming
发信站: 交大资科_BBS (Apr 7 10:20:53 1994)
8051 Forth 我没用过, 倒是用过 Super8 Forth, 似乎是 F83 的 kernel 改过来的. 12MHz 的 S8 Forth, 跑得比我那 16MHz PC 286-AT 上的 F83 还快, 这是意料中的情形.
我觉得在迷你系统中要快速地 porting 一个交谈式的系统, 具有强大的硬件控制以及软件开发扩充能力, Forth 是最佳地选择. 也就是说, 在单芯片的世界中,我个人觉得 Forth 将是 porting effort最小的. (甚至在还没有很好的 assembler之前, 就可以有 meta-compiling 所产生的 Forth 系统了, Super8就是很好的例子,从头到尾, 我不必用它附的 assembler, 因为 Fort......
Forth 这个东西(6)(2005-08-05 15:25:00)
摘要：发信人: 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 在 ......
Forth 这个东西(5)(2005-08-05 15:25:00)
摘要：
发信人: ajax@phoenix (ajax), 信区: programming
发信站: 交大资工凤凰城信息站 (Sat Apr 2 08:59:46 1994)
==> 在 TwoO@nctu_csie_bbs (O-O) 的文章中提到:
>> 太依赖 stack operation, 缺乏自然;
> 其实 Forth 的 word 相当于 C 里的 function，可见 Forth 的高度模块化。
> 各模块间要有一致的传递界面，最理想的是什么？ 答案是 Stack。 在一般
> 的模块化语言中，大多也都是用 stack 来传递参数，传回值有些虽不用 stack
> ，但却因而有传回值个数的问题。
> 在做运算时直接以 item in stack 做为 operand 有什么好处呢？ 在硬件上
> 可以少掉 operand 的 encode/decode，在软件上由于不用在 compile(/link)
> 时去计算 operand 的地址，速度变得很快，也因而使 design->coding->test
> 这个发展循环变得非常快，并使得 interactive develop 容易达成。
> PS. 在 C 中要测试刚写好的 function 正不正确有多麻烦，大家应该都印象
> 深刻。 如果等到程序全写完时才测试，结果就不用我说了。
其实用 stack传参数最大的好处是很容易做到 reentrance, 因此 Forth很容易加上 round robin 的 multi-tasking 功能, 但是 stack的处理可能得留心些, 一不小心就留下一堆垃圾或 underflow.
interactive develop 的环境实在太棒了, 尤其是在搞 emb......