[Info-vax] VAX vs. MV/8000 [was Re: Hard links on VMS ODS5 disks]

Chris Scheers chris at applied-synergy.com
Fri Aug 25 16:46:11 EDT 2023


Arne Vajhøj wrote:
> On 8/22/2023 9:36 PM, Rich Alderson wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne at vajhoej.dk> writes:
>>> VAX + VMS                               Eclipse MV + AOS/VS
> ...>> ---------                               -------------------
> 
>>> 16 bit compatibility mode               16 bit compatibility mode
>>
>> Wrong!  See below.
> 
>> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same 
>> method as the
>> Eclipse to add 32 bit intructions to the mix:  A previously unused set 
>> of NOPs
>> was turned into the prefixes for the 32 bit instruction set.
> 
> So you say that the Eclipse MV was "Eclipse compatible" instead
> of having "Eclipse compatibility mode"?


Yes, NOVA, Eclipse, and MV instructions could all be (and were) mixed in 
the same program. They would generally be mixed in the same subroutine.

Except for a few hardware functions (e.g., auto increment and auto 
decrement locations), Eclipse or Nova software could run directly on the MV.

Another correction: The MV had two only modes, privileged and 
non-privileged.

The "modes" referred to in the original post were memory "rings".

The MV used a segmented/paged memory model. The upper most bit of an 
address was (usually) the indirection bit and the next three bits were 
the segment number.

A single program would exist entirely within a single segment. A program 
could reference memory in its own segment or outer (higher segment 
number) segments, but could not access inner memory.  This is similar to 
the VAX KESU memory protections, but instead of doing it on a page by 
page basis, this was done on a segment by segment basis and was implicit 
in the address.

Within a segment, there would be a page table to support virtual memory.

For privileged system calls, a program would make an inner ring call 
using a gateway. That is, the call address would include a function 
number instead of an inner mode address.  This ring to ring transition 
was handled by the firmware. (Similar to the VAX CHMx instructions.)
The gateway function is similar to what Intel is doing now with the SGX 
extension.

AOS/VS laid out the rings as:

0: Kernel
1: PMGR
7: user programs

Kernel only supported block mode devices. PMGR handled non-block (e.g., 
terminals) devices and mapped to the appropriate Kernel calls.

Other rings could have various programs loaded into them depending on 
what the system needed. Databases and filesystems quite often went into 
rings. Debuggers could live in a ring.

Also be aware that Data General could be considered to be a spin off 
from DEC. Read up on its rather interesting history.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074



More information about the Info-vax mailing list