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

[Arne Vajhøj]

On 8/26/2023 3:09 PM, Dan Cross wrote:
> In article <ucdapd$ljc8$1 at dont-email.me>,
> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> On 8/26/2023 9:34 AM, Dan Cross wrote:
>>> In article <ucbh82$8kpo$2 at dont-email.me>,
>>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>>> [snip]
>>>> DEC chose to have the VAX switch mode between 32 and
>>>> 16 bit instructions (similar to what AMD did a couple
>>>> of decades later).
>>>
>>> One presumes you are referring to amd64 here.  If so, then nope,
>>> amd64 is an extension to 32-bit x86, not a replacement in the
>>> sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
>>> was set.
>>>
>>> Even in 64-bit mode, many (most?) programs will continue to
>>> operate as expected with 32- and even many 16- bit instructions.
>>> The same was not true of the VAX.
>>
>> x86-64 in long mode has an emulation mode set via
>> an emulation bit that allows it to execute 32 bit
>> programs.
>>
>> That is the same as what VAX did for PDP-11
>> compatibility.
> 
> Not even close.  PDP-11 compatibility mode on the VAX uses an
> entirely different instruction encoding (PDP-11 encoding for
> PDP-11 instructions) compared to VAX-native instructions.
> http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf
> 
> By contrast, AMD64 mode shares most of the instruction space
> with 32-bit x86.  `xorl %eax, %eax` works just fine in either
> 32-bit or 64-bit mode, with the exact same encoding.  AMD used
> a prefix byte to indicate 64-bit operands to instructions.
> For example, see Chapter 2 of
> https://cdrdv2.intel.com/v1/dl/getContent/671110
> 
> Of course, the semantics of a few instructions do change (the
> size of words on the stack changes, for example, so the `PUSH`
> instruction behaves differently in 64-bit mode), but in this
> regard, the mechanism is closer to what DG did than what DEC
> did.

I think the operative word is "most".

>> The rule is that one cannot mix 64 bit and 32 bit
>> code in the same process.
> 
> You should define what you mean here.  What do you mean by
> "64-bit" and "32-bit" code?

I mean what everybody else in the industry mean by that.

Code compiled for x86-64 vs code compiled for x86.

Binaries packages for AMD64/x86_64/x64 vs for i686/x86.

Code compiled with GCC with -m64 vs -m32.

>                        And what do you mean when you say
> that you "cannot mix" them "in the same process"?

Yes.

>                                                     As I
> mentioned above, the instruction encoding is _mostly_ the same.

Yes. "mostly".

>> Most 32 bit instructions actually work identical
>> in 64 bit mode, but some produce different results
>> and some causes a crash.
> 
> Correct.
> 
>> So executing 32 bit code not in compatibility mode
>> is a big no no.
> 
> Incorrect.  Indeed, the optimization manual encourages using
> 32-bit instructions (ie, without a REX prefix) in some common
> code sequences, even in 64-bit mode, for efficiency reasons.
> For example, the quickest way to clear, e.g., `%rax` is
> `xorl %eax, %eax`, as this is defined to sign-extend the upper
> half of the register, and this has a more compact encoding.
> https://cdrdv2.intel.com/v1/dl/getContent/671488.  See section
> 13.2.1 in particular, which directly contradicts your assertion
> about 32-bit code in 64-bit mode:
> 
> |Assembly/Compiler Coding Rule 56. (H impact, M generality)
> |Use the 32-bit versions of instructions in 64-bit mode to
> |reduce code size unless the 64-bit version is necessary to
> |access 64-bit data or additional registers.
> 
> Regardless, the salient point is that what x86 did is not a
> universe switch into a totally foreign (non-native) ISA.  You
> seem to be comflating this with difficulties stemming from
> running totally unmodified 32-bit programs that assume a 32-bit
> execution mode while in 64-bit mode.  But that is qualitatively
> different than how instructions are encoded and used on x86 with
> respect to the processor "mode", which is almost nothing like
> how the VAX treated PDP-11 compatibility mode.

The topic was how to switch architecture.

Let us call it going from N/2 bit architecture to N
bit architecture.

With hardware compatibility there are two fundamentally
different approaches:
A) having a compatibility bit and when not set don't
    support all N/2 bit instructions and when set support
    all N/2 bit instructions
B) not having a compatibility bit and always support all
    N/2 bit instructions

The choice of approach has implications:
- for the OS
- for the ability to mix N bit and N/2 bit code (it is
   possible with approach B but not with A)

In case of approach A it doesn't really matter if "not all"
is "almost all" or "none".

Even with "almost all" the OS need to distinguish between
bitness of programs and code doesn't mix.

DEC and AMD both those approach A. AMD may have been in
the "almost all" and DEC in the "none" subgroup, but that
doesn't matter for the software.

DG chose approach B.

Arne


Arne