[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