Path: utzoo!attcan!uunet!husc6!ukma!xanth!ames!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: Message queues
Message-ID: <25603@amdcad.AMD.COM>
Date: 12 May 89 06:53:43 GMT
References: <279@inmos.co.uk> <1446@brwa.inmos.co.uk>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 29

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