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

[Dan Cross]

In article <uci441$lgj$2 at news.misty.com>,
Johnny Billquist  <bqt at softjar.se> wrote:
>On 2023-08-28 13:15, John Dallman wrote:
>> In article <ucgkbf$1bupe$2 at dont-email.me>, arne at vajhoej.dk (Arne Vajhøj)
>> wrote:
>> 
>>> On 8/27/2023 8:45 AM, Dan Cross wrote:
>>>> 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.
>>>
>>> You cannot mix code.
>>>
>>> A 64 bit program cannot use 32 bit libraries.
>>>
>>> The build will detect it and reject it. But if that check was
>>> disabled then the result would be almost guaranteed to crash.
>> 
>> Dan is distinguishing between what the x86-64 hardware can do, and what
>> the commonly-used operating systems support.
>> 
>> None of Linux, macOS and Windows support calling libraries built for the
>> x86-32 versions of the respective operating systems from programs built
>> for the x86-64 versions of the operating systems. You're quite right
>> about that.
>
>[...]
>
>I've tried to stay out, and don't want to get too deep in.
>But in a sense, my question/issue would be: Can you take a binary for 
>x86 and run it without any "mode bit", or anything else, on an x86-64 
>and it works?

Provided you set up segmentation correctly, those binaries will
run just fine.  You simply execute it in a 32-bit code segment,
with 32-bit data segments.  Is a "mode" bit involved?  Kinda
sorta, but that's an implementation detail.  Usually the OS does
this for you; the user program doesn't care.

But this is a strawman argument that is, again, besides the
point I was making.  I never said you don't have to take care
when running 32-bit binaries on a 64-bit system, nor did I say
that _every_ instruction is compatible between 32-bit and 64-bit
x86.

If we go back to what Arne said, I was responding to this bit:

|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.
(https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/M2Ef9LyHAAAJ)

Note, again, the use of the word "instructions" here.

And here's the rub: this is factually incorrect on the technical
points of what AMD did _at the instruction level_: in fact,
x86_64 will run "32-bit" _instructions_ in 64-bit mode just fine
just as DG's MV would run NOVA and Eclipse instructions.  One
needn't switch back into 32-bit mode to execute a 32-bit
instruction, provided the semantics match what the program is
trying to do.

This is in sharp contrast to what DEC did with PDP-11
compatibility mode on the VAX, where one _had_ to enter PDP-11
mode to execute a 16-bit _instruction_ because the ISA was
totally incompatible.

>Individual instructions is not all. Will the stack offsets remain the 
>same when I push stuff, will address references be fine when I just use 
>32 bits, and do arithmetic and address offsets and so on.

This is true, but a) I never claimed that it was "all", b) I
mentioned the stack instructions explicitly, and c) I pointed
to the architecture manual that addressed issues of instruction
oerands and doing e.g. arithmetic.  Quoting again from the Intel
Software Optimization Manual again:

|64-bit mode makes 16 general purpose 64-bit registers available
|to applications. If application data size is 32 bits, there is
|no need to use 64-bit registers or 64-bit arithmetic.
|
|The default operand size for most instructions is 32 bits. The
|behavior of those instructions is to make the upper 32 bits all
|zeros. For example, when zeroing out a register, the following
|two instruction streams do the same thing, but the 32-bit
|version saves one instruction byte:
|
|32-bit version:
|
|    xor eax, eax;	Performs xor on lower 32bits and zeroes
|    ;			the upper 32 bits.
|
|64-bit version:
|
|    xor rax, rax; Performs xor on all 64 bits.
|
|This optimization holds true for the lower 8 general purpose
|registers: EAX, ECX, EBX, EDX, ESP, EBP, ESI, EDI. To access
|the data in registers R9-R15, the REX prefix is required.
|Using the 32-bit form there does not reduce code size.

In other words, if you don't need 64-bit operands, use the
32-bit instructions in long-mode.  If you need the 64-bit
operands, use the 64-bit instructions.  This is something one
would not be able to easily do on the VAX because switching
modes would be required, but is something you could trivially
do on the DG MV, which is the point.  As Chris Scheers pointed
out regarding the DG machines, this sort of instruction mixing
was common and, "If you need a 32 bit result, you use an MV
instruction.  If you need a 16 bit (or less) result, you can use
any of the instructions."  Same on x86, not the same on VAX.

>If that is the case, then yes, it has been done the same way DG did it. 
>Which truly meant you could take your old binaries and run them on the 
>newer hardware without any added trickery.

Again, I was not talking about arbitrary binaries; I was talking
about executing 32-bit and 64-bit instructions in the same
instruction stream.  Arne was simply wrong when he likened DEC's
scheme to AMD's here.

Morever, let's look at what DG actually did with the Eclipse/MV.

