Arne Vajhøj wrote:

> DG approach seems more elegant as it must have
> allowed new 32 bit code to call old 16 bit code
> within the same program. If someone knew how to
> ensure that everything got set up properly (somewhat
> similar to VMS code today using 64 bit pointers needing
> to call code using 32 bit pointers - you better have
> the data in P0 and not P2).

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.

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.

A lot of DG programming is based on the idea of a conditional skip. A
skip increments the PC by 1. So it is very common to have an MV
instruction with a conditional skip that is directly followed by a NOVA
or (one word) Eclipse instruction.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: chris@applied-synergy.com
Fax: 817-237-3074

In article <uces30$12gsl$1@dont-email.me>,
Chris Scheers <chris@applied-synergy.com> wrote:
>Arne Vajhøj wrote:
>> DG approach seems more elegant as it must have
>> allowed new 32 bit code to call old 16 bit code
>> within the same program. If someone knew how to
>> ensure that everything got set up properly (somewhat
>> similar to VMS code today using 64 bit pointers needing
>> to call code using 32 bit pointers - you better have
>> the data in P0 and not P2).
>
>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.

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

Again, this is almost exactly what x86 does today. x86 is
otherwise a dumpster fire of bad design, but the approach they
took with the 64-bit extensions is spiritually closer to what
DG did with Nova, Eclipse, and MV than what DEC did.

- Dan C.

On 8/26/2023 3:09 PM, Dan Cross wrote:
> In article <ucdapd$ljc8$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/26/2023 9:34 AM, Dan Cross wrote:
>>> In article <ucbh82$8kpo$2@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> [snip]
>>>> DEC chose to have the VAX switch mode between 32 and
>>>> 16 bit instructions (similar to what AMD did a couple
>>>> of decades later).
>>>
>>> One presumes you are referring to amd64 here. If so, then nope,
>>> amd64 is an extension to 32-bit x86, not a replacement in the
>>> sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
>>> was set.
>>>
>>> Even in 64-bit mode, many (most?) programs will continue to
>>> operate as expected with 32- and even many 16- bit instructions.
>>> The same was not true of the VAX.
>>
>> x86-64 in long mode has an emulation mode set via
>> an emulation bit that allows it to execute 32 bit
>> programs.
>>
>> That is the same as what VAX did for PDP-11
>> compatibility.
>
> Not even close. PDP-11 compatibility mode on the VAX uses an
> entirely different instruction encoding (PDP-11 encoding for
> PDP-11 instructions) compared to VAX-native instructions.
> http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf
>
> By contrast, AMD64 mode shares most of the instruction space
> with 32-bit x86. `xorl %eax, %eax` works just fine in either
> 32-bit or 64-bit mode, with the exact same encoding. AMD used
> a prefix byte to indicate 64-bit operands to instructions.
> For example, see Chapter 2 of
> https://cdrdv2.intel.com/v1/dl/getContent/671110
>
> Of course, the semantics of a few instructions do change (the
> size of words on the stack changes, for example, so the `PUSH`
> instruction behaves differently in 64-bit mode), but in this
> regard, the mechanism is closer to what DG did than what DEC
> did.

I think the operative word is "most".

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

Code compiled for x86-64 vs code compiled for x86.

Binaries packages for AMD64/x86_64/x64 vs for i686/x86.

Code compiled with GCC with -m64 vs -m32.

> And what do you mean when you say
> that you "cannot mix" them "in the same process"?

Yes.

> As I
> mentioned above, the instruction encoding is _mostly_ the same.

Yes. "mostly".

>> Most 32 bit instructions actually work identical
>> in 64 bit mode, but some produce different results
>> and some causes a crash.
>
> Correct.
>
>> So executing 32 bit code not in compatibility mode
>> is a big no no.
>
> Incorrect. Indeed, the optimization manual encourages using
> 32-bit instructions (ie, without a REX prefix) in some common
> code sequences, even in 64-bit mode, for efficiency reasons.
> For example, the quickest way to clear, e.g., `%rax` is
> `xorl %eax, %eax`, as this is defined to sign-extend the upper
> half of the register, and this has a more compact encoding.
> https://cdrdv2.intel.com/v1/dl/getContent/671488. See section
> 13.2.1 in particular, which directly contradicts your assertion
> about 32-bit code in 64-bit mode:
>
> |Assembly/Compiler Coding Rule 56. (H impact, M generality)
> |Use the 32-bit versions of instructions in 64-bit mode to
> |reduce code size unless the 64-bit version is necessary to
> |access 64-bit data or additional registers.
>
> Regardless, the salient point is that what x86 did is not a
> universe switch into a totally foreign (non-native) ISA. You
> seem to be comflating this with difficulties stemming from
> running totally unmodified 32-bit programs that assume a 32-bit
> execution mode while in 64-bit mode. But that is qualitatively
> different than how instructions are encoded and used on x86 with
> respect to the processor "mode", which is almost nothing like
> how the VAX treated PDP-11 compatibility mode.

The topic was how to switch architecture.

Let us call it going from N/2 bit architecture to N
bit architecture.

With hardware compatibility there are two fundamentally
different approaches:
A) having a compatibility bit and when not set don't
support all N/2 bit instructions and when set support
all N/2 bit instructions
B) not having a compatibility bit and always support all
N/2 bit instructions

The choice of approach has implications:
- for the OS
- for the ability to mix N bit and N/2 bit code (it is
possible with approach B but not with A)

In case of approach A it doesn't really matter if "not all"
is "almost all" or "none".

Even with "almost all" the OS need to distinguish between
bitness of programs and code doesn't mix.

DEC and AMD both those approach A. AMD may have been in
the "almost all" and DEC in the "none" subgroup, but that
doesn't matter for the software.

DG chose approach B.

Arne

Arne

On 8/27/2023 8:45 AM, Dan Cross wrote:
> In article <uces30$12gsl$1@dont-email.me>,
> Chris Scheers <chris@applied-synergy.com> wrote:
>> Arne Vajhøj wrote:
>>> DG approach seems more elegant as it must have
>>> allowed new 32 bit code to call old 16 bit code
>>> within the same program. If someone knew how to
>>> ensure that everything got set up properly (somewhat
>>> similar to VMS code today using 64 bit pointers needing
>>> to call code using 32 bit pointers - you better have
>>> the data in P0 and not P2).
>>
>> 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.

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.

If I understand the peoples description of Eclipse MV and AOS/VS
correct then it 32 bit code can call 16 bit code.

That is one of the benefits of not having the mode bit.

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.

Almost compatible is not compatible.

Arne

In article <ucgjus$1bupe$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 8/26/2023 3:09 PM, Dan Cross wrote:
>> In article <ucdapd$ljc8$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 8/26/2023 9:34 AM, Dan Cross wrote:
>>>> In article <ucbh82$8kpo$2@dont-email.me>,
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> [snip]
>>>>> DEC chose to have the VAX switch mode between 32 and
>>>>> 16 bit instructions (similar to what AMD did a couple
>>>>> of decades later).
>>>>
>>>> One presumes you are referring to amd64 here. If so, then nope,
>>>> amd64 is an extension to 32-bit x86, not a replacement in the
>>>> sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
>>>> was set.
>>>>
>>>> Even in 64-bit mode, many (most?) programs will continue to
>>>> operate as expected with 32- and even many 16- bit instructions.
>>>> The same was not true of the VAX.
>>>
>>> x86-64 in long mode has an emulation mode set via
>>> an emulation bit that allows it to execute 32 bit
>>> programs.
>>>
>>> That is the same as what VAX did for PDP-11
>>> compatibility.
>>
>> Not even close. PDP-11 compatibility mode on the VAX uses an
>> entirely different instruction encoding (PDP-11 encoding for
>> PDP-11 instructions) compared to VAX-native instructions.
>> http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf
>>
>> By contrast, AMD64 mode shares most of the instruction space
>> with 32-bit x86. `xorl %eax, %eax` works just fine in either
>> 32-bit or 64-bit mode, with the exact same encoding. AMD used
>> a prefix byte to indicate 64-bit operands to instructions.
>> For example, see Chapter 2 of
>> https://cdrdv2.intel.com/v1/dl/getContent/671110
>>
>> Of course, the semantics of a few instructions do change (the
>> size of words on the stack changes, for example, so the `PUSH`
>> instruction behaves differently in 64-bit mode), but in this
>> regard, the mechanism is closer to what DG did than what DEC
>> did.
>
>I think the operative word is "most".

Read what you wrote that I quoted above.

From article <ucbh82$8kpo$2@dont-email.me>, you write:
|[snip]
|DEC chose to have the VAX switch mode between 32 and
|16 bit instructions (similar to what AMD did a couple
|of decades later).

Note your use of the word "instructions."

You are simply wrong here; AMD did nothing like what DEC did,
where PDP-11 compatibility mode on the VAX-11 switched mode into
a totally different, and incompatible, ISA. AMD instead did
something much closer to what DG did, where you _can_ intermix
32-bit and 64-bit instructions in the same instruction stream.
Indeed, that is the _norm_ for for the exact same efficiency
reasons DG did supported it.

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

