Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!david
From: david@june.cs.washington.edu (David Callahan)
Newsgroups: comp.arch
Subject: Re: Lisp "future" instruction in 88k hardware.
Message-ID: <6410@june.cs.washington.edu>
Date: 13 Nov 88 16:16:48 GMT
References: <3401@geaclib.UUCP> <3410@geaclib.UUCP>
Reply-To: david@uw-june.UUCP (David Callahan)
Organization: U of Washington, Computer Science, Seattle
Lines: 48

In article <3410@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes:
>
>  The principle is "start it, and only wait for it if you have to",

>programmer-visible coprocessors and parallel processors.  I propose
>not that one make a scoreboarding instruction available (ie, a
>special case), but instead a general case, which might take the form
>
>	future function,returnVector2
>	...
>	...
>	await r4,returnVector2
>
This is similar to a mechanism Arvind at MIT has been talking
about for executing Dataflow programs on a RISC-ish processor
He inverts the order of operations:

	join  r1		! wait for incoming token
	add r1 =  r1 + r2 
	fork r3			! generante extra token

WHich is sort of what the coprocessor would see in your example.
Arvind's proposed  dataflow processor (Monsoon) can be thought of
as multiplexing a large number of these small risc instruction
streams on the same processor. 

A different approach used on the HEP machine from Denelcor
was to multiplex more traditional "instruction streams" 
on one processor. The processor could support 64 instruction
streams and one instruction stream could fork off a new instruction
stream in one instruction (assuming resources available, trap otherwise).
The HEP then provided Full/Empty bits on each word of memory to support "join" 
operations.

>  Anyone want to comment on the difficulty of achieving this with
>current memory management techniques?
>	
I'm not sure what you mean by memory management exactly. THe
most difficult problem I see is "parallelism" mangagement
to acheive load balancing. 

>-- 
> David Collier-Brown.  | yunexus!lethe!dave
> Interleaf Canada Inc. |
> 1550 Enterprise Rd.   | HE's so smart he's dumb.
> Mississauga, Ontario  |       --Joyce C-B

David Callahan, Tera Computer Co.,  Seattle, WA.