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

[Dan Cross]

In article <ucgjus$1bupe$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>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".

Read what you wrote that I quoted above.

>From article <ucbh82$8kpo$2 at dont-email.me>, you write:
|[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).

Note your use of the word "instructions."

You are simply wrong here; AMD did nothing like what DEC did,
where PDP-11 compatibility mode on the VAX-11 switched mode into
a totally different, and incompatible, ISA.  AMD instead did
something much closer to what DG did, where you _can_ intermix
32-bit and 64-bit instructions in the same instruction stream.
Indeed, that is the _norm_ for for the exact same efficiency
reasons DG did supported it.

>>> 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.

If by "everybody else in the industry" you mean IT people with
a "TechCrunch" level of understanding, perhaps you are right,
but as you demonstrate in this conversation, those folks are
not experts on the technology details.

>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.

You are conflating the implementation detail of a particular
code generation convention on systems you are familiar with,
with details of the architecture and instruction set.

Moreover, it's not correct; long jumps and call-gating allow you
to switch between architectural contexts on a per-segment basis,
even within the same "process."

Besides, that's not what you wrote, as we saw above.

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

That's not the correct answer to the above question, which was
asking you to clarify what you meant.

Are you saying that x86_64 cannot use 32-bit instructions in the
same "process" (what is your definition of a "process" in this
context?), in direct contravention of what the architecture
optimization manual tells you to do?

>> mentioned above, the instruction encoding is _mostly_ the same.
>
>Yes. "mostly".

Yes.  Mostly.  Meaning it's nothing like what DEC did with the
PDP-11 compatibility mode on the VAX.

>>> 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.

No, see above.  The topic was intermixing 32-bit and 64-bit
_instructions_ in a single binary, dependent on mode.  Perhaps
that's not what you meant, but that's what you wrote, and that's
what I responded to.

>[snip some tortured thing about mode bits missing the point]
>>> Actually, DG's approach allows mixing NOVA, Eclipse, and MV instructions
>>> in the same instruction stream. Actually, it not only allowed, it is
>>> normal to do this.
>>
>> Ah, this is precisely what x86 does, again underscoring how it
>> is different from the approach that DEC chose with PDP-11
>> compatibility on the VAX.
>
>That is not how x86-64 work.

Incorrect.

>You cannot mix code.

You don't have a particularly good handle on what "code" means
here.

>A 64 bit program cannot use 32 bit libraries.

Again, you are conflating an architectural issue with the
implementation of some code-generation system that you are
familiar with.  That is, where you are saying, "a 64 bit
program cannot use 32 bit libraries" what you really mean is,
"that is not done by systems that I am familiar with."

In fact, there are many ways for a 64-bit program to make use of
32-bit libraries on x86; one might use a long-jump to a 32-bit
code segment, for example; or, for a particular language, if one
knows that one is calling from 64- into 32-bit code, one ensures
that arguments are passed appropriately (e.g., pointers to
somewhere in the first 4GiB of the address space, etc).

But none of this is relevant to the original point: 32-bit
instructions are freely mingled with 64-bit instructions in
long mode, which is utterly unlike what DEC did with PDP-11
compatibilty mode on the VAX, which again, was the original
point I was making.

>The build will detect it and reject it. But if that check was
>disabled then the result would be almost guaranteed to crash.

Again, your confusion here comes from conflating a general
misunderstanding of how the architecture works with specifics of
some implementation.

>If I understand the peoples description of Eclipse MV and AOS/VS
>correct then it 32 bit code can call 16 bit code.

The description from Chris Scheers earlier said that "DG's
approach allows mixing NOVA, Eclipse, and MV instructions in the
same application stream.  Actually, it not only allowed, it is
normal to do this."
(https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/Uie6Ez7rAAAJ)
(again, note the use of the word _instructions_)

The _exact_ same is true of x86.  Yet you continue to argue that
x86 is somehow "different" because, say, Linux or maybe VMS
won't let you link 32-bit libraries into a 64-bit binary; that
is an implementation detail, and by fixating on that you show
that you don't understand how the DG or x86 architectures work.

In particular, you seem to think that _no_ instruction required
special handling on MV, which is almost certainly not the case.

Moreoever, this wasn't the original point at all.  Perhaps you
have heard the expression, "moving the goal posts?"

>That is one of the benefits of not having the mode bit.

The mode bit has nothing to do with it.  You started by
conflating the mode bith with whether the ISA is completely
distinct or shared--at least partially.  On the VAX, you could
not mix 16-bit and 32-bit _instructions_ because the two ISAs
were not at all compatible; your mistake was stating that the
same is true on x86: it is not.

>The fact that maybe 98% of the instructions in 32 bit x86
>code would work fine interpreted as 64 bit x86-64 code
>and only maybe 2% would return wrong results or crash
>is about as relevant as the background color used when
>running the program.

That's not how it works.

>Almost compatible is not compatible.

You are really confused as to both how the DG system _actually
worked_, and how x86 _actually works_, and how both are
different from how PDP-11 compatibility mode _worked on VAX_.

Suggesting that you cannot use 32-bit x86 instructions in 64-bit
mode on x86_64, even after being given the actual text from the
architecture manual, is simply ignorant.  At this point, you
seem to be arguing a different point, but that is neither what
you said originally, nor particularly relevant to the topic at
hand.

	- Dan C.