Path: utzoo!utgpu!watmath!iuvax!cica!gatech!prism!robinson
From: robinson@prism.gatech.EDU (Stephen M. Robinson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Subtantiatng my criticism [really: VM on PDP 11/70]
Message-ID: <1404@hydra.gatech.EDU>
Date: 8 Aug 89 14:31:34 GMT
References: <13277@polyslo.CalPoly.EDU> <30466@ucbvax.BERKELEY.EDU>
Reply-To: robinson@prism.gatech.EDU (Stephen M. Robinson)
Organization: Georgia Tech Computer Science, AI Group
Lines: 56

In article <30466@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>In article <13277@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes:
>
>> [Stephen M. Robinson very gently pointed out that the 11/70 doesn't have
>>virtual memory.]
>
>>  hmmmmm, well then I guess this makes me look pretty foolish.  Guess I
>
>Sorry to bother the comp.sys.mac.programmer crowd with this. David, don't
>be so quick to apologize, Stephen is absolutely wrong.  The PDP-11/70 only
>has a 16-bit program counter, so you'd think it can only address 64k. But,
>the memory mapping registers map the program counter into one 64k space,
>and the data registers into a second 64k space. This was known as split i
>& d space.  Each program gets its own pair of i&d space, and the kernel
>gets _its_ own space. So, you had virtual memory, but on a whole system
>basis. A single program could get no bigger than 128k bytes. Since the
>operating system has direct access to the memory mapping registers, it can
>be much larger than 128k by accessing other memory spaces as needed.

Whoa...  Alright, yes, an 11/70 has separate instruction and address space.
However, this does *not* constitute virtual memory with all the requisite
disk space, paging mechanism (and caching, etc).  Not only that but "i-space"
cannot be used for data and vice versa.  You *are* limited to 64K of program
and 64K of data in user applications.  I thought the kernel was similarly
limited but I guess not.  Sorry David, now *I* look somewhat foolish, eh?
(But then I don't really care.)

>Now, the Macintosh connection: that Unix system had a huge latency: if you
>typed a key, it might be as long as 5 seconds before your job came around

We never had this kind of slow reponse, not even with 25-30 users logged on.
Now our old VAX used to get really slow when 18-20 were logged on .....

[.....]

>Unix is okay, but the pipeline components Stephen puts such store by:
[Hey, where did i "put store by" these things in my message? I didn't, but in
fact pipelining is one of unix's big wins for me so you must have read
between the lines :-)]
>sort, ls, grep, awk, and the rest are essentially non-interactive. You
>start them up and wait for them to finish. If you want interactive
>performance on a wimpy old slow 68000, you don't want unix.
What about on a 68030 or 040?  What's a Sun anyway?  You can't run VM on
a 68000 (that's why sun2's had 68010's in them) anyway, so that's not the
problem.  I think the Mac OS is great for cetain kinds of document preparation
and for novices/infrequent users but not for many kinds of program development,
etc.  I own a Mac+ myself and love to use it for my paper writing, etc.  But,
I'd rather have a Sequent or Sun4, etc and Unix or better yet a Symbolics
for Lisping anyday for programming, data analysis, etc.  Enough rambling -
I'm way off the original posting about running unix on small machines, etc.
[I promise the comp.mac.pgmming crowd I won't post again on this subject...]
-- 
Stephen M. Robinson, AI Group, School of Information and Computer Science
Georgia Institute of Technology, Atlanta Georgia, 30332-0280  404-894-8932
uucp:     ...!{allegra,amd,hplabs,uiucdcs,ut-ngp}!gatech!prism!robinson
Internet: robinson@prism.gatech.edu