🚀 go-pugleaf

In article <70663@yale-celray.yale.UUCP> leichter@CS.YALE.EDU (Jerry Leichter) writes:
>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...

That *they* didn't need it, note, not that other software developers might
not need it.  (Of course, as we all know, there was only going to be *one*
operating system for the VAX...)

>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...

The same is true of the architectural tweaks on many modern machines.  For
example, according to John Mashey, the MIPS machines make a considerable
effort to do precise exceptions because the OS people got quite upset about
the alternative.  The difference is that modern OS people don't see any need
to reinvent the square wheel, so the issue is how to *support* the system,
not what it should look like.

>...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...

Might one ask how many RISC designs you are acquainted with?  The SPARC,
the MIPS architecture, and the HP Precision Architecture, to name three,
were all designed with considerable attention to multi-language support.
The fact is, supporting C well is very nearly enough to support the other
"conventional" languages well.  (Note, "very nearly" -- some attention to
the fine points is still desirable.)  Compiler designers today understand
that it may be better to convert COBOL numbers to binary for arithmetic
than to mess up the hardware with decimal instructions, for example.
COBOL programs are seldom arithmetic-bound anyway.

>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.)

Take a look at the history of Lisp on Lisp machines, whose time has come
*and gone* -- those awful "C-only" RISC machines run Lisp faster than the
custom-cooked Lisp machines do.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu