CPUs and Forth

["Stephen Pelc" <sfp@xxxxxxxxxxxxxxxxxx>]

Jaap says
> Forth is only easy to use when you're scribbling
> down a small program (as for as I know).
Sorry, Jaap, but this just ain't so. As with all
languages, this is a mangement issue. Anyone who
writes that sort of code is no use as an application
programmer. Some of our customers write very large
(10Mb binary) applications in Forth that have a
15 year history and are used all over the world.
If you want a demo copy, it is available at:
  www.ccssa.com
and is currently planning the largest civil engineering
project in the world. We also have cross-compiler
clients with very large applications, but they tend
to be invisible, being inside ISDN routers and access
control systems and the like.

Other Forth vendors can give you similar case histories.

> I was an embedded systems programmer. A large
> portion of my time was spend on trying to locate
> hardware errors (or getting to know more on
> hardware aspects that weren't documented well
> enough or were documented incorrectly) a small
> portion was spend on just writing things, a large
> portion was spend on thinking about concepts,
> and a very large portion was spend on checking
> code or revising it because of users wishes.
> This requires re-re-re and re-reading the code
> and therefore it needs to be very rereadable.
> 
> I dare you to convince me that (multi-typed)
> Forth has that quality.
This is the same point as above, and the answers are the
same. Large software systems need management, much as
we don't like to admit it. One reason we moved to Forth
was your first point above, the one about hardware errors.
Forth is IMHO the best language for hardware/software
codevelopment because of the interactivity.

On the compiler front, MPE has put in a lot of effort
to develop high quality compilers for Forth. The result
is that our compilers produce code that is 2-3 times
faster than anything else around. The benchmarks are
on our web site, as is a 30 day free evaluation version
of ProForth/VFX.

The VFX compiler development, plus a lot of work on
using Forth as tokenised binary, plus our funding of
the Teesside UTSA stack machine, has given us a good
perspective on both hardware and software for stack
machines.

Our conclusions were, and don't forget that we are a
commercial operation:

a) A successful stack machine must be able to run C
efficiently and must be supplied with a C compiler.
The hardware extensions required to run C efficiently
on a stack machine are not ver great.
b) For the same CPU instruction rate (however that is
measured), the diffence in program execution rate of Forth
and C will not differ much, regardless of whether this
is a stack machine or a register/RISC/CISC machine. The
on chip stacks of the stack machine offer internal
parallelism in the same way as the CISC/RISC register
file. I'm leaving out any discussion of VLIW.
c) Currently, peak CPU bandwidth (1GHz or so) is running
at about 10 times the memory bandwidth (100Mhz or so),
so memory interfae and code density are limiting
factors, which is where MISC comes in.

The reason for this is that a stack machine usually
has to execute the stack operations, whereas in a
RISC/CISC architecture, these are replaced by indexed
loads with a single stack adjustment per block. The
stack machine instructions are 0-address.

The real point about MISC is that it uses a minimal
set of very short opcodes, which should give very good
code density. Since the world is now communication
oriented, my Forth CPU would be 32 bit and byte
addressed. However, my point here is that MISC is
an interesting slant on CPU design.

--
Stephen Pelc, sfp@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeltd.demon.co.uk