>Code compiled for x86-64 vs code compiled for x86.
>
>Binaries packages for AMD64/x86_64/x64 vs for i686/x86.
>
>Code compiled with GCC with -m64 vs -m32.

You are conflating the implementation detail of a particular
code generation convention on systems you are familiar with,
with details of the architecture and instruction set.

Moreover, it's not correct; long jumps and call-gating allow you
to switch between architectural contexts on a per-segment basis,
even within the same "process."

Besides, that's not what you wrote, as we saw above.

>> And what do you mean when you say
>> that you "cannot mix" them "in the same process"?
>
>Yes.

That's not the correct answer to the above question, which was
asking you to clarify what you meant.

Are you saying that x86_64 cannot use 32-bit instructions in the
same "process" (what is your definition of a "process" in this
context?), in direct contravention of what the architecture
optimization manual tells you to do?

>> mentioned above, the instruction encoding is _mostly_ the same.
>
>Yes. "mostly".

Yes. Mostly. Meaning it's nothing like what DEC did with the
PDP-11 compatibility mode on the VAX.

>>> Most 32 bit instructions actually work identical
>>> in 64 bit mode, but some produce different results
>>> and some causes a crash.
>>
>> Correct.
>>
>>> So executing 32 bit code not in compatibility mode
>>> is a big no no.
>>
>> Incorrect. Indeed, the optimization manual encourages using
>> 32-bit instructions (ie, without a REX prefix) in some common
>> code sequences, even in 64-bit mode, for efficiency reasons.
>> For example, the quickest way to clear, e.g., `%rax` is
>> `xorl %eax, %eax`, as this is defined to sign-extend the upper
>> half of the register, and this has a more compact encoding.
>> https://cdrdv2.intel.com/v1/dl/getContent/671488. See section
>> 13.2.1 in particular, which directly contradicts your assertion
>> about 32-bit code in 64-bit mode:
>>
>> |Assembly/Compiler Coding Rule 56. (H impact, M generality)
>> |Use the 32-bit versions of instructions in 64-bit mode to
>> |reduce code size unless the 64-bit version is necessary to
>> |access 64-bit data or additional registers.
>>
>> Regardless, the salient point is that what x86 did is not a
>> universe switch into a totally foreign (non-native) ISA. You
>> seem to be comflating this with difficulties stemming from
>> running totally unmodified 32-bit programs that assume a 32-bit
>> execution mode while in 64-bit mode. But that is qualitatively
>> different than how instructions are encoded and used on x86 with
>> respect to the processor "mode", which is almost nothing like
>> how the VAX treated PDP-11 compatibility mode.
>
>The topic was how to switch architecture.

No, see above. The topic was intermixing 32-bit and 64-bit
_instructions_ in a single binary, dependent on mode. Perhaps
that's not what you meant, but that's what you wrote, and that's
what I responded to.

>[snip some tortured thing about mode bits missing the point]
>>> 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."

In fact, there are many ways for a 64-bit program to make use of
32-bit libraries on x86; one might use a long-jump to a 32-bit
code segment, for example; or, for a particular language, if one
knows that one is calling from 64- into 32-bit code, one ensures
that arguments are passed appropriately (e.g., pointers to
somewhere in the first 4GiB of the address space, etc).

But none of this is relevant to the original point: 32-bit
instructions are freely mingled with 64-bit instructions in
long mode, which is utterly unlike what DEC did with PDP-11
compatibilty mode on the VAX, which again, was the original
point I was making.

>The build will detect it and reject it. But if that check was
>disabled then the result would be almost guaranteed to crash.

Again, your confusion here comes from conflating a general
misunderstanding of how the architecture works with specifics of
some implementation.

>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."
(https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/Uie6Ez7rAAAJ)
(again, note the use of the word _instructions_)

On Sunday, August 27, 2023 at 8:46:01 AM UTC-4, Dan Cross wrote:
> Again, this is almost exactly what x86 does today. x86 is
> otherwise a dumpster fire of bad design, but the approach they
> took with the 64-bit extensions is spiritually closer to what
> DG did with Nova, Eclipse, and MV than what DEC did.

Intel has proposed X86-S which jettisons most of the 32-bit and
16-bit parts of the architecture. That might let them clean up their
microarchitecture (or at least provide a larger microcode patch
area 8-).

