Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!unisoft!paul
From: paul@unisoft.UUCP (n)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Keywords: paging virtual-memory speed
Message-ID: <963@unisoft.UUCP>
Date: 27 May 88 17:30:16 GMT
References: <463@cvaxa.sussex.ac.uk> <1016@cresswell.quintus.UUCP> <508@cmx.npac.syr.edu>
Reply-To: paul@unisoft.UUCP (Paul Campbell)
Lines: 30

In article <508@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O'Farrell) writes:
>In article <1016@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>In article <463@cvaxa.sussex.ac.uk>, aarons@cvaxa.sussex.ac.uk (Aaron Sloman) writes:
>>The B6700 could and did page large data arrays, but it couldn't page
>
>The B6700, at least the one that I knew and loved :-), did not do
>"paging" of either data or code.  Yes, procedures were in their own


Actually it did, the compiler made arrays bigger that 1023 words into things
with doubly indirect pointers, the descriptor had a bit set (I think it
was called 'segmented') that ment that when it was accessed it split
the array into 256 word chunks, and referenced and array of normal
descriptors, which in turn referenced the real memory (some of which
could be paged). This of course was slower and (I think) the string opcodes
didn't work on them, hence the Algol construct 'long array' which was how
you created a non segmented array .... I too remember the 6700 with fond
memories .... and for the Unix people out there  - it had 'streams', of course
called by a different name and with many of the details different but one 
could create an MCS with all the same functionality (and we did ...)


	Paul



-- 
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca
	E-mail:		..!{ucbvax,hoptoad}!unisoft!paul  
Nothing here represents the opinions of UniSoft or its employees (except me)
"Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)