hutch@celerity.uucp (Jim Hutchison) (05/06/89)
Has anyone seen/heard of an architecture which aided kernel message passing by
supplying hardware message queues for *fast* message queueing and dequeueing?
/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */
/* Disclaimor: I am not an official spokesman for FPS computing */wilkes@mips.COM (John Wilkes) (05/08/89)
In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? elxsi >/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ >/* Disclaimor: I am not an official spokesman for FPS computing */
hild@infbs.UUCP (Frank Hildebrandt) (05/08/89)
In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? Maybe you want to take a look into Ramachandran, U., Solomon, M.: "Hardware Support for Interprocess Communication" Comp. Arch. News, Vol. 15, No. 2, June 87, pp 178-188 or Ramachandran, U.: "Hardware Support for Interprocess Communication", Ph.D.Thesis, Technical Report #667, Comp.Sc.Dept., U of Wisconsin, Madison, September 86 Greetings, Frank. ------------------------------------------------------------------------------- Frank Hildebrandt, TU Braunschweig, Inst. f. Betriebssysteme und Rechnerverbund Postfach 3329, D-3300 Braunschweig, West Germany. Tel.: +49 531 391 3292 email: hild@infbs.UUCP hild@dbsinf6.BITNET
aglew@mcdurb.Urbana.Gould.COM (05/08/89)
>Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? >/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ ELXSI is the current best example. Gould had firmware message queue instructions in a regular memory. I posted about this recently, although it may have gotten lost in the SL/cik war.
michaelw@microsoft.UUCP (Michael Winser) (05/09/89)
In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? The transputer, I believe. Michael -- /\ no guts michael winser \/ no glory microsoft corp. (206) 882-8080, michaelw@microsoft.uucp
kolding@june.cs.washington.edu (Eric Koldinger) (05/09/89)
In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? IBM S/38 and AS/400 use message passing quite a bit in the kernel for IPC. I don't know how much is in hardware or how *fast* it is though. -- _ /| Eric Koldinger \`o_O' University of Washington ( ) "Gag Ack Barf" Department of Computer Science U kolding@cs.washington.edu
lethin@wheaties.ai.mit.edu (Richard A. Lethin) (05/09/89)
In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >Has anyone seen/heard of an architecture which aided kernel message passing by >supplying hardware message queues for *fast* message queueing and dequeueing? >/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ >/* Disclaimor: I am not an official spokesman for FPS computing */ @INPROCEEDINGS{DAL:JMA, AUTHOR = {Dally, William J. and Chien, Andrew and Horwat, Waldemar and Keen, John and Larivee, Michael and Lethin, Rich and Nuth, Peter and Wills, Scott}, TITLE = {The J-Machine: A Fine-Grain Concurrent Computer}, BOOKTITLE = {Proceedings of IFIP 89 Conference}, YEAR = {1989} } The "Jellybean machine" is an experimental system which has LOTS of hardware to support message sends and dispatch on receipt. The point of it is to reduce the cost of initiating processes in order to support the execution of "fine-grained" concurrent methods. -- -- Rich lethin@wheaties.ai.mit.edu
roger@wraxall.inmos.co.uk (Roger Shepherd) (05/09/89)
In article <5668@inmos.co.uk (Michael Winser) writes: >In article <279@inmos.co.uk (Jim Hutchison) writes: >>Has anyone seen/heard of an architecture which aided kernel message passing by >>supplying hardware message queues for *fast* message queueing and dequeueing? > >The transputer, I believe. > Well, no actually. The transputer does have fast mesage passing and scheduling but is has NO message queues. The model of message passing implemented is that of CSP, processes synchronise when they pass messages; if the receiver is not ready to receieve when the sender sends, the sender suspends. If the sender is not ready when the receiver wants to receive the receiever suspends. This model is supported, not only for processes running on the same transputer, but also for processes running on distinct transputers joined by trasputer links. The choice of synchronised message passing has many advantages both to the implementor and to the user. One advantage is that it eliminates the need for message queues (and hence message buffers) to be associated with every communication channel. If another style of message passing is required it can normally built from the process and message passing primitives in the machine. A fuller discussion of the issues here can be found in Communicating process architecture INMOS Ltd Pub: Prentice Hall ISBN 0-13-629320-4 Roger Shepherd, INMOS Ltd JANET: roger@uk.co.inmos 1000 Aztec West UUCP: ukc!inmos!roger or uunet!inmos-c!roger Almondsbury INTERNET: @col.hp.com:roger@inmos-c +44 454 616616 ROW: roger@inmos.co.uk
ttwang@polyslo.CalPoly.EDU (Thomas Wang) (05/10/89)
In article <2277@cream-of-wheat.ai.mit.edu> lethin@cream-of-wheat.ai.mit.edu.WISC.EDU (Richard A. Lethin) writes: >In article <279@celit.UUCP> hutch@celerity.UUCP (Jim Hutchison) writes: >>Has anyone seen/heard of an architecture which aided kernel message passing by >>supplying hardware message queues for *fast* message queueing and dequeueing? >>/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ Try H. Kanakia and D.R. Cheriton. The VMP network adapter board NAB: High- performance network communication for multiprocessors. In SIGCOMM 88, ACM SIGCOMM, Aug 1988 -Thomas Wang (Anime drinking game - toast when you hear "Ayukawa!!!") ttwang@polyslo.calpoly.edu
rpw3@amdcad.AMD.COM (Rob Warnock) (05/12/89)
In article <279@inmos.co.uk (Jim Hutchison) writes: +--------------- | Has anyone seen/heard of an architecture which aided kernel message passing by | supplying hardware message queues for *fast* message queueing and dequeueing? +--------------- Circa 1979 at Digital Communications Associates we did this with in a multi-processor communications controller (multiple Z-80's, *ugh*). To send, you just wrote the (fixed 4-byte) message in a hardware register. A bus state-machine understood the addressing and did some DMA, and the message showed up in a linked-list queue in the receiving Z-80's RAM. Since the DMA input was atomic to the Z-80, when sending a message to from one process to another on the same CPU it was actually cheaper to send it out to the bus and back rather than doing the interlock in software. (You could also save the test of whether the recipient was local.) For highest performance, the IPC does need to be tuned to the application. Said another way, if you try to define a totally general message-passing system without carefully considering the domain of applications, you lose. Conversely, for a restricted applications domain, the required IPC can often be *much* cheaper in hardware/software than a "general" message system. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403