I expect there will be unpleasant surprises if S-mode processors
make it to operating system developers (outside of "most favored
nation" ones like Microsoft).

In article <ucgkbf$1bupe$2@dont-email.me>, arne@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

On 2023-08-28 13:15, John Dallman wrote:
> In article <ucgkbf$1bupe$2@dont-email.me>, arne@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?

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.

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.

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

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.

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.

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

(And the PDP-11 mode on the VAX meant that you could take most user
space PDP-11 binaries over to the VAX and run them, which was the same
goal both DEC and DG had. Just the two different approaches to
accomplish it.)

Johnny

In article <uci441$lgj$2@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-08-28 13:15, John Dallman wrote:
>> In article <ucgkbf$1bupe$2@dont-email.me>, arne@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.
|
Click here to read the complete article

In article <0f65bba5-93d1-469f-8bc9-9e9d91da6d76n@googlegroups.com>,
terry-...@glaver.org <terry-groups@glaver.org> wrote:
>On Sunday, August 27, 2023 at 8:46:01 AM UTC-4, Dan Cross wrote:
>> Again, this is almost exactly what x86 does today. x86 is
>> otherwise a dumpster fire of bad design, but the approach they
>> took with the 64-bit extensions is spiritually closer to what
>> DG did with Nova, Eclipse, and MV than what DEC did.
>
>Intel has proposed X86-S which jettisons most of the 32-bit and
>16-bit parts of the architecture. That might let them clean up their
>microarchitecture (or at least provide a larger microcode patch
>area 8-).

With some caveats... They will retain 32-bit userspace support,
but yeah, the kernel will be 64-bit only and real mode will go
away. Note, however, that the 32-bit instruction encodings for
using 32-bit operands are not affected. That is, the opcode for
`xorl %eax, %eax` is not changing.

>I expect there will be unpleasant surprises if S-mode processors
>make it to operating system developers (outside of "most favored
>nation" ones like Microsoft).

Outside of people still trying to run DOS programs (frankly,
those folks are better off with whole-machine emulators like
DOSBox anyway), most users won't notice. People like me will
have to care a little bit, but the biggest source of changes
will be in very, very early boot. A more rational startup
sequence will be kinda nice, though they are making noises
about ancilliary processors (e.g., to set up the initial page
tables that the BSP will beginning executing on) that need some
elaboration.

- Dan C.

In article <uci441$lgj$2@news.misty.com>, bqt@softjar.se (Johnny
Billquist) wrote:

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

Depends on how much setup you're willing to do before kicking off the
binary. As Dan says, if you set up the segments right, many of the
instructions will execute, but you'll hit problems with others, and
certainly when you start trying to call OS functions that are at all
complicated.

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

Stack offsets and arithmetic operations will likely be OK; there may be
some corner cases. The problem comes with memory references being passed
between 32-bit and 64-bit code. Those are offsets within segments, and
there is no intrinsic or canonical mapping between 32-bit segments and
64-bit segments on x86.

To run executables intended for a 32-bit OS on a 64-bit OS, the usual
route on x86 is "thunks", small chunks of code that receive OS calls made
by the 32-bit code map the data into 64-bit addressing, and then call the
OS' native 64-bit API. That's how 64-bit Windows and Linux run 32-bit
executable. 64-bit macOS did that too, until Apple removed its ability to
run 32-bit executables. The thunks are collected into special versions of
the various run-time libraries that 32-bit code calls. Sometimes, for
performance reasons, chunks of the "real" 32-bit run0time libraries are
included.

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

No, it isn't the full DG job. But it isn't a VAX-style separate mode
either. It's something in between.

An example of a modern separate mode comes with ARM. The ARM32 and ARM64
instruction sets are /very/ different. Most ARM32 instructions are
conditionally executed using predicate flags in the instructions, taking
up 5 bits in almost all instructions. ARM64 threw that out, and some old
ARM hands reckon ARM64 is more like MIPS than ARM32.

John

On Monday, August 28, 2023 at 12:26:04 PM UTC-4, John Dallman wrote:
> In article <uci441$lgj$2...@news.misty.com>, b...@softjar.se (Johnny
> Billquist) wrote:
>
> > 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?
> Depends on how much setup you're willing to do before kicking off the
> binary. As Dan says, if you set up the segments right, many of the
> instructions will execute, but you'll hit problems with others, and
> certainly when you start trying to call OS functions that are at all
> complicated.
> > 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.
> Stack offsets and arithmetic operations will likely be OK; there may be
> some corner cases. The problem comes with memory references being passed
> between 32-bit and 64-bit code. Those are offsets within segments, and
> there is no intrinsic or canonical mapping between 32-bit segments and
> 64-bit segments on x86.
>
> To run executables intended for a 32-bit OS on a 64-bit OS, the usual
> route on x86 is "thunks", small chunks of code that receive OS calls made
> by the 32-bit code map the data into 64-bit addressing, and then call the
> OS' native 64-bit API. That's how 64-bit Windows and Linux run 32-bit
> executable. 64-bit macOS did that too, until Apple removed its ability to
> run 32-bit executables. The thunks are collected into special versions of
> the various run-time libraries that 32-bit code calls. Sometimes, for
> performance reasons, chunks of the "real" 32-bit run0time libraries are
> included.
> > 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.
> No, it isn't the full DG job. But it isn't a VAX-style separate mode
> either. It's something in between.
>
> An example of a modern separate mode comes with ARM. The ARM32 and ARM64
> instruction sets are /very/ different. Most ARM32 instructions are
> conditionally executed using predicate flags in the instructions, taking
> up 5 bits in almost all instructions. ARM64 threw that out, and some old
> ARM hands reckon ARM64 is more like MIPS than ARM32.
>
> John
I've tried to stay out of this so far, but I do want to point out that 64-bit mode
doesn't use CS, DS, ES, SS segments in that way. You can put whatever values you want into
them, but they read as 0. We do use GS for some things in the OS.

From the architecture manual, Volume 1,
section 3.4.2.1, "Segment Registers in 64-Bit Mode"

In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0, regardless of the value of the associated
segment descriptor base. This creates a flat address space for code, data, and stack. FS and GS are exceptions.
Both segment registers may be used as additional base registers in linear address calculations (in the addressing
of local data and certain operating system data structures).

Even though segmentation is generally disabled, segment register loads may cause the processor to perform
segment access assists. During these activities, enabled processors will still perform most of the legacy checks on
loaded values (even if the checks are not applicable in 64-bit mode). Such checks are needed because a segment
register loaded in 64-bit mode may be used by an application running in compatibility mode.

Limit checks for CS, DS, ES, SS, FS, and GS are disabled in 64-bit mode.

In article <8350f858-079b-4361-be47-97f96a4dde32n@googlegroups.com>,
xyzzy1959@gmail.com (John Reagan) wrote:

> I've tried to stay out of this so far, but I do want to point out
> that 64-bit mode doesn't use CS, DS, ES, SS segments in that way.
> You can put whatever values you want into them, but they read as 0.
> We do use GS for some things in the OS.

Thanks, I had not realised it was limited to the small model.

John

In article <8350f858-079b-4361-be47-97f96a4dde32n@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>On Monday, August 28, 2023 at 12:26:04 PM UTC-4, John Dallman wrote:
>> In article <uci441$lgj$2...@news.misty.com>, b...@softjar.se (Johnny
>> Billquist) wrote:
>>
>> > 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?
>> Depends on how much setup you're willing to do before kicking off the
>> binary. As Dan says, if you set up the segments right, many of the
>> instructions will execute, but you'll hit problems with others, and
>> certainly when you start trying to call OS functions that are at all
>> complicated.
>> > 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.
>> Stack offsets and arithmetic operations will likely be OK; there may be
>> some corner cases. The problem comes with memory references being passed
>> between 32-bit and 64-bit code. Those are offsets within segments, and
>> there is no intrinsic or canonical mapping between 32-bit segments and
>> 64-bit segments on x86.
>>
>> To run executables intended for a 32-bit OS on a 64-bit OS, the usual
>> route on x86 is "thunks", small chunks of code that receive OS calls made
>> by the 32-bit code map the data into 64-bit addressing, and then call the
>> OS' native 64-bit API. That's how 64-bit Windows and Linux run 32-bit
>> executable. 64-bit macOS did that too, until Apple removed its ability to
>> run 32-bit executables. The thunks are collected into special versions of
>> the various run-time libraries that 32-bit code calls. Sometimes, for
>> performance reasons, chunks of the "real" 32-bit run0time libraries are
>> included.
>> > 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.
>> No, it isn't the full DG job. But it isn't a VAX-style separate mode
>> either. It's something in between.
>>
>> An example of a modern separate mode comes with ARM. The ARM32 and ARM64
>> instruction sets are /very/ different. Most ARM32 instructions are
>> conditionally executed using predicate flags in the instructions, taking
>> up 5 bits in almost all instructions. ARM64 threw that out, and some old
>> ARM hands reckon ARM64 is more like MIPS than ARM32.
>>
>> John
>I've tried to stay out of this so far, but I do want to point out that 64-bit mode
>doesn't use CS, DS, ES, SS segments in that way. You can put whatever values you want into
>them, but they read as 0.

It's unclear what you mean here. Do you mean the segment
selectors; that is, the visible portion of the segment
registers? If so, the "read as 0" part is incorrect. They read
as whatever value you write to them (most OS's zero them out
once they get into long mode in early boot). This is easily
shown empirically:

: samudra; cat segregs.c
#include <stdio.h>

int
main()
{ unsigned short cs, ds, es, ss, fs, gs;

cs = 0;
ds = 0;
es = 0;
fs = 0;
gs = 0;
ss = 0;

asm("mov %%cs, %0" : "=r"(cs) ::);
asm("mov %%ds, %0" : "=r"(ds) ::);
asm("mov %%es, %0" : "=r"(es) ::);
asm("mov %%ss, %0" : "=r"(ss) ::);
asm("mov %%fs, %0" : "=r"(fs) ::);
asm("mov %%gs, %0" : "=r"(gs) ::);

printf("cs = %#hx\n", cs);
printf("ds = %#hx\n", ds);
printf("es = %#hx\n", es);
printf("ss = %#hx\n", ss);
printf("fs = %#hx\n", fs);
printf("gs = %#hx\n", gs);

return 0;
} : samudra; make segregs
cc -O2 -pipe -o segregs segregs.c
: samudra; ./segregs
cs = 0x2b
ds = 0x23
es = 0x23
ss = 0x23
fs = 0x23
gs = 0x23
: samudra; file segregs
segregs: ELF 64-bit LSB shared object, x86-64, version 1
: samudra; uname -a
OpenBSD samudra.gajendra.net 7.3 GENERIC.MP#17 amd64
: samudra;

(That's on an i9; same program run on Ryzen, EPYC, and Xeon
under a variety of different operating systems gives similar
results.)

Indeed, if one could not read the selector values in 64-bit mode
then it would not be possible to preserve them on entry to a
64-bit kernel from a 32-bit user-space program.

As an aside, since much of this discussion has revolved around
mixing 32- and 64-bit code in the same "process", Unix is an
interesting example here. Things like kernel page-table
isolation not withstanding, the mental model is that every Unix
process has the kernel mapped into it; 64-bit kernels running
32-bit user programs are, therefore, an example of two different
types of code running in the same "process."

>We do use GS for some things in the OS.

GS and FS are special and commonly used for CPU-local and
thread-local storage, respectively. With the fast system call
instruction support, you pretty much need GS (cf the `SWAPGS`
instruction).

However, none of this means that one cannot use segmentation to
switch into 32-bit compatibility mode; this can be accomplished
in a few different ways, such as by means of a _long jump_ into
a 32-bit code segment, as I mentioned elsewhere in this thread.
Intel calls this a "Far jump" in the documentation of the JMP
instruction: the target is a segment selector, which is an index
into one of the two segment tables (either global or local).

It is correct that just MOV'ing a value into a segmentation
register has little effect in 64-bit mode, but that's not how
you switch into 32-bit mode.

>From the architecture manual, Volume 1,
>section 3.4.2.1, "Segment Registers in 64-Bit Mode"
>
>In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0, regardless of the value of the associated
>segment descriptor base. This creates a flat address space for code, data, and stack. FS and GS are exceptions.

It is important to note that, in this section, the SDM is
talking about the entire segment register, not just the visible
segment selectors we see in %cs et al. The values in the
segment selector portion are indicies into a table of segment
descriptors that are themselves pointed to by the GDTR and LDTR.
In 64-bit the base is always 0 (regardless of what's in the
descriptor) and the limit is ignored. In 32-bit mode, base and
limit are respected.

>Both segment registers may be used as additional base registers in linear address calculations (in the addressing
>of local data and certain operating system data structures).
>
>Even though segmentation is generally disabled, segment register loads may cause the processor to perform
>segment access assists. During these activities, enabled processors will still perform most of the legacy checks on
>loaded values (even if the checks are not applicable in 64-bit mode). Such checks are needed because a segment
>register loaded in 64-bit mode may be used by an application running in compatibility mode.
>
>Limit checks for CS, DS, ES, SS, FS, and GS are disabled in 64-bit mode.

This is good background information for those wishing to
understand the architecture at a level deeper but not super
relevant to the topic at hand. If you want to switch into
32-bit mode from 64-bit mode, you need a far jump/call gate.

But again, all of this is qualitatively different than executing
a 32-bit instruction in 64-bit mode, which is normal.

- Dan C.

On 2023-07-26 00:53:52 +0000, Arne Vajhj said:

> On 7/25/2023 8:52 PM, Arne Vajhøj wrote:
>> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>>> But difficult to check the difference between /OPT and /NOOPT,
>>>> because for some unknown reason /LIST/MACH does not list the
>>>> generated code.
>>>
>>> MACRO-32 on x86?
>>
>> Yes.
>>
>>> You can always (except you compile with /NOOBJECT :-) get the machine
>>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
>>
>> I did not know that.
>>
>> But also weird.
>>
>> I do not see a difference between /OPT and /NOOPT at all.
>
> Tested with a trivial piece of code:
>
> .title str
> .psect $CODE quad,pic,con,lcl,shr,exe,nowrt
> .entry str_int_val,^m<r2,r3,r4>
> movl B^4(ap),r0
> movl B^4(r0),r1 ; address of string
> movzwl (r0),r2 ; length of string
> movl #0,r0 ; value=0
> tstl r2 ; test if empty string
> bleq 400$
> clrl r3
> movl #1,r4 ; scale=1
> 100$: movb (r1),r3
> cmpb #32,r3 ; test if " " => skip
> beql 300$
> cmpb #45,r3 ; test if "-" => scale=-1*scale
> bneq 200$
> mull2 #-1,r4
> brb 300$
> 200$: subb2 #48,r3 ; value=10*value+digit
> mull2 #10,r0
> addl2 r3,r0
> 300$: incl r1
> decl r2
> tstl r2
> bgtr 100$
> mull2 r4,r0 ; value=value*scale
> 400$: movl r0,@B^8(ap)
> ret
> .end
>
> with /NOOPT:
>
> .section $CODE, "ax",
> "progbits" # EXE,SHR
> .align 16
> .cfi_startproc
> STR_INT_VAL::
> 55 00000000: pushq %rbp
> # 000003
> E5 89 48 00000001: movq %rsp,%rbp
> 53 00000004: pushq %rbx
> 57 41 00000005: pushq %r15
> 56 41 00000007: pushq %r14
> 55 41 00000009: pushq %r13
> DC B6 0F 0000000B: movzbl %ah,%ebx
> 00 00 00 00 E8 0000000E: callq
> LIB$ALPHA_REG_VECTOR_BASE@PLT
> 93 48 00000013: xchgq %rax,%rbx
> 54 41 00000015: pushq %r12
> 00 00 00 80 BB 89 48 00000017: movq %rdi,00000080(%rbx)
> 00 00 00 88 B3 89 48 0000001E: movq %rsi,00000088(%rbx)
> 20 73 FF 00000025: pushq 20(%rbx)
> 18 73 FF 00000028: pushq 18(%rbx)
> 10 73 FF 0000002B: pushq 10(%rbx)
> 00 6A 0000002E: pushq $00
> E4 89 49 00000030: movq %rsp,%r12
> _$$L1:
> 00 00 00 80 93 63 4C 00000033: movslq
> 00000080(%rbx),%r10 #
> 000004
> 13 89 4C 0000003A: movq %r10,(%rbx)
> 13 8B 4C 0000003D: movq (%rbx),%r10
> # 000005
> 04 5A 63 4D 00000040: movslq 04(%r10),%r11
> 08 5B 89 4C 00000044: movq %r11,08(%rbx)
> 13 8B 4C 00000048: movq (%rbx),%r10
> # 000006
> 1A B7 0F 4D 0000004B: movzwq (%r10),%r11
> 10 5B 89 4C 0000004F: movq %r11,10(%rbx)
> 00 00 00 00 03 C7 48 00000053: movq $00000000,(%rbx)
> # 000007
> 10 53 63 4C 0000005A: movslq 10(%rbx),%r10
> # 000008
> 00 FA 83 41 0000005E: cmpl $00,%r10d
> 9F 00000062: lahf
> C7 89 41 66 00000063: movw %ax,%r15w
> F8 89 44 66 00000067: movw %r15w,%ax
> # 000009
> FF FE E0 81 66 0000006B: andw $-0002,%ax
> 9E 00000070: sahf
> 00 00 00 BC 8E 0F 00000071: jle 3_400$
> C0 31 48 00000077: xorq %rax,%rax
> # 000010
> 18 43 89 48 0000007A: movq %rax,18(%rbx)
> 00 00 00 01 20 43 C7 48 0000007E: movq
> $00000001,20(%rbx) #
> 000011
> 3_100$:
> 08 53 8B 4C 00000086: movq 08(%rbx),%r10
> # 000012
> 1A B6 0F 4D 0000008A: movzbq (%r10),%r11
> 18 5B 88 44 0000008E: movb %r11l,18(%rbx)
> 18 53 B6 0F 4C 00000092: movzbq 18(%rbx),%r10
> # 000013
> 00 20 BB 41 66 00000097: movw $0020,%r11w
> D2 BE 0F 4D 0000009C: movsbq %r10l,%r10
> D3 39 45 66 000000A0: cmpw %r10w,%r11w
> 9F 000000A4: lahf
> C7 89 41 66 000000A5: movw %ax,%r15w
> F8 89 44 66 000000A9: movw %r15w,%ax
> # 000014
> 9E 000000AD: sahf
> 00 00 00 4A 84 0F 000000AE: je 3_300$
> 18 53 B6 0F 4C 000000B4: movzbq 18(%rbx),%r10
> # 000015
> 00 2D BB 41 66 000000B9: movw $002D,%r11w
> D2 BE 0F 4D 000000BE: movsbq %r10l,%r10
> D3 39 45 66 000000C2: cmpw %r10w,%r11w
> 9F 000000C6: lahf
> C7 89 41 66 000000C7: movw %ax,%r15w
> F8 89 44 66 000000CB: movw %r15w,%ax
> # 000016
> 9E 000000CF: sahf
> 00 00 00 0A 85 0F 000000D0: jne 3_200$
> 00 00 00 8B E9 000000D6: jmpq _$$L3
> # 000016
> 00 00 00 86 E9 000000DB: jmpq _$$L3
> 3_200$:
> 30 18 6B 80 000000E0: subb $30,18(%rbx)
> # 000019
> 0A 13 6B 44 000000E4: imul $0A,(%rbx),%r10d
> # 000020
> DA 63 4D 000000E8: movslq %r10d,%r11
> 1B 89 4C 000000EB: movq %r11,(%rbx)
> 18 53 63 4C 000000EE: movslq 18(%rbx),%r10
> # 000021
> 1B 8B 4C 000000F2: movq (%rbx),%r11
> D3 01 45 000000F5: addl %r10d,%r11d
> CB 63 4D 000000F8: movslq %r11d,%r9
> 0B 89 4C 000000FB: movq %r9,(%rbx)
> 3_300$:
> 01 08 43 83 48 000000FE: addq $01,08(%rbx)
> # 000022
> 01 10 6B 83 48 00000103: subq $01,10(%rbx)
> # 000023
> 10 53 63 4C 00000108: movslq 10(%rbx),%r10
> # 000024
> 00 FA 83 41 0000010C: cmpl $00,%r10d
> 9F 00000110: lahf
> C7 89 41 66 00000111: movw %ax,%r15w
> F8 89 44 66 00000115: movw %r15w,%ax
> # 000025
> FF FE E0 81 66 00000119: andw $-0002,%ax
> 9E 0000011E: sahf
> FF FF FF 61 8F 0F 0000011F: jg 3_100$
> 20 53 63 4C 00000125: movslq 20(%rbx),%r10
> # 000026
> 13 AF 0F 44 00000129: imull (%rbx),%r10d
> DA 63 4D 0000012D: movslq %r10d,%r11
> 1B 89 4C 00000130: movq %r11,(%rbx)
> 3_400$:
> 13 63 4C 00000133: movslq (%rbx),%r10
> # 000027
> 00 00 00 88 9B 8B 4C 00000136: movq 00000088(%rbx),%r11
> 13 89 45 0000013D: movl %r10d,(%r11)
> _$$_0:
> C0 65 8D 48 00000140: leaq -40(%rbp),%rsp
> # 000028
> FE 00 00 00 F0 A3 80 00000144: andb $-02,000000F0(%rbx)
> 10 43 8F 0000014B: popq 10(%rbx)
> 18 43 8F 0000014E: popq 18(%rbx)
> 20 43 8F 00000151: popq 20(%rbx)
> 03 8B 48 00000154: movq (%rbx),%rax
> 08 53 8B 48 00000157: movq 08(%rbx),%rdx
> 5C 41 0000015B: popq %r12
> 5D 41 0000015D: popq %r13
> 5E 41 0000015F: popq %r14
> 5F 41 00000161: popq %r15
> 5B 00000163: popq %rbx
> 5D 00000164: popq %rbp
> C3 00000165: retq
> _$$L3:
> FF 20 53 6B 44 00000166: imul
> $-01,20(%rbx),%r10d #
> 000017
> DA 63 4D 0000016B: movslq %r10d,%r11
> 20 5B 89 4C 0000016E: movq %r11,20(%rbx)
> FF FF FF 87 E9 00000172: jmpq 3_300$
> # 000018
> .cfi_endproc
>
> with /OPT:
>
> .cfi_startproc
> STR_INT_VAL::
> 55 00000000: pushq %rbp
> # 000003
> E5 89 48 00000001: movq %rsp,%rbp
> 53 00000004: pushq %rbx
> 57 41 00000005: pushq %r15
> 56 41 00000007: pushq %r14
> 55 41 00000009: pushq %r13
> DC B6 0F 0000000B: movzbl %ah,%ebx
> 00 00 00 00 E8 0000000E: callq
> LIB$ALPHA_REG_VECTOR_BASE@PLT
> 93 48 00000013: xchgq %rax,%rbx
> 54 41 00000015: pushq %r12
> 00 00 00 80 BB 89 48 00000017: movq %rdi,00000080(%rbx)
> 00 00 00 88 B3 89 48 0000001E: movq %rsi,00000088(%rbx)
> 20 73 FF 00000025: pushq 20(%rbx)
> 18 73 FF 00000028: pushq 18(%rbx)
> 10 73 FF 0000002B: pushq 10(%rbx)
> 00 6A 0000002E: pushq $00
> E4 89 49 00000030: movq %rsp,%r12
> _$$L1:
> 00 00 00 80 93 63 4C 00000033: movslq
> 00000080(%rbx),%r10 #
> 000004
> 13 89 4C 0000003A: movq %r10,(%rbx)
> 13 8B 4C 0000003D: movq (%rbx),%r10
> # 000005
> 04 5A 63 4D 00000040: movslq 04(%r10),%r11
> 08 5B 89 4C 00000044: movq %r11,08(%rbx)
> 13 8B 4C 00000048: movq (%rbx),%r10
> # 000006
> 1A B7 0F 4D 0000004B: movzwq (%r10),%r11
> 10 5B 89 4C 0000004F: movq %r11,10(%rbx)
> 00 00 00 00 03 C7 48 00000053: movq $00000000,(%rbx)
> # 000007
> 10 53 63 4C 0000005A: movslq 10(%rbx),%r10
> # 000008
> 00 FA 83 41 0000005E: cmpl $00,%r10d
> 9F 00000062: lahf
> C7 89 41 66 00000063: movw %ax,%r15w
> F8 89 44 66 00000067: movw %r15w,%ax
> # 000009
> FF FE E0 81 66 0000006B: andw $-0002,%ax
> 9E 00000070: sahf
> 00 00 00 BC 8E 0F 00000071: jle 3_400$
> C0 31 48 00000077: xorq %rax,%rax
> # 000010
> 18 43 89 48 0000007A: movq %rax,18(%rbx)
> 00 00 00 01 20 43 C7 48 0000007E: movq
> $00000001,20(%rbx) #
> 000011
> 3_100$:
> 08 53 8B 4C 00000086: movq 08(%rbx),%r10
> # 000012
> 1A B6 0F 4D 0000008A: movzbq (%r10),%r11
> 18 5B 88 44 0000008E: movb %r11l,18(%rbx)
> 18 53 B6 0F 4C 00000092: movzbq 18(%rbx),%r10
> # 000013
> 00 20 BB 41 66 00000097: movw $0020,%r11w
> D2 BE 0F 4D 0000009C: movsbq %r10l,%r10
> D3 39 45 66 000000A0: cmpw %r10w,%r11w
> 9F 000000A4: lahf
> C7 89 41 66 000000A5: movw %ax,%r15w
> F8 89 44 66 000000A9: movw %r15w,%ax
> # 000014
> 9E 000000AD: sahf
> 00 00 00 4A 84 0F 000000AE: je 3_300$
> 18 53 B6 0F 4C 000000B4: movzbq 18(%rbx),%r10
> # 000015
> 00 2D BB 41 66 000000B9: movw $002D,%r11w
> D2 BE 0F 4D 000000BE: movsbq %r10l,%r10
> D3 39 45 66 000000C2: cmpw %r10w,%r11w
> 9F 000000C6: lahf
> C7 89 41 66 000000C7: movw %ax,%r15w
> F8 89 44 66 000000CB: movw %r15w,%ax
> # 000016
> 9E 000000CF: sahf
> 00 00 00 0A 85 0F 000000D0: jne 3_200$
> 00 00 00 8B E9 000000D6: jmpq _$$L3
> # 000016
> 00 00 00 86 E9 000000DB: jmpq _$$L3
> 3_200$:
> 30 18 6B 80 000000E0: subb $30,18(%rbx)
> # 000019
> 0A 13 6B 44 000000E4: imul $0A,(%rbx),%r10d
> # 000020
> DA 63 4D 000000E8: movslq %r10d,%r11
> 1B 89 4C 000000EB: movq %r11,(%rbx)
> 18 53 63 4C 000000EE: movslq 18(%rbx),%r10
> # 000021
> 1B 8B 4C 000000F2: movq (%rbx),%r11
> D3 01 45 000000F5: addl %r10d,%r11d
> CB 63 4D 000000F8: movslq %r11d,%r9
> 0B 89 4C 000000FB: movq %r9,(%rbx)
> 3_300$:
> 01 08 43 83 48 000000FE: addq $01,08(%rbx)
> # 000022
> 01 10 6B 83 48 00000103: subq $01,10(%rbx)
> # 000023
> 10 53 63 4C 00000108: movslq 10(%rbx),%r10
> # 000024
> 00 FA 83 41 0000010C: cmpl $00,%r10d
> 9F 00000110: lahf
> C7 89 41 66 00000111: movw %ax,%r15w
> F8 89 44 66 00000115: movw %r15w,%ax
> # 000025
> FF FE E0 81 66 00000119: andw $-0002,%ax
> 9E 0000011E: sahf
> FF FF FF 61 8F 0F 0000011F: jg 3_100$
> 20 53 63 4C 00000125: movslq 20(%rbx),%r10
> # 000026
> 13 AF 0F 44 00000129: imull (%rbx),%r10d
> DA 63 4D 0000012D: movslq %r10d,%r11
> 1B 89 4C 00000130: movq %r11,(%rbx)
> 3_400$:
> 13 63 4C 00000133: movslq (%rbx),%r10
> # 000027
> 00 00 00 88 9B 8B 4C 00000136: movq 00000088(%rbx),%r11
> 13 89 45 0000013D: movl %r10d,(%r11)
> _$$_0:
> C0 65 8D 48 00000140: leaq -40(%rbp),%rsp
> # 000028
> FE 00 00 00 F0 A3 80 00000144: andb $-02,000000F0(%rbx)
> 10 43 8F 0000014B: popq 10(%rbx)
> 18 43 8F 0000014E: popq 18(%rbx)
> 20 43 8F 00000151: popq 20(%rbx)
> 03 8B 48 00000154: movq (%rbx),%rax
> 08 53 8B 48 00000157: movq 08(%rbx),%rdx
> 5C 41 0000015B: popq %r12
> 5D 41 0000015D: popq %r13
> 5E 41 0000015F: popq %r14
> 5F 41 00000161: popq %r15
> 5B 00000163: popq %rbx
> 5D 00000164: popq %rbp
> C3 00000165: retq
> _$$L3:
> FF 20 53 6B 44 00000166: imul
> $-01,20(%rbx),%r10d #
> 000017
> DA 63 4D 0000016B: movslq %r10d,%r11
> 20 5B 89 4C 0000016E: movq %r11,20(%rbx)
> FF FF FF 87 E9 00000172: jmpq 3_300$
> # 000018
> .cfi_endproc
>
> Arne

In article <uciuuk$1rhnp$1@dont-email.me>,
Brian Schenkenberger <mail@SendSpamHere.ORG> wrote:
>[snip]
>I'd sure like to see VMS on X86.

It's already there! https://vmssoftware.com/

- Dan C.

On 8/28/2023 4:09 PM, Brian Schenkenberger wrote:
> On 2023-07-26 00:53:52 +0000, Arne Vajhj said:
>> On 7/25/2023 8:52 PM, Arne Vajhøj wrote:
>>> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>>>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>>>> But difficult to check the difference between /OPT and /NOOPT,
>>>>> because for some unknown reason /LIST/MACH does not list the
>>>>> generated code.
>>>>
>>>> MACRO-32 on x86?
>>>
>>> Yes.
>>>
>>>> You can always (except you compile with /NOOBJECT :-) get the
>>>> machine code listing with ANALYZE/OBJECT/DISASSEMBLE.
>>>
>>> I did not know that.
>>>
>>> But also weird.
>>>
>>> I do not see a difference between /OPT and /NOOPT at all.
>>
>> Tested with a trivial piece of code:
>>
>>          .title  str
>>          .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>>          .entry  str_int_val,^m<r2,r3,r4>

>> with /NOOPT:
>>

>>                                                  .cfi_startproc
>>                                                  STR_INT_VAL::

>> with /OPT:
>>
>>                                                  .cfi_startproc
>>                                                  STR_INT_VAL::

> I'd sure like to see VMS on X86.

I assume you are referring to the missing "-64"?

We figured it out.

:-)

Arne

On 8/28/2023 8:32 AM, Johnny Billquist wrote:
> On 2023-08-28 13:15, John Dallman wrote:
>> In article <ucgkbf$1bupe$2@dont-email.me>, arne@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?
>
> 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.
>
> 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.
>
> 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...)

