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

[Dan Cross]

In article <ucj9la$1t9kd$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 8/28/2023 8:32 AM, Johnny Billquist wrote:
>Some things will break.
>
>It is not easy to get 32 bit code executed in 64 bit mode,

See, this is where it is important to provide your
definitions, not smugly dismiss the question.

Because if by "32 bit code" you mean 32-bit instructions
using 32-bit opcodes, then this is actually trivial and
normal: the CPU just does it, and most compilers will emit
more compact "legacy" instructions for things that don't
_need_ access to 64-bit operands or addresses.

If, instead, you mean "object code compiled and linked
assuming a pure 32-bit execution environment" then you may have
sort of a point.

But it's important to make the distinction.

>[snip]

Ya know, you could have just pointed out that the `push`
instruction changes the amount that it decrements the stack
pointer by in 64-bit mode versus 32-bit mode.  It's in the
manual, after all.

What's ironic is that something analogous to that example you
created would almost certainly have behaved differently on
MV/8000 instead of earlier Eclipse as well, since AMD did what
DG did in choosing a little-used prefix (essentially) to
distinguish the MV opcode space from the C/350 opcode space.
I posted this earlier:
https://people.computing.clemson.edu/~mark/330/kidder/no_mode_bit.txt

>Actually there are more reasons for that than just the unsafe
>nature of executing 32 bit instructions in 64 bit mode.
>
>Common toolchains use a different calling convention for 32 bit
>and 64 bit. For 32 bit they typical prefix function name with an
>underscore and pass arguments by stack (lots of variations though).
>For 64 bit they do not prefix and pass first arguments by register.

Again, you are conflating implementation on a particular system
with how the architecture behaves: the hint is in the term
"calling _convention_".

Again, all while pushing a strawman: recall my responses were
about instruction execution vis the mode bit; I was not
concerned with linking against old libraries, just correcting
your mistatement about AMD64's long mode being like the VAX-11
PDP-11 compatibility mode.

>But it is possible with a little creativity. Assembler
>byte directives are not checked for mode.
>
>But my hypothesis is that if a call from 64 to 32 had been safe,
>then there would have been created a workaround for the calling
>convention.
>
>void __call32bit f()
>
>or whatever.

It's called a far jump.

	- Dan C.