|MV/8000 - C/350 Compatibility
|The MV/8000 supports the instruction mnemonics and binary
|opcodes of _most_ instructions implemented on the ECLIPSE
|C/350.  This means that _most_ programs that execute on the
|C/350 computer will also execute on the MV/8000 without
|recompiling or reassmbling.
(http://www.bitsavers.org/pdf/dg/mv8000/014-00648_MV8000_PrincOps_Apr80.pdf)

Emphasis added; note the use of the word "most"; DG never
claimed that _all_ such programs would run on the MV without
change.  Some more details here:
https://people.computing.clemson.edu/~mark/330/kidder/no_mode_bit.txt

See also Appendix C of the aforementioned DG Principles of
Operation document; from page 361:

|The MV/8000 computer allows you to execute C/350 programs when
|operating under the AOS/VS operating system.  Programs that
|include C/350 instructions _must meet certain requirements to
|be executed properly, however._
(Emphasis added.)

On page 362,
|If the C/350 MAP is enabled, MV/8000-specific instructions
|cannot be executed.  Any attempt to do so causes a narrow I/O
|protection failt to occur....

On page 363,
|Calling a C/350 Subroutine From an MV/8000 Program
|An MV/8000 program can call a C/350 subroutine, though such an
|arrangement requires many changes to the C/350 subroutine.
|These changes are showin in Table C.1.

Among such changes, replacing SAVE and RTN instructions with
their wide variants; "All references from outside routines may
need new memory reference instructions", "short negative
reference on the stack may require new displacements", and
"check routines that are referenced by a JSR through page zero
to save the 32-bit PC."

So, like x86, calling 16-bit code on MV requires care.

>If "it works, but some things will break", then it don't work. If you 
>need to turn on some mode bit in order for it to work, then it is not 
>like DG did it. (See previous comments about mode bits...)

See above.  But again, we're getting far afield from the
original correction about instructions and modes.

>If the fact is just that a program written for x86-64 can also use 
>instructions from the x86 intermixed with new stuff, then sure. It 
>allows code written for the x86-64 to use a (possibly) larger 
>instruction set. But that code/program will not run on an x86.

Of course, the same was true of DG.  Surely no one would expect
an MV/8000 program that used the "MV/8000-specific instructions"
or the "wide stack" to execute unmodified on a C/350 computer?

>So, while not entirely as much of a different mode than the VAX PDP-11 
>mode, it's really still more on that side than the DG side, I would say.

People are fixating on the mode-bit without looking at how the
instruction encoding and execution actually works, which was my
point.

If we go back to what Chris Scheers wrote again:

|Actually, DG's approach allows mixing NOVA, Eclipse, and MV
|instructions in the same instruction stream. Actually, it not
|only allowed [sic], it is normal to do this.
|
|The advantage is instruction size. NOVA instructions are one
|word (16 bits). Eclipse instructions are 1 or 2 word, and MV
|instructions are 1 to 4 words. They are actually pretty elegant
|about how you can mix them.
|
|If you need a 32 bit result, you use an MV instruction.
|
|If you need a 16 bit (or less) result, you can use any of the
|instructions.
|
|In general, MV instructions can reference the whole 4GB memory
|space directly.
|
|NOVA and Eclipse instructions are still 16 bit, but 32 bit
|aware.
|
|PC relative branches can use NOVA or Eclipse instructions if
|the branch destination is in the range of the shorter offset in
|the instruction.  Otherwise, MV instructions are used for
|"long" branches.
|
|NOVA and Eclipse instructions running on an MV can directly
|address the first 32KW of the current ring.
|
|16 bit results in registers are extended to 32 bits.

This is almost exactly what x86 does (see the above quotation
from the Intel Software Optimization Manual).  But of course,
once we start talking about mixing MV, Eclipse and NOVA
instructions in the same instruction stream, we're no longer
talking about running unmodified, pre-linked programs.
Similarly, with x86, once we start talking about binaries that
use REX-prefixed instructions in the same text as "legacy"
instructions, we're again no longer talking about unmodified
binaries for 32-bit Linux, Windows, FreeBSD, SCO, or whatever.

>Oh, and with that said. The DG way was *horrible*. You had two different 
>stacks, a total of 7 registers to deal with the two stacks (don't even 
>ask), if I remember right even duplicates of similar instructions for if 
>you wanted to make use of the larger address space and registers.
>It was *not* something I would want to throw on anyone. The VAX way was 
>much better, and that compatibility mode could be dropped, or shifter 
>over to software when it became less important, and leave the actual VAX 
>clean and nice (relatively speaking).

Just so.  AMD evidently learned from both DEC and DG here and
chose something that was a combination of both, but unlike
either.  In terms of the ability to execute 32-bit instructions
in 64-bit mode, however, I maintain that they were closer to
DG than DEC.

	- Dan C.