Some things will break.

It is not easy to get 32 bit code executed in 64 bit mode,
because on common platforms:
- the linker/loader will not produce a 64 bit executable with
code compiled for 32 bit
- the OS will not start a 32 bit executable in 64 bit mode

But it is possible with a little creativity. Assembler
byte directives are not checked for mode.

f1.c:

#include <stdio.h>

__asm__(
"f:\n"
"_f:\n"
".byte 0xb8, 0x29, 0x00, 0x00, 0x00\n" // 32 bit mode : movl $41, %eax
// 64 bit mode : movl $41, %eax
".byte 0x40\n" // 32 bit mode : inc %eax
// 64 bit mode : (REX prefix)
".byte 0xC3\n" // 32 bit mode : ret
// 64 bit mode : ret
);

int f();

int main()
{ printf("The answer is %d\n", f());
return 0;
}

On Windows:

C:\Work\mode>del f1.exe

C:\Work\mode>gcc -m32 f1.c -o f1.exe

C:\Work\mode>f1
The answer is 42

C:\Work\mode>del f1.exe

C:\Work\mode>gcc -m64 f1.c -o f1.exe

C:\Work\mode>f1
The answer is 41

On Linux:

rm f1
gcc -m32 f1.c -o f1
../f1
The answer is 42
rm f1
gcc -m64 f1.c -o f1
../f1
The answer is 41

