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

[Arne Vajhøj]

On 8/24/2023 6:05 AM, Johnny Billquist wrote:
> On 2023-08-23 04:16, 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"?
> 
> I think there was a famous quote about this:
> "We will *not* have a compatibility mode bit like the VAX did!".

But if we look at this from the high level.

Both DEC and DG considered it important to be able to
run old 16 bit applications on their new 32 bit system.

Both DEC and DG was willing to add support for the
16 bit instructions in the hardware (as opposed to
DEC a little over a decade later when the 64 bit support
for 32 bit applications was software based: VEST).

DEC chose to have the VAX switch mode between 32 and
16 bit instructions (similar to what AMD did a couple
of decades later).

DG chose to support both instruction sets at the
same time.

Both DEC and DG achieved the business goal of being
able to run both old 16 bit applications and new
32 bit applications.

DG approach seems more elegant as it must have
allowed new 32 bit code to call old 16 bit code
within the same program. If someone knew how to
ensure that everything got set up properly (somewhat
similar to VMS code today using 64 bit pointers needing
to call code using 32 bit pointers - you better have
the data in P0 and not P2).

Arne