Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!oberon!bbn!rochester!pt.cs.cmu.edu!cat.cmu.edu!ns From: ns@cat.cmu.edu (Nicholas Spies) Newsgroups: comp.lang.forth Subject: FORTH and memory Message-ID: <2353@pt.cs.cmu.edu> Date: 22 Jul 88 08:42:04 GMT References: <8807211846.AA27919@jade.berkeley.edu> <9428@dartvax.Dartmouth.EDU> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 36 The argument that FORTH is less desirable because large amounts of memory are now common, is one-sided. Sure, FORTH is no longer the _only_ way to make toy, home computers do useful work without resorting to assembler, but the fact that Megs of memory are now available to be squandered doesn't make it virtuous to do so... Case in point: work with HyperCard on the Mac (which requires 750K) sometimes boggles my mind, in that it uses 15 times the memory required by my old MMSFORTH system on a TRS-80 Model I (48K RAM). On the Trash-80, the FORTH was the operating system (another 256K of ROM on the Mac, plus 100+K of system file). I regularly had in RAM a tracing Z-80 disassembler, an editor with a ring buffer (good for outlining), and other stuff, with about 30K left over. Compare this with the peculiar manner in which HyperCard stacks balloon to several 100K over their nominal size on disk, requiring periodic compacting, which otherwise wastes gobs of space--more than the total space that I had with the 80, even with 3 floppies. Granted, I'm getting far more (graphics, sophisticated glitz) now than before, but I sometimes wonder how much more I am missing because the Mac OS wasn't written in FORTH. I suspect, alot. Consider also, that with networking becoming a much more important aspect of computing, that program bulk becomes again a real problem, for a bogged down network it often percieved as worse than no network at all. In this case, the performance of threaded vs. unthreaded code must include some thought of overall system throughput, not just the time it takes a single CPU to munch through code. How much better it might be to install on each machine on a network a threaded dictionary of routines, whose execution time might be slower, but which could be invoked by the few characters of a FORTH word rather than heroic block moves of object code. Summary: Small _still_ is beautiful. :-) -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University