[MachineForth] [Nosc] 25x Forth engine

[Andy Valencia <vandys@xxxxxxxxx>]

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx> writes:]

>...
>As we would hope it is almost like changing a do loop
>from 5x5 to 7x7 or to 5x10 or to 100x100 and then 
>agreeing to pay for prototype and/or production chips 
>of that size.

Of course, scaling becomes ever more of an issue here... even given your
idea of using I/O pins off more sides of the array to access more memory,
the interior to exterior ratio continues to degrade as you scale up.  At
some point in the curve, those shared vertical and horizontal buses should
even cross the point of becoming the bottleneck before the peripherally
attached RAM!  You've already mentioned private neighbor connections, and
those will become ever more critical as you scale up.

But I'm guessing that for the 5x5 array at hand, the buses will not be the
first or second bottleneck.

>> What happens if two CPU's write at the exact same moment?
>I would assume that either both get blocked if both hit on the
>same 80ps cycle or the chip favors left or up or something.  The 
>spec has not been publised yet.  But OKAD simulates 1ps intervals
>and indicate that the arbitration circuit works.  Still good
>to test the real circuit a lot if it gets made.

I'm more curious about the software model.  The one who loses *must* not
just block, because what if he's one of the destinations of the message from
the other side?  Deadlock.  Seems like some sort of atomic test-and-set
behavior is required.  With detection and (exponentail) backoff.

>When Chuck said that "Most programs fit in 1K." I didn't get it.  
>After many years I observed that most programs assigned the
>MachineForth programmers were less than one 1K on Chuck's
>word addresssing and multiple opcodes per word designs.  Chuck's
>code is even more dense.  It took me a long time to get what
>he was talking about.  He now seems to feel that 256
>(up to 3 opcodes on c18) words is reasonable for most 
>things, at least those that he is thinking about...

The code size, sure.  But state size is another issue.  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.

Regards,
Andy Valencia
------------------------

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.