f2.c:

#include <stdio.h>

__asm__(
"f:\n"
"_f:\n"
".byte 0x1E\n" // 32 bit mode : push %ds
// 64 bit mode : (undefined)
".byte 0x1F\n" // 32 bit mode : pop %ds
// 64 bit mode : (undefined)
".byte 0xC3\n" // 32 bit mode : ret
// 64 bit mode : ret
);

void f();

int main()
{ printf("Start\n");
f();
printf("Finish\n");
return 0;
}

On Windows:

C:\Work\mode>del f2.exe

C:\Work\mode>gcc -m32 f2.c -o f2.exe

C:\Work\mode>f2
Start
Finish

C:\Work\mode>del f2.exe

C:\Work\mode>gcc -m64 f2.c -o f2.exe

C:\Work\mode>f2
Start

On Linux:

rm f2
gcc -m32 f2.c -o f2
../f2
Start
Finish
rm f2
gcc -m64 f2.c -o f2
../f2
Start
Illegal instruction (core dumped)

In some ways I think the first example is the worst.

But the bottom line is that while most 32 bit instructions
will work fine in 64 bit mode, then some will produce wrong results
and some will crash. It is not safe to execute 32 bit
code in 64 bit mode.

And it is a characteristics of how x86-64 is defined.

The toolchain and platform does not matter for that. How to get
assembler code into a HLL depends on the toolchain and what happens
when an invalid instruction is encountered depends on the
platform.

