Path: utzoo!mnetor!uunet!seismo!esosun!cogen!celerity!jpa
From: jpa@celerity.UUCP (Jeff Anderson)
Newsgroups: comp.arch
Subject: Re: Today's dumb question...
Message-ID: <607@celerity.UUCP>
Date: 31 Mar 88 20:48:06 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP>
Reply-To: jpa@celerity.UUCP (Jeff Anderson)
Organization: /usr/lib/news/organization
Lines: 44


In article <2676@pdn.UUCP> ard@pdn.UUCP (Akash Deshpande) writes:
>	RISC people (as I discovered at ASPLOS II, San Jose, Oct 87) would
>	rather not speak of parallel processing. Reminds me of the ostrich.
>	Ask them - "how are you going to maintain cache coherency, TLB
>	flushing, accesses integrity, etc in a parallel processing system?"
>	and they will say "why do you want parallel processing when one
>	RISC machine is so much faster than even parallel CISCs?"

The Celerity 6000 has many RISC attributes, and was designed as a
multiprocessor.  The instruction set of all Celerity's processors
includes separate fetch and receive instructions, which provided an easy
mechanism for implementing semaphores in hardware without "special"
instructions.  

Basically there is a semaphore "box" in the memory address space of the
processor (which incidentally is implemented as 4 semaphores per 16KB
page, in order that they can be assigned 4-at-a-time to the virtual
address space of a user process).  Each semaphore in the box has two
"registers", a "content register" for reading and initializing, and an
"access register" for P'ing and V'ing.  V's are stores to the access
register, and P's are fetches to the access register.  The data returned
indicates the semaphore state for determining whether the processor
should wait.  I won't give you any more specifics since it is patentable,
but it's pretty fast to execute, and easy to implement.

This semaphore implementation doesn't violate any RISC principle since
the instruction set does not need to be tweaked and most of the work is
done in special off-processor memory.  Cache coherancy and TLB flushing
present problems which understandably RISC chip designers would rather
not commit to silicon;  but there ARE fast, off-chip solutions.  Maybe
you're talking to the wrong group?

We don't buy the argument that RISC people "don't care" about
multiprocessing.  Celerity does.

			-- The "J" Team at Celerity Computing
					JJ Whelan
					Jeff Anderson

					ucsd!celerity!jpa
					ucsd!celerity!jjw

					619-271-9940