Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: VAX and VMS development (was Re: Graphics Primitives)
Message-ID: <1990Nov26.214146.24523@Think.COM>
Date: 26 Nov 90 21:41:46 GMT
References: <513@ctycal.UUCP> <1990Nov21.191759.23254@Think.COM> <1990Nov26.172817.20055@weitek.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 44

In article <1990Nov26.172817.20055@weitek.COM> weaver@weitek.UUCP (Michael Weaver) writes:
>It has been a while since I learned about VAX/VMS, but here is what I 
>remember about architectural support for VMS by VAX:
... [Examples deleted]
>None of these would seem to have been radical at the time, but they
>do seem to be architectural support specifically for VMS.

Except for the branch-on-low-bit instruction, those examples seemed more
like architectural support for any modern mainframe OS, not specifically
VMS.  However, not all OSes may be able to take advantage of them, because
the instructions frequently dictate data structure layout, and the OS may
have its own needs in this regard.  For instance, the atomic enqueue
instruction presumably specifies the way a queue is represented in memory,
and the call instructions specify stack frame layout.

In the case of VAX and VMS, the OS developers presumably had early access
to the architecture design spec, so they were able to design the OS to use
the hardware's data layouts.  They might even have had the opportunity to
suggest changes.  When an OS is designed before or independently of a
particular hardware architecture (as Unix has been) the OS designer
generally lays the data out in the way that is most convenient to him, and
this may not match the hardware designers' layouts, so the OS is not able
to use the hardware features.  The fact that VMS uses these VAX features
doesn't indicate a particular direction of causality; the VAX designers
might have told the VMS designers what features they could use, or the VMS
designers could have told the VAX designers what features they wanted.

There's a similar issue with language-oriented processors.  In recent years
a number of microprocessor designs have been touted as being "C-oriented".
This doesn't necessarily mean that any of the C compilers around are able
to use the C-oriented features of the processor.  Code generators are
frequently designed based on features common to most processors, so it may
be difficult to make them take advantage of unusual features.  Some CISCs
have special instructions for evaluating polynomials, which were presumably
intended to help Fortran-style programs, but I suspect few Fortran
compilers for those machines actually use them (however, I've also heard
that many of the implementations aren't very fast, so you wouldn't want to
use them).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar