barmar@think.com (Barry Margolin) (11/22/90)
In article <513@ctycal.UUCP> ingoldsb@ctycal.UUCP (Terry Ingoldsby) writes: >Aren't you forgetting one of the most successful symbiotic relationships? >I speak of VAX/VMS. I took a VMS Internals course a few years ago, and >was struck by the frequency with which the VAX architecture just happened >to be exactly what was needed for VMS. I finally concluded that if VAX >was not designed for VMS, then certainly the hardware architects had a >lot of input from the VMS people. Could you give examples? While it's quite likely that you're right about the hardware and software people talking to each other during the development (if you're going to implement a proprietary OS specifically targeted at your new hardware architecture, this is the right way to do it), there are also other factors. I don't know too much about VMS and VAX internals, but I've never heard that it was extremely revolutionary. The VAX primitives are presumably based on the needs of timesharing systems that were developed during the two decades before it was introduced, and these OSes also strongly influenced the design of VMS. In particular, it was well known by then what hardware primitives are needed to support efficient process scheduling and demand paged virtual memory. Also, to contradict your premise, I have a vague recollection that the VAX memory architecture is lacking a dirty bit in the page table (but I could be confusing it with another contemporary), even though most paging algorithms would be helped by this feature. Perhaps the VAX and VMS seem like such a good match because VMS doesn't try to do things that are hard to do on the VAX. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
egdorf@zaphod.lanl.gov (Skip Egdorf) (11/22/90)
In article <1990Nov21.191759.23254@Think.COM> barmar@think.com (Barry Margolin) writes: > > In article <513@ctycal.UUCP> ingoldsb@ctycal.UUCP (Terry Ingoldsby) writes: > >Aren't you forgetting one of the most successful symbiotic relationships? > >I speak of VAX/VMS. > > Could you give examples? While it's quite likely that you're right about > the hardware and software people talking to each other during the > development (if you're going to implement a proprietary OS specifically > targeted at your new hardware architecture, this is the right way to do > it),... > > Barry Margolin, Thinking Machines Corp. > > barmar@think.com > {uunet,harvard}!think!barmar DEC made a big thing when the VAX was announced about how the hardware and software folks had all crawled into bed together. This can be viewed as both a blessing and a curse. Bill Joy once went into great detail in a bull session at one of the Unix User's Group meetings about problems with 3BSD getting onto the VAX. One particularly nasty one was (I seem to recall) the "tape splatter problem" where one of the massbus registers on the 1/2" tape controller would bleed over into the word-counter when a tape error happened (as they do silently and correctably on 1600 and 6250 bpi drives) causing the tape read to run away. After digging through the sources, they found that VMS mapped the tape's buffer into its on little world and the NORMAL termination was the page-fault caused by running off the end of the buffer. It took a stand-alone Macro program to convince the DEC folks that there was a problem. This is an example of VMS covering up a problem with another problem. These bug/anti-bug pairs can be the bane of one's existance at times. Skip Egdorf hwe@lanl.gov
ckp@grebyn.com (Checkpoint Technologies) (11/22/90)
In article <1990Nov21.191759.23254@Think.COM> barmar@think.com (Barry Margolin) writes: >Also, to contradict your premise, I have a vague recollection that the VAX >memory architecture is lacking a dirty bit in the page table (but I could >be confusing it with another contemporary), even though most paging >algorithms would be helped by this feature. Perhaps the VAX and VMS seem >like such a good match because VMS doesn't try to do things that are hard >to do on the VAX. The VAX MMU has a "modified" bit for page table entries, but no "referenced" bit. VMS uses a "soft page fault" (the page is invalidated for the user, but remains in core; if a fault occurs, the page is revalidated quickly) to discover reference frequency. Interestingly enough, the "modified" bit is not used by VMS; pages are always written out, modified or not. (I, also, have taken the VMS internals course!) -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
ga@herts.rdg.dec.com (Giles Atkinson) (11/22/90)
In article <23425@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: |> |> The VAX MMU has a "modified" bit for page table entries, but no |> "referenced" bit. VMS uses a "soft page fault" (the page is invalidated |> for the user, but remains in core; if a fault occurs, the page is |> revalidated quickly) to discover reference frequency. Interestingly |> enough, the "modified" bit is not used by VMS; pages are always |> written out, modified or not. (I, also, have taken the |> VMS internals course!) Actually pages are not 'always written out', but VMS does sometimes write out pages which have not been modified. This happens to pages which are writeable and not shared and is done because the same memory location in the executive (BAK array entry) is used to store the original disk location of the page's data and its allocated backing store in the paging file. Lazy allocation of backing store occurs when the page is first brought in. BSD does the same, but also does it for read-only pages! I think the lack of a reference bit was probably seen as advantageous given the original VMS memory management concept of each process paging within a fixed quota of physical memory. A weak substitute for a reference bit is simulated on most VAX processors by polling the TLB before replacing a page. (I have taught the VMS internals course more often than I care to remember) No signature. Standard diclaimer here.
weaver (11/27/90)
It has been a while since I learned about VAX/VMS, but here is what I remember about architectural support for VMS by VAX: 1. Atomic enqueue/dequeue instructions are used for queuing IO requests. 2. The famous complex CALLG and CALLS call instructions use a certain stack frame layout, which is used in signal handling. 3. Software interrupts (Asynchronous System Traps) are like signals, but handled by hardware as if they were interrupts in an attempt to integrate interrupt and signal handling. 4. Branch-on-low bit is used frequently because the returned status from each system call is encoded with the least signifigant bit signifying success or failure, and other bits uniquely identifying the error. None of these would seem to have been radical at the time, but they do seem to be architectural support specifically for VMS. The handling of page faults in VMS has been described incorrectly a few times in comp.arch, so I will attempt to get it right. The VAX has a dirty bit in the MMU, but does not have a referenced bit. The textbook approach to page replacement is called the clock algorithm. This works like a meter maid: I mark a page as not used, wait a while, and if it is not marked as used (referenced) when I look at it again, it is a candidate for replacement. Usually, the marking of pages as referenced is supported by hardware. The VMS version works as follows: when I need a page that is not in memory, I pick a page *at random* from my working set (per process pool of memory), and put it in one of two long lists of pages, one for dirty and one for clean. Then I take the last page in the list of clean pages, and use that block of memory as my new page. (The dirty list is being written back to disk asynchronously, and when a page is written back it also transferred to the clean list). If the page I need is actually in the clean or dirty list, a simple swap is made. In this case, the mapping for the needed page is still in the page tables, so finding it is fairly efficient. The net effect is similar to the clock algorithm in that pages that have not been used for a long time will most likely to be put to backing store. It would be interesting to hear from any developers of the VAX why this was done this way. It is hard to believe that the designers of the VAX had not heard of a referenced bit. It is possible that the simplification of hardware was considered a plus, but this goes against the grain of the rest of the design. I would guess the the VMS developers thought they had a superior implementation of working sets, and having committed to it, told the VAX developers not to bother with a referenced bit.
barmar@think.com (Barry Margolin) (11/27/90)
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