[comp.unix.cray] Protection in Cray

chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh) (12/19/90)

I am currently investigating methods of minimizing virtual memory overheads
in high-performance computers. I think I have some way of solving 
logical-physical address translation. But I can't think of an efficient way 
of providing protection. I figure since Cray doesn't have virtual memory, maybe
it can teach me something about achieving protection inexpensively. 
Can anybody enlighten me about how Cray provides protection as normal virtual 
memory systems offer, or where can I find useful description in this regard ? 
Thank you. 

tzi-cker

djh@xipe.osc.edu (David Heisterberg) (12/19/90)

In article <1990Dec18.214228.25858@agate.berkeley.edu> chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh) writes:
>                         I figure since Cray doesn't have virtual memory, maybe
>it can teach me something about achieving protection inexpensively. 
>Can anybody enlighten me about how Cray provides protection as normal virtual 
>memory systems offer, or where can I find useful description in this regard ? 

CRAYs (at least X and Y models) use base and limit register pairs (one
set for code, one for data) for each process.  The base register is added
to the logical address (as generated by the program) to give the physical
memory address.  It is, I think, the physical address that is checked
against the limit register, and, if out of bounds, a program or operand
range exception is generated.

With separate code/data base/limit registers code sharing is possible, but
I don't think it is much used.

That phrase, "normal virtual memory" - I just don't know what to make of it!
--
David J. Heisterberg		djh@osc.edu		And you all know
The Ohio Supercomputer Center	djh@ohstpy.bitnet	security Is mortals'
Columbus, Ohio  43212		ohstpy::djh		chiefest enemy.

chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh) (12/20/90)

The kind of protection I have in mind is access right control (e.g., read-only)
"Normal virtual memory systems" perform this kind of protection check while 
doing logical-physical address mapping. The protection bits are either in page 
tables or TLB.  Now, since Cray doesn't have virtual memory, the question is 
does it provide access control, if so, where does it put this check ?
From the previous responses, it seemed that Cray only provides out-of-bound
protection check. Furthermore, this check is done for EVERY reference. 
If this is indeed the case, this protection check process should be as 
expensive as address mapping in machines that have VM. 
So why does Cray get rid of virtual memory altogether ?  Or does anybody 
know how much performance improvement can we gain from getting rid of VM ?

tzi-cker

fair@Apple.COM (Erik E. Fair) (12/23/90)

Mike O'dell gave a wonderful paper at the last USENIX conference about
trying to build a 150 MIPS SPARC system in GAs technology. One of the
more amusing parts was his description of why heavily pipelined
machines and virtual memory systems don't get along very well: it is
somewhat disconcerting to find out that you had a page fault four
instructions ago...

	Erik E. Fair    apple!fair      fair@apple.com

fouts@bozeman.ingr.com (Martin Fouts) (01/05/91)

>>>>> On 23 Dec 90 09:47:59 GMT, fair@Apple.COM (Erik E. Fair) said:

Erik> Mike O'dell gave a wonderful paper at the last USENIX conference about
Erik> trying to build a 150 MIPS SPARC system in GAs technology. One of the
Erik> more amusing parts was his description of why heavily pipelined
Erik> machines and virtual memory systems don't get along very well: it is
Erik> somewhat disconcerting to find out that you had a page fault four
Erik> instructions ago...

Not sure how this applies to comp.unix.cray, as Mr. Cray's
machines don't have virtual memory.  It was a much more
interesting problem on the ETA-10, which did. (does?)

Marty
--
Martin Fouts
Software Craftsman

EMAIL:  fouts@apd.ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa