Xref: utzoo comp.arch:11143 comp.sys.mips:121
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!yale!leichter
From: leichter@CS.YALE.EDU (Jerry Leichter)
Newsgroups: comp.arch,comp.sys.mips
Subject: Re: Memory utilization & inter-process contention
Message-ID: <70663@yale-celray.yale.UUCP>
Date: 25 Aug 89 17:50:27 GMT
Sender: root@yale.UUCP
Organization: Yale Computer Science Department, New Haven, Connecticut, USA
Lines: 49
X-from: leichter@CS.YALE.EDU (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU))

In article <5967@pt.cs.cmu.edu>, ram@wb1.cs.cmu.edu (Rob MacLachlan) writes...
>...Many classic VM algorithms (such as Working Set) do consider processes and
>degree of thrashing, etc., but these algorithms seem to be little used in
>recently designed o.s.'es.  [Since this is comp.arch, I will note in passing
>that is may be partly due to brain-dead VM hardware, such as the VAX, which
>doesn't even have a reference bit.]...

VMS and the VAX architecture were designed at the same time by a group of
people who worked together.  VMS has implemented a Working Set algorithm
since it first shipped.

I've heard (from reasonably reliable sources) that the hardware people were
ready to include a reference bit, but the software people's work showed they
didn't need it, given appropriate algorithms.  The fact that early Unix
implementations for the VAX didn't handle it correctly is a problem with the
developers of those early versions, not with the VAX architecture.

I have never understood this need people have to use the VAX as the standard
bad example of EVERYTHING.  In fact, the designers of the VAX worked in ways
very similar to the way good RISC designers work today:  Hardware and software
people cooperated, and there was an attempt to balance the complexity each
had to deal with.  It may seem hard to believe, almost 15 years later, that
the compiler writers heavily influenced the design of the ISA, asking for
things like 3-address arithmetic instructions in addition to 2-address and
indexed addressing modes, but given the compiler technology of the day, this
is what they thought would be useful to them.  Compiler technology has changed
greatly since then, as has hardware technology.

The main difference between the VAX design team and current design teams is
probably in the inclusion of the OS designers.  The process structure of the
VAX, the support in hardware for AST's, the security structure - all of these
are direct reflections of the OS being developed.  These days, OS design is
rapidly becoming a lost art - Unix is the answer, what was the question?  So
there is little room for interplay any more between OS designers and hardware
designers - the hardware designers provide what the well-understood Unix
kernel needs and are finished.  (To a certain extent, language design is
approaching the same point:  Support C and figure you are done.  The VAX was
viewed from the start as a multi-lingual machine, and its ISA contains
elements that the COBOL developers found important, as well as elements the
FORTRAN developers wanted.  Most of the early RISC papers used C examples,
exclusively.  More recently, we've seen "Smalltalk RISC's" and "LISP RISC's".
I'm certainly not up on all the literature, but I know of no RISC design,
paper or otherwise, specifically intended to simultaneously support two quite
different languages efficiently.  As a language designer, I find it very
distressing to think that the machines of the future may be "refined" to the
point where doing anything but Unix and C will require extreme effort.  Take a
look at the history of LISP on CDC machines to see the possible results.)

							-- Jerry