Which is why the toolchains don't allow mixing.

f.c:

#include <stdio.h>

void f()
{ printf("f\n");
}

m.c:

#include <stdio.h>

void f();

int main()
{ printf("main\n");
f();
return 0;
}

Windows:

C:\Work\mode>del m.exe

C:\Work\mode>gcc -c -m32 f.c -o f.obj

C:\Work\mode>gcc -m32 m.c f.obj -o m.exe

C:\Work\mode>m
main
f

C:\Work\mode>del m.exe

C:\Work\mode>gcc -c -m64 f.c -o f.obj

C:\Work\mode>gcc -m64 m.c f.obj -o m.exe

C:\Work\mode>m
main
f

C:\Work\mode>del m.exe

C:\Work\mode>gcc -c -m32 f.c -o f.obj

C:\Work\mode>gcc -m64 m.c f.obj -o m.exe
C:/GCC/13.1/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
i386 architecture of input file `f.obj' is incompatible with i386:x86-64
output
C:/GCC/13.1/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\arne\AppData\Local\Temp\ccgfmh7E.o:m.c:(.text+0x71): undefined
reference to `f'
C:/GCC/13.1/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
f.obj:f.c:(.text+0x18): undefined reference to `__imp____acrt_iob_func'
C:/GCC/13.1/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
f.obj:f.c:(.text+0x2d): undefined reference to `___mingw_vfprintf'
collect2.exe: error: ld returned 1 exit status

Linux:

