On 2023-08-28 16:59, Dan Cross wrote:
> 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.

Which is equally true for the PDP-11 mode bit on the VAX. ;-)
User programs just run. The OS is handling all the details on how to
actually get the machine in the correct state.

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

Oh, I agree that we're splitting hairs. But I do think DG went a bit
further than AMD did, with the goal of being able to basically just move
the binaries over and run them. Hence the two stacks, and all that ugliness.
Yes, the OS might still need to set some things up, but I don't think
it's completely comparable what DG did with what AMD did, just as it
isn't the same as what DEC did.

And with all that said, I do think DG made a bad choice. AMD basically
did a good choice (or better, at least - anything involving the x86 is
inherently bad... ;-) ).

No need to comment on the rest you wrote. I'm not disagreeing.

Johnny

On Monday, August 28, 2023 at 9:26:19 PM UTC-4, Dan Cross wrote:
> In article <45fd1f30-55fb-4691...@googlegroups.com>,
> John Reagan <xyzz...@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.
I was mostly talking about doing things like common sub-expression (computing a value
once outside of a loop), doing clever shifts vs divide, etc. For knowing that some VAX
instructions are "faster" than other VAX instructions stopped being useful when moving
to Alpha. For instance, no integer divide on Alpha; no actual divide on Itanium; but both
kinds of divide on x86.

On 2023-08-29, Johnny Billquist <bqt@softjar.se> wrote:
>
> Oh, I agree that we're splitting hairs. But I do think DG went a bit
> further than AMD did, with the goal of being able to basically just move
> the binaries over and run them. Hence the two stacks, and all that ugliness.
> Yes, the OS might still need to set some things up, but I don't think
> it's completely comparable what DG did with what AMD did, just as it
> isn't the same as what DEC did.
>
> And with all that said, I do think DG made a bad choice. AMD basically
> did a good choice (or better, at least - anything involving the x86 is
> inherently bad... ;-) ).
>

And none of that compares to the extreme compatibility that IBM maintains
with its mainframe architecture. It's reported that you can _still_ run
S/360 application programs unchanged on modern mainframes...

Simon.

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

In article <uckthl$2m8$3@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-08-28 16:59, Dan Cross wrote:
>> In article <uci441$lgj$2@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>>[snip]
>>> 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.
>
>Which is equally true for the PDP-11 mode bit on the VAX. ;-)

This is true.

>User programs just run. The OS is handling all the details on how to
>actually get the machine in the correct state.

This is also true, though I don't see any reason that the OS
couldn't set up 32-bit segments in addition to 64-bit segs and
let a user process jump between them, shifting some of the
burden to the application, if it wanted it. It'd be sort of a
silly exercise, though I doubt there's a technical limitation
there.

>> 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.
>
>Oh, I agree that we're splitting hairs. But I do think DG went a bit
>further than AMD did, with the goal of being able to basically just move
>the binaries over and run them. Hence the two stacks, and all that ugliness.
>Yes, the OS might still need to set some things up, but I don't think
>it's completely comparable what DG did with what AMD did, just as it
>isn't the same as what DEC did.

I agree with this. Certainly, what AMD did was not _exactly_
like what DG did, just as it wasn't exactly like what DEC did.
I just think that the AMD mechanism is more like DG in the sense
of allowing a 64-bit program to execute 32-bit instructions
without a mode switch.

>And with all that said, I do think DG made a bad choice. AMD basically
>did a good choice (or better, at least - anything involving the x86 is
>inherently bad... ;-) ).

Agreed.

AMD had the benefit of a few decades after both VAX and DG, and
likely the insight of engineers familiar with both. They chose
a middle path that, IMHO, is a good combination of both.

I also agree that x86 is a dumpster fire of bad design
encumbered by legacy otherwise.

- Dan C.

In article <1265c2b4-565b-4f6f-ab73-bac58ddbfde4n@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>On Monday, August 28, 2023 at 9:26:19 PM UTC-4, Dan Cross wrote:
>> In article <45fd1f30-55fb-4691...@googlegroups.com>,
>> John Reagan <xyzz...@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?
>
>I was mostly talking about doing things like common sub-expression (computing a value
>once outside of a loop), doing clever shifts vs divide, etc. For knowing that some VAX
>instructions are "faster" than other VAX instructions stopped being useful when moving
>to Alpha. For instance, no integer divide on Alpha; no actual divide on Itanium; but both
>kinds of divide on x86.

That makes sense; thanks!

- Dan C.

On 8/29/2023 1:33 PM, Simon Clubley wrote:
> On 2023-08-29, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> Oh, I agree that we're splitting hairs. But I do think DG went a bit
>> further than AMD did, with the goal of being able to basically just move
>> the binaries over and run them. Hence the two stacks, and all that ugliness.
>> Yes, the OS might still need to set some things up, but I don't think
>> it's completely comparable what DG did with what AMD did, just as it
>> isn't the same as what DEC did.
>>
>> And with all that said, I do think DG made a bad choice. AMD basically
>> did a good choice (or better, at least - anything involving the x86 is
>> inherently bad... ;-) ).
>>
>
> And none of that compares to the extreme compatibility that IBM maintains
> with its mainframe architecture. It's reported that you can _still_ run
> S/360 application programs unchanged on modern mainframes...
>
> Simon.
>

