Path: utzoo!yunexus!geac!geaclib!daveb
From: daveb@geaclib.UUCP (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: Lisp "future" instruction in 88k hardware.
Message-ID: <3410@geaclib.UUCP>
Date: 12 Nov 88 00:58:04 GMT
Article-I.D.: geaclib.3410
References: <3401@geaclib.UUCP>
Organization: GEAC Computers, Toronto, CANADA
Lines: 37


  I should have included a disclaimer in my response to Jonathan
Swedler (in <917@taux01.UUCP>, by saying that it is the same
**principle** as scoreboarding within the alu/pipeline, but quite a
different application of the principle.

  The principle is "start it, and only wait for it if you have to",
but in this case the application is to large-scale, possibly
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

  which could be done by a fairly simple trap scheme, which would
execute the function iff no coprocessor and its return vector was
available and would send it off to a coprocessor otherwise. This
would cost some operating system overhead (meaning that it would not
be a real risc instruction, but extracode instead).  The await
(which I called FUTU in a previous article) would be a real RISC
instruction though, and one very straightforward to implement: move
from memory area to register iff memory access controller permits.
  This implies, of course, that you are prepared to live with a
small number of coprocessors, or a rather complex memory access
controller.

  Anyone want to comment on the difficulty of achieving this with
current memory management techniques?
	
-- 
 David Collier-Brown.  | yunexus!lethe!dave
 Interleaf Canada Inc. |
 1550 Enterprise Rd.   | HE's so smart he's dumb.
 Mississauga, Ontario  |       --Joyce C-B