rm m
gcc -c -m32 f.c -o f.o
gcc -m32 m.c f.o -o m
../m
main
f rm m
gcc -c -m64 f.c -o f.o
gcc -m64 m.c f.o -o m
../m
main
f rm m
gcc -c -m32 f.c -o f.o
gcc -m64 m.c f.o -o m
/usr/bin/ld: i386 architecture of input file `f.o' is incompatible with
i386:x86-64 output
collect2: error: ld returned 1 exit status

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.

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.

Arne

On 8/27/2023 10:11 PM, Dan Cross wrote:
> In article <ucgjus$1bupe$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/26/2023 3:09 PM, Dan Cross wrote:
>>> In article <ucdapd$ljc8$1@dont-email.me>,
>>> Arne Vajhøj <arne@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

In article <ucjb5o$1tgf7$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 8/27/2023 10:11 PM, Dan Cross wrote:
>[snip]
>>> 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.

Again, you wrote:
|DEC chose to have the VAX switch mode between 32 and
|16 bit instructions (similar to what AMD did a couple
|f decades later).
(https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/M2Ef9LyHAAAJ)

This is what I was responding to: on VAX, you had to switch to
PDP-11 compatibility mode to execute _any_ 16-bit instruction.
This is NOT true on x86. x86 does essentially what DG did.

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

I posted the reference. Here is again:
http://www.bitsavers.org/pdf/dg/mv8000/014-00648_MV8000_PrincOps_Apr80.pdf

See appendices C and D, which I quoted in
https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/arX5DixUAQAJ

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

MV couldn't either. VAX couldn't execute any. x86 is much
closer to DG in this regard, which was my original point. You
keep trying to move the goalposts by talking about other
issues, but that's just tedious.

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

Maybe if you get most of your information from Infoworld-quality
articles you find from trivial Google searches you believe that.

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

Why would I bother? I already pointed out that some
instructions behave differently and never suggested otherwise.
For example, I wrote:
|Of course, the semantics of a few instructions do change (the
|size of words on the stack changes, for example, so the `PUSH`
|instruction behaves differently in 64-bit mode), but in this
|regard, the mechanism is closer to what DG did than what DEC
|did.
(https://groups.google.com/g/comp.os.vms/c/k-wizEMeS14/m/Zx7kwqHEAAAJ)
So that part of what you wrote is objectively true, but I had
already pointed it out, so what's your point?

Where you are incorrect, and seem incapable of admitting error,
is in asserting that the x86 execution mode is exactly like the
PDP-11 compability mode on the VAX-11. It is not. It really
truly is much closer to the DG model where 32-bit and 64-bit
instructions can, with care, be intermingled in a single
instruction stream while on VAX where they cannot be so mixed
_at all_.

All of the rest of it, with linking 64-bit binaries against
32-bit libraries and so on, is a strawman; I merely asked you to
clarify your point so I could understand exactly what you were
referring to. I either got vague allusions to, "what everyone
means" or the non-answer, "yes."

- Dan C.

In article <ucj9la$1t9kd$1@dont-email.me>,
Arne Vajhøj <arne@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.

On Monday, August 28, 2023 at 4:10:00 PM UTC-4, Brian Schenkenberger wrote:
> On 2023-07-26 00:53:52 +0000, Arne Vajh j said:
>
> > On 7/25/2023 8:52 PM, Arne Vajhøj wrote:
> >> On 7/24/2023 4:38 AM, h...@end.of.inter.net wrote:
> >>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
> >>>> But difficult to check the difference between /OPT and /NOOPT,
> >>>> because for some unknown reason /LIST/MACH does not list the
> >>>> generated code.
> >>>
> >>> MACRO-32 on x86?
> >>
> >> Yes.
> >>
> >>> You can always (except you compile with /NOOBJECT :-) get the machine
> >>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
> >>
> >> I did not know that.
> >>
> >> But also weird.
> >>
> >> I do not see a difference between /OPT and /NOOPT at all.
> >
> > Tested with a trivial piece of code:
> >
> > .title str
> > .psect $CODE quad,pic,con,lcl,shr,exe,nowrt
> > .entry str_int_val,^m<r2,r3,r4>
> > movl B^4(ap),r0
> > movl B^4(r0),r1 ; address of string
> > movzwl (r0),r2 ; length of string
> > movl #0,r0 ; value=0
> > tstl r2 ; test if empty string
> > bleq 400$
> > clrl r3
> > movl #1,r4 ; scale=1
> > 100$: movb (r1),r3
> > cmpb #32,r3 ; test if " " => skip
> > beql 300$
> > cmpb #45,r3 ; test if "-" => scale=-1*scale
> > bneq 200$
> > mull2 #-1,r4
> > brb 300$
> > 200$: subb2 #48,r3 ; value=10*value+digit
> > mull2 #10,r0
> > addl2 r3,r0
> > 300$: incl r1
> > decl r2
> > tstl r2
> > bgtr 100$
> > mull2 r4,r0 ; value=value*scale
> > 400$: movl r0,@B^8(ap)
> > ret
> > .end
> >
> > with /NOOPT:
> >
> > .section $CODE, "ax",
> > "progbits" # EXE,SHR
> > .align 16
> > .cfi_startproc
> > STR_INT_VAL::
> > 55 00000000: pushq %rbp
> > # 000003
> > E5 89 48 00000001: movq %rsp,%rbp
> > 53 00000004: pushq %rbx
> > 57 41 00000005: pushq %r15
> > 56 41 00000007: pushq %r14
> > 55 41 00000009: pushq %r13
> > DC B6 0F 0000000B: movzbl %ah,%ebx
> > 00 00 00 00 E8 0000000E: callq
> > LIB$ALPHA_REG_VECTOR_BASE@PLT
> > 93 48 00000013: xchgq %rax,%rbx
> > 54 41 00000015: pushq %r12
> > 00 00 00 80 BB 89 48 00000017: movq %rdi,00000080(%rbx)
> > 00 00 00 88 B3 89 48 0000001E: movq %rsi,00000088(%rbx)
> > 20 73 FF 00000025: pushq 20(%rbx)
> > 18 73 FF 00000028: pushq 18(%rbx)
> > 10 73 FF 0000002B: pushq 10(%rbx)
> > 00 6A 0000002E: pushq $00
> > E4 89 49 00000030: movq %rsp,%r12
> > _$$L1:
> > 00 00 00 80 93 63 4C 00000033: movslq
> > 00000080(%rbx),%r10 #
> > 000004
> > 13 89 4C 0000003A: movq %r10,(%rbx)
> > 13 8B 4C 0000003D: movq (%rbx),%r10
> > # 000005
> > 04 5A 63 4D 00000040: movslq 04(%r10),%r11
> > 08 5B 89 4C 00000044: movq %r11,08(%rbx)
> > 13 8B 4C 00000048: movq (%rbx),%r10
> > # 000006
> > 1A B7 0F 4D 0000004B: movzwq (%r10),%r11
> > 10 5B 89 4C 0000004F: movq %r11,10(%rbx)
> > 00 00 00 00 03 C7 48 00000053: movq $00000000,(%rbx)
> > # 000007
> > 10 53 63 4C 0000005A: movslq 10(%rbx),%r10
> > # 000008
> > 00 FA 83 41 0000005E: cmpl $00,%r10d
> > 9F 00000062: lahf
> > C7 89 41 66 00000063: movw %ax,%r15w
> > F8 89 44 66 00000067: movw %r15w,%ax
> > # 000009
> > FF FE E0 81 66 0000006B: andw $-0002,%ax
> > 9E 00000070: sahf
> > 00 00 00 BC 8E 0F 00000071: jle 3_400$
> > C0 31 48 00000077: xorq %rax,%rax
> > # 000010
> > 18 43 89 48 0000007A: movq %rax,18(%rbx)
> > 00 00 00 01 20 43 C7 48 0000007E: movq
> > $00000001,20(%rbx) #
> > 000011
> > 3_100$:
> > 08 53 8B 4C 00000086: movq 08(%rbx),%r10
> > # 000012
> > 1A B6 0F 4D 0000008A: movzbq (%r10),%r11
> > 18 5B 88 44 0000008E: movb %r11l,18(%rbx)
> > 18 53 B6 0F 4C 00000092: movzbq 18(%rbx),%r10
> > # 000013
> > 00 20 BB 41 66 00000097: movw $0020,%r11w
> > D2 BE 0F 4D 0000009C: movsbq %r10l,%r10
> > D3 39 45 66 000000A0: cmpw %r10w,%r11w
> > 9F 000000A4: lahf
> > C7 89 41 66 000000A5: movw %ax,%r15w
> > F8 89 44 66 000000A9: movw %r15w,%ax
> > # 000014
> > 9E 000000AD: sahf
> > 00 00 00 4A 84 0F 000000AE: je 3_300$
> > 18 53 B6 0F 4C 000000B4: movzbq 18(%rbx),%r10
> > # 000015
> > 00 2D BB 41 66 000000B9: movw $002D,%r11w
> > D2 BE 0F 4D 000000BE: movsbq %r10l,%r10
> > D3 39 45 66 000000C2: cmpw %r10w,%r11w
> > 9F 000000C6: lahf
> > C7 89 41 66 000000C7: movw %ax,%r15w
> > F8 89 44 66 000000CB: movw %r15w,%ax
> > # 000016
> > 9E 000000CF: sahf
> > 00 00 00 0A 85 0F 000000D0: jne 3_200$
> > 00 00 00 8B E9 000000D6: jmpq _$$L3
> > # 000016
> > 00 00 00 86 E9 000000DB: jmpq _$$L3
> > 3_200$:
> > 30 18 6B 80 000000E0: subb $30,18(%rbx)
> > # 000019
> > 0A 13 6B 44 000000E4: imul $0A,(%rbx),%r10d
> > # 000020
> > DA 63 4D 000000E8: movslq %r10d,%r11
> > 1B 89 4C 000000EB: movq %r11,(%rbx)
> > 18 53 63 4C 000000EE: movslq 18(%rbx),%r10
> > # 000021
> > 1B 8B 4C 000000F2: movq (%rbx),%r11
> > D3 01 45 000000F5: addl %r10d,%r11d
> > CB 63 4D 000000F8: movslq %r11d,%r9
> > 0B 89 4C 000000FB: movq %r9,(%rbx)
> > 3_300$:
> > 01 08 43 83 48 000000FE: addq $01,08(%rbx)
> > # 000022
> > 01 10 6B 83 48 00000103: subq $01,10(%rbx)
> > # 000023
> > 10 53 63 4C 00000108: movslq 10(%rbx),%r10
> > # 000024
> > 00 FA 83 41 0000010C: cmpl $00,%r10d
> > 9F 00000110: lahf
> > C7 89 41 66 00000111: movw %ax,%r15w
> > F8 89 44 66 00000115: movw %r15w,%ax
> > # 000025
> > FF FE E0 81 66 00000119: andw $-0002,%ax
> > 9E 0000011E: sahf
> > FF FF FF 61 8F 0F 0000011F: jg 3_100$
> > 20 53 63 4C 00000125: movslq 20(%rbx),%r10
> > # 000026
> > 13 AF 0F 44 00000129: imull (%rbx),%r10d
> > DA 63 4D 0000012D: movslq %r10d,%r11
> > 1B 89 4C 00000130: movq %r11,(%rbx)
> > 3_400$:
> > 13 63 4C 00000133: movslq (%rbx),%r10
> > # 000027
> > 00 00 00 88 9B 8B 4C 00000136: movq 00000088(%rbx),%r11
> > 13 89 45 0000013D: movl %r10d,(%r11)
> > _$$_0:
> > C0 65 8D 48 00000140: leaq -40(%rbp),%rsp
> > # 000028
> > FE 00 00 00 F0 A3 80 00000144: andb $-02,000000F0(%rbx)
> > 10 43 8F 0000014B: popq 10(%rbx)
> > 18 43 8F 0000014E: popq 18(%rbx)
> > 20 43 8F 00000151: popq 20(%rbx)
> > 03 8B 48 00000154: movq (%rbx),%rax
> > 08 53 8B 48 00000157: movq 08(%rbx),%rdx
> > 5C 41 0000015B: popq %r12
> > 5D 41 0000015D: popq %r13
> > 5E 41 0000015F: popq %r14
> > 5F 41 00000161: popq %r15
> > 5B 00000163: popq %rbx
> > 5D 00000164: popq %rbp
> > C3 00000165: retq
> > _$$L3:
> > FF 20 53 6B 44 00000166: imul
> > $-01,20(%rbx),%r10d #
> > 000017
> > DA 63 4D 0000016B: movslq %r10d,%r11
> > 20 5B 89 4C 0000016E: movq %r11,20(%rbx)
> > FF FF FF 87 E9 00000172: jmpq 3_300$
> > # 000018
> > .cfi_endproc
> >
> > with /OPT:
> >
> > .cfi_startproc
> > STR_INT_VAL::
> > 55 00000000: pushq %rbp
> > # 000003
> > E5 89 48 00000001: movq %rsp,%rbp
> > 53 00000004: pushq %rbx
> > 57 41 00000005: pushq %r15
> > 56 41 00000007: pushq %r14
> > 55 41 00000009: pushq %r13
> > DC B6 0F 0000000B: movzbl %ah,%ebx
> > 00 00 00 00 E8 0000000E: callq
> > LIB$ALPHA_REG_VECTOR_BASE@PLT
> > 93 48 00000013: xchgq %rax,%rbx
> > 54 41 00000015: pushq %r12
> > 00 00 00 80 BB 89 48 00000017: movq %rdi,00000080(%rbx)
> > 00 00 00 88 B3 89 48 0000001E: movq %rsi,00000088(%rbx)
> > 20 73 FF 00000025: pushq 20(%rbx)
> > 18 73 FF 00000028: pushq 18(%rbx)
> > 10 73 FF 0000002B: pushq 10(%rbx)
> > 00 6A 0000002E: pushq $00
> > E4 89 49 00000030: movq %rsp,%r12
> > _$$L1:
> > 00 00 00 80 93 63 4C 00000033: movslq
> > 00000080(%rbx),%r10 #
> > 000004
> > 13 89 4C 0000003A: movq %r10,(%rbx)
> > 13 8B 4C 0000003D: movq (%rbx),%r10
> > # 000005
> > 04 5A 63 4D 00000040: movslq 04(%r10),%r11
> > 08 5B 89 4C 00000044: movq %r11,08(%rbx)
> > 13 8B 4C 00000048: movq (%rbx),%r10
> > # 000006
> > 1A B7 0F 4D 0000004B: movzwq (%r10),%r11
> > 10 5B 89 4C 0000004F: movq %r11,10(%rbx)
> > 00 00 00 00 03 C7 48 00000053: movq $00000000,(%rbx)
> > # 000007
> > 10 53 63 4C 0000005A: movslq 10(%rbx),%r10
> > # 000008
> > 00 FA 83 41 0000005E: cmpl $00,%r10d
> > 9F 00000062: lahf
> > C7 89 41 66 00000063: movw %ax,%r15w
> > F8 89 44 66 00000067: movw %r15w,%ax
> > # 000009
> > FF FE E0 81 66 0000006B: andw $-0002,%ax
> > 9E 00000070: sahf
> > 00 00 00 BC 8E 0F 00000071: jle 3_400$
> > C0 31 48 00000077: xorq %rax,%rax
> > # 000010
> > 18 43 89 48 0000007A: movq %rax,18(%rbx)
> > 00 00 00 01 20 43 C7 48 0000007E: movq
> > $00000001,20(%rbx) #
> > 000011
> > 3_100$:
> > 08 53 8B 4C 00000086: movq 08(%rbx),%r10
> > # 000012
> > 1A B6 0F 4D 0000008A: movzbq (%r10),%r11
> > 18 5B 88 44 0000008E: movb %r11l,18(%rbx)
> > 18 53 B6 0F 4C 00000092: movzbq 18(%rbx),%r10
> > # 000013
> > 00 20 BB 41 66 00000097: movw $0020,%r11w
> > D2 BE 0F 4D 0000009C: movsbq %r10l,%r10
> > D3 39 45 66 000000A0: cmpw %r10w,%r11w
> > 9F 000000A4: lahf
> > C7 89 41 66 000000A5: movw %ax,%r15w
> > F8 89 44 66 000000A9: movw %r15w,%ax
> > # 000014
> > 9E 000000AD: sahf
> > 00 00 00 4A 84 0F 000000AE: je 3_300$
> > 18 53 B6 0F 4C 000000B4: movzbq 18(%rbx),%r10
> > # 000015
> > 00 2D BB 41 66 000000B9: movw $002D,%r11w
> > D2 BE 0F 4D 000000BE: movsbq %r10l,%r10
> > D3 39 45 66 000000C2: cmpw %r10w,%r11w
> > 9F 000000C6: lahf
> > C7 89 41 66 000000C7: movw %ax,%r15w
> > F8 89 44 66 000000CB: movw %r15w,%ax
> > # 000016
> > 9E 000000CF: sahf
> > 00 00 00 0A 85 0F 000000D0: jne 3_200$
> > 00 00 00 8B E9 000000D6: jmpq _$$L3
> > # 000016
> > 00 00 00 86 E9 000000DB: jmpq _$$L3
> > 3_200$:
> > 30 18 6B 80 000000E0: subb $30,18(%rbx)
> > # 000019
> > 0A 13 6B 44 000000E4: imul $0A,(%rbx),%r10d
> > # 000020
> > DA 63 4D 000000E8: movslq %r10d,%r11
> > 1B 89 4C 000000EB: movq %r11,(%rbx)
> > 18 53 63 4C 000000EE: movslq 18(%rbx),%r10
> > # 000021
> > 1B 8B 4C 000000F2: movq (%rbx),%r11
> > D3 01 45 000000F5: addl %r10d,%r11d
> > CB 63 4D 000000F8: movslq %r11d,%r9
> > 0B 89 4C 000000FB: movq %r9,(%rbx)
> > 3_300$:
> > 01 08 43 83 48 000000FE: addq $01,08(%rbx)
> > # 000022
> > 01 10 6B 83 48 00000103: subq $01,10(%rbx)
> > # 000023
> > 10 53 63 4C 00000108: movslq 10(%rbx),%r10
> > # 000024
> > 00 FA 83 41 0000010C: cmpl $00,%r10d
> > 9F 00000110: lahf
> > C7 89 41 66 00000111: movw %ax,%r15w
> > F8 89 44 66 00000115: movw %r15w,%ax
> > # 000025
> > FF FE E0 81 66 00000119: andw $-0002,%ax
> > 9E 0000011E: sahf
> > FF FF FF 61 8F 0F 0000011F: jg 3_100$
> > 20 53 63 4C 00000125: movslq 20(%rbx),%r10
> > # 000026
> > 13 AF 0F 44 00000129: imull (%rbx),%r10d
> > DA 63 4D 0000012D: movslq %r10d,%r11
> > 1B 89 4C 00000130: movq %r11,(%rbx)
> > 3_400$:
> > 13 63 4C 00000133: movslq (%rbx),%r10
> > # 000027
> > 00 00 00 88 9B 8B 4C 00000136: movq 00000088(%rbx),%r11
> > 13 89 45 0000013D: movl %r10d,(%r11)
> > _$$_0:
> > C0 65 8D 48 00000140: leaq -40(%rbp),%rsp
> > # 000028
> > FE 00 00 00 F0 A3 80 00000144: andb $-02,000000F0(%rbx)
> > 10 43 8F 0000014B: popq 10(%rbx)
> > 18 43 8F 0000014E: popq 18(%rbx)
> > 20 43 8F 00000151: popq 20(%rbx)
> > 03 8B 48 00000154: movq (%rbx),%rax
> > 08 53 8B 48 00000157: movq 08(%rbx),%rdx
> > 5C 41 0000015B: popq %r12
> > 5D 41 0000015D: popq %r13
> > 5E 41 0000015F: popq %r14
> > 5F 41 00000161: popq %r15
> > 5B 00000163: popq %rbx
> > 5D 00000164: popq %rbp
> > C3 00000165: retq
> > _$$L3:
> > FF 20 53 6B 44 00000166: imul
> > $-01,20(%rbx),%r10d #
> > 000017
> > DA 63 4D 0000016B: movslq %r10d,%r11
> > 20 5B 89 4C 0000016E: movq %r11,20(%rbx)
> > FF FF FF 87 E9 00000172: jmpq 3_300$
> > # 000018
> > .cfi_endproc
> >
> > Arne
>
> I'd sure like to see VMS on X86.

In article <45fd1f30-55fb-4691-a561-e5941143a6fcn@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>[big snip]
>Macro doesn't use the LLVM optimizer (it doesn't use the GEM one either). All the
>branching between routines doesn't fit the high-level model.
>
>Macro does a limited job of pulling address computations out of loops if there are
>free registers (and on x86, the answer is "almost never").
>
>With GEM, AMACRO/IMACRO gets the benefit of GEM's instruction level peephole
>optimizer. That doesn't exist in that form for LLVM. So XMACRO today has several
>"branches to branches" and is sloppy with x86 condition codes. However, we think
>the microarchitecture and predictive execution takes care of those branches to branches
>and the like.
>
>In general Macro-32 code is optimized by the human while typing it in.

This begs a question: how useful are those optimizations? I
imagine many are based on an execution environment that is not
the actual target anymore; is it possible that something that
was a clear win on VAX is a pessimization as implemented on
x86?

- Dan C.

On 2023-08-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/24/2023 6:08 AM, Johnny Billquist wrote:
>> On 2023-08-23 14:35, Simon Clubley wrote:
>>> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> VAX + VMS                               Eclipse MV + AOS/VS
>>>> ---------                               -------------------
> ...
>>>> kernel in Macro-32 or Bliss             kernel in assembler
>>>> utilities in Macro-32 or Bliss or HLL   utilities in Algol dialect
>>>
>>> Based purely on what you write above, the use of an Algol dialect for
>>> writing their userland code is a _massive_ win over the DEC approach
>>> and _far_ superior to the way DEC did things.
>>>
>>> Wish DEC had done the same.
>>
>> I think when it came to utilities, very little was in Macro-32, and most
>> were in Bliss or some other HLL. Can't say that I'd consider everything
>> written in some Algol dialect to be a massive win over that.
>
> Isn't DCL or at least large parts of in Macro-32?
>

Yes.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-08-28, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <uciuuk$1rhnp$1@dont-email.me>,
> Brian Schenkenberger <mail@SendSpamHere.ORG> wrote:
>>[snip]
>>I'd sure like to see VMS on X86.
>
> It's already there! https://vmssoftware.com/
>

Brian knows who they are and many of the engineers there know
exactly who he is as well. :-)

I think Brian is referring to being unable to send a request
via the website for the VSI community access for some reason.

He also complained he didn't receive any replies to questions
sent via the contact form. Given the history of problems he has
had in this area, I wonder if his mail system is dropping the
replies as spam.

Brian, have you considered registering for the VSI forums and
raising the problems you are experiencing there ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.