Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: FORTH and memory
Message-ID: <1530@crete.cs.glasgow.ac.uk>
Date: 26 Jul 88 13:45:14 GMT
References: <ZMLEB@SCFVM> <8807211846.AA27919@jade.berkeley.edu> <9428@dartvax.Dartmouth.EDU> <2353@pt.cs.cmu.edu>
Reply-To: orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 48

In article <2353@pt.cs.cmu.edu> ns@cat.cmu.edu (Nicholas Spies) writes:
>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...
>

This is most certainly true, but the point I was trying to make is that
memory is much cheaper than programmer time. I agree that memory should be
used as sparingly as possible (one point you didn't mention is that on systems
with virtual memory overuse of memory can cause performance problems), but it
is my contention that memory usage and (as I mentioned before) speed considerations,
should only be the concern of the compiler not the programmer. 
If this is so then the programmer can concentrate on space and
time efficient algorithims rather that detailed implementation problems.
(Surely everyone has heard the story of the programmer who was very proud of
his sorting routine written in assembler, that he had spent ages cutting one
microscend of the inner loop here, and 23 microseconds off the loop preamble.
what he forgot to mention was that it was a bubble sort, because n.log(n) sorts
were too hard to code in assembler:-)

>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.
>

     This is certainly true.. One of the things I always liked about 
forth was the way common functions were shared amongst all the `programs' 
on the system. I think though, this idea could be moved to high level 
languages. Indeed in UNIX this the system calls are shared amongst all
programs in the kernel. 
There is no reason why this could not be extended so that you had a 
`super kernel' with stuff like stdio, the maths library etc, in it. So you
would have the advantage mentioned above by having every machine on the 
network preload both the kernel and the `super kernel' and locking them 
in memory.
This of course could be extended to other operating systems and languages.

==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK)
UseNet: {uk}!cs.glasgow.ac.uk!orr       JANET: orr@uk.ac.glasgow.cs
ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk