Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SUN.COM!wmb
From: wmb@SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: embedded systems & Forth
Message-ID: <9001030201.AA25703@jade.berkeley.edu>
Date: 2 Jan 90 23:36:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu>
Organization: The Internet
Lines: 51

> fat systems for Unix use.  And, don't be so fast to give
> the argument about being able to simply subset the Unix
> Forth for use in embedded systems.  The assumptions and
> structure of a fat Forth system, unless special care is taken,
> run a little bit too deep in the implementation to be able
> to just strip out major features without a lot of work as well
> as a qualitative shift to the way the language looks and
> feels.

From experience with my own rather "fat" Forth implementations,
I can confirm that it does indeed require care to structure an
implementation so that it can be "subsetted".  However, it is
not really all that difficult.  Furthermore, having taken such
care, the implementation becomes more modular, which has many
useful side effects, such as increased portability and ease of
maintenance.

For example, my "fat" systems have a sophisticated input stream
mechanism, with abstract stream types that resolve to files or
devices or memory or whatever.  However, since the interface between
that and the rest of the system is fairly modular, I can replace
that with a very small "keyboard only" input stream implementation,
or anything in between.


> Perhaps, if we want to see Forth get acceptance with
> the rest of the world, we should make a concerted effort
> to make it very usable for embedded control applications.

Here's the trend that I see:  Most programmers' habits and strategies
are set by the environment that they use on general purpose computers.
Then they tend to want to continue to use that development environment
to write code for the embedded system.

It seems to me that this is causing C to encroach into the embedded
systems world, rather than having Forth expand into the general
computing world.  They may pay a penalty for this, but they are often
willing to pay that penalty in exchange for not having to learn a
new language or environment.  Furthermore, hardware technology keeps improving
so fast that, in many cases, the penalty may be erased in 6 months time.

You can always counter that there will be always be a "lower-end", but
that would seem to consign Forth to an ever-decreasing part of the
market.

My preferred solution is to increase the number of standardized "add-on"
packages.  A "lean and mean" subset implementation can always be built
"from the ground up"; one does not have to get there by stripping down
a fat implementation.

Mitch