[MachineForth] [Nosc] 25x Forth engine

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

David K Walker wrote:
> 
> 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.
------------------------

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.