[Info-vax] VAX vs. MV/8000 [was Re: Hard links on VMS ODS5 disks]
John Dallman
jgd at cix.co.uk
Mon Aug 28 07:15:00 EDT 2023
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.
However, Dan is saying that the hardware can run instructions that use
32-bit (rather than 64-bit) offsets from segment registers, or something
similar, mingled with code that uses 64-bit constructs. It has
capabilities that the commonly-used operating systems can't exploit. I'll
take his word for it; I have not dug into that side of x86-64.
I do know that x86-64 hardware can run x86-16 code, and it would be
possible for x86-64 Windows to run old WIN16 software if Microsoft had
been willing to do the work to implement that. They left it out, as a
deliberate (and publicised) choice.
There is an ABI for x86-64 called "x32" that provides the larger register
set of x86-64 but stores pointers in memory in 32-bit form. This was
invented to provide better performance for programs that have no need for
more than 4GB RAM, but has not become popular
<https://en.wikipedia.org/wiki/X32_ABI>.
John
More information about the Info-vax
mailing list