I'm not positive as it has been a long time since I was really active
in that world but I think the same is true of Unisys and old 1100 code.

bill

On 8/29/2023 11:19 AM, John Reagan wrote:
> On Monday, August 28, 2023 at 9:26:19 PM UTC-4, Dan Cross wrote:
>> In article <45fd1f30-55fb-4691...@googlegroups.com>,
>> John Reagan <xyzz...@gmail.com> wrote:
>>> 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?
>>
> I was mostly talking about doing things like common sub-expression (computing a value
> once outside of a loop), doing clever shifts vs divide, etc. For knowing that some VAX
> instructions are "faster" than other VAX instructions stopped being useful when moving
> to Alpha. For instance, no integer divide on Alpha; no actual divide on Itanium; but both
> kinds of divide on x86.

I think of it like:
* the Macro-32 code ran acceptable fast on a VAX 780
* I don't believe the unoptimized Macro-32
on Alpha/Itanium/x86-64 could be improved more than x5
* newer systems are at least x1000 faster than a VAX 780
so the absolutely worst case scenario is that the unoptimized
Macro-32 is only x200 faster than on a VAX 780.

I guess we can live with that. :-)

Arne

On 8/29/2023 8:04 PM, Arne Vajhøj wrote:
> On 8/29/2023 11:19 AM, John Reagan wrote:
>> On Monday, August 28, 2023 at 9:26:19 PM UTC-4, Dan Cross wrote:
>>> In article <45fd1f30-55fb-4691...@googlegroups.com>,
>>> John Reagan <xyzz...@gmail.com> wrote:
>>>> 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?
>>>
>> I was mostly talking about doing things like common sub-expression (computing
>> a value
>> once outside of a loop), doing clever shifts vs divide, etc. For knowing that
>> some VAX
>> instructions are "faster" than other VAX instructions stopped being useful
>> when moving
>> to Alpha. For instance, no integer divide on Alpha; no actual divide on
>> Itanium; but both
>> kinds of divide on x86.
>
>
> I think of it like:
> * the Macro-32 code ran acceptable fast on a VAX 780
> * I don't believe the unoptimized Macro-32
> on Alpha/Itanium/x86-64 could be improved more than x5
> * newer systems are at least x1000 faster than a VAX 780
> so the absolutely worst case scenario is that the unoptimized
> Macro-32 is only x200 faster than on a VAX 780.
>
> I guess we can live with that. :-)
>
> Arne
>
>

Understand, I'm not knocking CPU performance. It is important. But, it's not
everything. Some applications can be I/O bound, and, while caching can make
huge differences there, the app is still about I/O. At such a time, is all this
fuss about the efficiency of Macro-32 meaningful?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Monday, August 28, 2023 at 8:32:05 AM UTC-4, 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?

Sure:

(0:283) 165h:~terry% cat test.c
#include <stdio.h>
int main() {
printf("Hello, cruel world...\n");
return 0;
} (0:284) 165h:~terry% cc -o test test.c
(0:285) 165h:~terry% file test
test: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked,
interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2 (1302507), FreeBSD-style, with
debug_info, not stripped
(0:286) 165h:~terry% ./test
Hello, cruel world...
(0:287) 165h:~terry% cc -o test -m32 -DCOMPAT_32BIT -L/usr/lib32 -B/usr/lib32 test.c
(0:288) 165h:~terry% file test
test: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked,
interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2 (1302507), FreeBSD-style, with
debug_info, not stripped
(0:289) 165h:~terry% ./test
Hello, cruel world...

Yes, it also works for programs compiled before there was a 64-bit architecture:

(0:2) 165h:~/foo/stand% file sh
sh: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked,
for FreeBSD 5.3, stripped
(0:3) 165h:~/foo/stand% ./sh
$

I have some 100K+ LoC monstrosities that are not 32-bit clean that I
still compile and run in 32-bit mode.

True, this is under an operating system and the OS relies on ELF Notes
in the executable to set up the appropriate 32-bit runtime. But since no
current x86 processor starts up in 64-bit mode (you have to set things
up and get there first) that seems fair.

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

There was very little new stuff being written in DG assembler by that
point - DG had switched to DG/L for operating system implementation
and all that were left were (presumably) some small routines to do stuff
that couldn't be implemented in DG/L. At least that's what I heard from
inside DG - RDOS and XBASIC didn't go in for any of that new-fangled
HLL stuff. 8-}

By the time DEC got to IA-64 (many years later, of course) pretty much
the same was true for them - they just 'cheated' and made Macro-32
a compiler.

One extremely popular platform these days, Espressif's ESP-32, doesn't
even have a publicly-documented assembly language.

On 2023-08-30 10:35, terry-...@glaver.org wrote:
> On Monday, August 28, 2023 at 8:32:05 AM UTC-4, 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?
>
> Sure:

[...]

Well. Unfortunately, that don't prove a thing. As the OS knows what kind
of binary it is going to execute, it can set things up in all kind of
ways for you.

Basically, if we imagine that we had an old VAX, with PDP-11
compatibility, and we built the program for either machine, and the OS
had the understanding, your example would work just fine there too.
And we know that the VAX have a compatibility bit for the PDP-11 mode.

But I think we already probed this enough. :-)

Johnny