Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!rutgers!soleil!mlb.semi.harris.com!forth.mlb.semi.harris.com!rvn
From: rvn@forth.mlb.semi.harris.com (Rick VanNorman)
Newsgroups: comp.lang.forth
Subject: Re: of peasants and queues and dataflow
Message-ID: <1990Sep26.174155.13721@mlb.semi.harris.com>
Date: 26 Sep 90 17:41:55 GMT
References: <1990Sep26.084008.8616@idacom.uucp>
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 38
Nntp-Posting-Host: forth.mlb.semi.harris.com

In <1990Sep26.084008.8616@idacom.uucp>, rob@idacom.uucp (Rob Chapman) writes:

>>The question should not be "how do we get parallelism _despite_ FORTH's
>>stack?"; it should be "How best can we use the power of the stack to 
>>implement multiprocessing?".
>
>Stacks are best left attached to one processor due to there uniflow nature.

One of the techiques that I played with three years ago on the Novix (with
_external_ stacks!) was connecting two processors' stacks via dual-port
memory, but with one processor's addresses inverted such that the address
map of the stacks looked like:

	processor 1		processor 2
	  stack			  stack

	    0			   255
	    1			   254
	   ...			   ...
	   254			    1
	   255			    0

Thus processor one could push numbers onto the stack and feed processor 2.
We never did much with this, or find anywhere it could really be useful --
but it was an interesting (thought) experiment.

Could this be useful?  Would it justify placing the stacks of a Forth 
engine off-chip again? (they are on-chip for speed and pin-count reasons,
wiggling pins with CMOS drivers at 10MHz is _slow_ compared to having
memory on the chip)

Rick VanNorman
Staff Engineer, Software Development
RTX Marketing
Harris Semiconductor
Melbourne, Florida, USA

All opinions expressed by me, real or otherwise, are my own.