Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!apple!oracle!news
From: csimmons@jewel.oracle.com (Charles Simmons)
Newsgroups: comp.arch
Subject: Re: Does anyone know anything about the N-Cubed Hypercube?
Message-ID: <1990Jun2.121058.13912@oracle.com>
Date: 2 Jun 90 12:10:58 GMT
References: <9399@pt.cs.cmu.edu> <1990May23.172140.17510@portia.Stanford.EDU> <9385@pt.cs.cmu.edu> <26336@super.ORG>
Sender: news@oracle.com
Reply-To: csimmons@oracle.com
Organization: Oracle Corp
Lines: 45

In article <9399@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU
(Donald Lindsay) writes:
> From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
> Subject: Re: Does anyone know anything about the N-Cubed Hypercube?
> Date: 24 May 90 18:26:57 GMT
> 
> In article <26336@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes:
> 	[ concerning the NCUBE-2 multiprocessor ]
> >does anyone out there know what if any MMU support the processors 
> >have? 
> >I am trying to get manuals and tech docs but it is taking time, and 
> >I am hearing conflicting reports ranging from "no MMU" to "full MMU".
> 
> There are no page faults. Each CPU has bounds registers and a supervisor
> state, but that's it. 
> 
> This from Stephen Colley's lips when I put up my hand and asked.
> -- 
> Don		D.C.Lindsay 	Carnegie Mellon Computer Science

Elaborating just a little bit on Don's comments...

The memory model is reasonably kinky:

Each user process has 5 "segments".  There is a "text" segment
(which is framed by the "user code base/length" registers) and
there are 4 data segments (which are framed by the "user data space
base/length" registers).  The really kinky thing is that the processor
accesses the "text segment" if you use pc-relative addressing.  Otherwise
a data segment is referenced.  Thus, logical address zero can be either
in the text segment or in data segment zero depending on whether or
not you use pc-relative addressing.

The operating system allows multiple user processes running on a single
processor node to share one or more segments.

And while we're on the subject...  Things are implemented ever-so-slightly
incorrectly.  It turns out that you cannot dynamically grow your stack
segment.  Basically, the reason for this is that the stack grows down,
but segments "grow" up.  So you get to specify your stack segment size
at program load time and then live with your choice thereafter.

Ah!  The joys of programming on the cutting edge of technology.

-- Chuck