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

[Arne Vajhøj]

On 8/27/2023 10:11 PM, Dan Cross wrote:
> 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:
>>>> 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.

I am talking about all the big companies (IBM, Oracle, MS etc.)
and open source projects that publicize native code
specifying 32bit/x86/i686 or 64bit/x86_64/x64/AMD64 and
all the millions of sys admins and developers that
daily doesn't seem to have a problem downloading the
right one that works in their context.

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

It does not really matter what system.

Some 32 bit instructions produce wrong result when executed
in 64 bit model and some 32 bit instructions crash when
executed in 64 bit mode.

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

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

The premise was that DG could do without compatibility
mode what other did with a compatibility mode.

It was said to be the case.

I don't know personally as I have never used a DG system.

But it seems rather plausible. Because they did not
offer a compatibility mode.

Either the Eclipse MV could execute at least all
instructions outputted by Eclipse compilers and
commonly used by assembler programmers on Eclipse, so
an Eclipse executable can be expected to run on
Eclipse MV - or Eclipse MV was not compatible
with Eclipse.

x86-64 does not need to be able to execute all
32 bit instructions in 64 bit mode, because it
has a 32 bit compatibility mode.

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

Yes - it is how it works.

Some 32 bit instructions produce wrong result when
executed in 64 bit mode and some 32 bit instructions
crashed when executed in 64 bit mode.

You can try yourself. Code posted in other post.

Arne