[MachineForth] [Nosc] 25x Forth engine

[David K Walker <dkwalker@xxxxxxxxx>]

At 06:53 AM 11/26/01 -0800, Andy wrote:
In another note
>(groan from the list) I'm going to sketch out a packet processing design
>based on the 25x.  It'll test state size, peripheral capacity, and interior
>bus bandwidth more than the math crunching aspect of DES.

After reading Andrew McRae's "toaster" paper earlier today, I think packet
processing is more interesting than DES since it would take up issues of
scalability in the dataflow architecture.

About code size, I think Chuck may mean that "the interesting programs"
seen from his point of view are what we would normally view as "very
small", and what seems interesting for him is precisely those small
programs that are relevant to optimizing microcode in a way that will
(ultimately) reduce the size of larger programs.

E.g. my 256 kbytes of Forth code for administrative systems is (apparently)
extravagant by Chuck's criteria, but probably more accurately described as
uninteresting for him since it is not relevant to optimizing machine cycles
or parallelism in general.  However the fact that it is written in Forth
(actually Forth-83, Laxen & Perry style, with a conditional compilation
alternative for Novix processors) means that I can return to it as (as many
times previously) and continue to factor it.  So I interpret Chuck as
saying that you can factor any size code into independent networked
programs, each with no greater total memory requirement than 256 18-bit
words.  The separate programs can then function relatively independently in
a packet-switched networking environment (on chip and external to chip,
both) depending on the memory and pipe drivers.  This I see as a discovery
not so much about parallelism and microcoding, as a discovery about
packet-switching.

Thus Andy's comments about contention and (dealing with) the risk of
deadlock, and scaling, seem key to this direction of development.

Seen from a completely different point of view, more in line with my other
interests, there are very many potential applications in networks provided
we can process packets at 10 Gbps in such a way that we either do not need
buffers (cf. Andrew McRae's paper) or we can somehow (I know very little
about memory addressing) context switch very rapidly to buffers.  A main
point that I see about Forth, particularly after repeated factoring (see
earlier), is that you can write (as in my administrative system) code that
has a very small context because it is a stack-oriented language.  In
another (non-Forth) project (time series report generation) I used
Forth-like architecture with heavily structured relatively large stacked
items as the arguments, with a small number of verbs (about 25) that do all
the work needed entirely within this framework.  It is easy for me to
imagine stacking the various kinds of data packet as such, and also easy to
refer indirectly not only to the each entire packet as stacked without
moving it in memory, but also (alternatively and more interesting) to each
packet's encapsulated data packets from higher layers in the OSI 7-layer
model.  Which would enable application-oriented pocessing at near
wire-speed for content-based caching (e.g. WWW caching, or SQL caching)
and/or QoS based on the various perspectives of the upper 4 layers of the
OSI model.  E.g. encryption/decryption at layer 6.  This leads rapidly to
Jeff's mixture of software/hardware being able to deal with packets at
layers 4,5 and 6 much as in the "toaster" story but potentially with more
general computing power and hence greater flexibility with shorter time to
market.  

Why do we get more general computing power than McRae ?  Because we have a
smaller context to switch, and we have experience in factoring major
applications and may ultimately reach down to the small program size
focused by Chuck (which he seems to have reached for 0KAD after focusing on
10 bit addressing earlier, a matter of experience).  And because Forth
programs are generally smaller anyway for any given application (probably
because they are better factored?).

Anyway, that is why I would be interested to hear more about
packet-switching and drivers, with the proviso that it is interesting to
link in compute-intensive stuff that can be done (possibly in steps) within
Chuck's criterion for code size.

David


------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe MachineForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main Machine Forth site   -   http://www.