Just listening to John Reagan talk about the hoops VSI needed to jump through when porting compilers to x86-64. Very cool stuff but way more complicated than I could have ever imagined.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net

On Tuesday, 27 April 2021 at 10:26:03 UTC-4, Neil Rieck wrote:
> Just listening to John Reagan talk about the hoops VSI needed to jump through when porting compilers to x86-64. Very cool stuff but way more complicated than I could have ever imagined.
>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net

True, but its nice to hear that previous work on other platforms has been useable here. Think of the time it would have taken to get this far had Alpha and Itanium work not applied at all.

Dan

On 4/27/2021 10:26 AM, Neil Rieck wrote:
> Just listening to John Reagan talk about the hoops VSI needed to jump
> through when porting compilers to x86-64. Very cool stuff but way
> more complicated than I could have ever imagined.

Allowing old VMS code to still build and support new
standard stuff has its challenges.

Arne

On Tuesday, April 27, 2021 at 10:36:43 AM UTC-4, abrsvc wrote:
> On Tuesday, 27 April 2021 at 10:26:03 UTC-4, Neil Rieck wrote:
> > Just listening to John Reagan talk about the hoops VSI needed to jump through when porting compilers to x86-64. Very cool stuff but way more complicated than I could have ever imagined.
> >
> > Neil Rieck
> > Waterloo, Ontario, Canada.
> > http://neilrieck.net
> True, but its nice to hear that previous work on other platforms has been useable here. Think of the time it would have taken to get this far had Alpha and Itanium work not applied at all.
>
> Dan

Yep, I recall talking to people who worked on porting everything to Itanium with comments like "I don't think anyone has put a second set of eyes on this code since the port from VAX to Alpha".

Neil

On Tuesday, April 27, 2021 at 10:44:11 AM UTC-4, Arne Vajhøj wrote:
> On 4/27/2021 10:26 AM, Neil Rieck wrote:
> > Just listening to John Reagan talk about the hoops VSI needed to jump
> > through when porting compilers to x86-64. Very cool stuff but way
> > more complicated than I could have ever imagined.
> Allowing old VMS code to still build and support new
> standard stuff has its challenges.
>
> Arne

As always, 32-bit code vs 64-bit code always seems an issue

Neil

John mentioned some of his videos on youtube. Here is one of a bunch:

https://www.youtube.com/watch?v=xTaBkCBYskA

Neil

In article <3914400e-a708-48fd-b8de-cdd4877f97ean@googlegroups.com>,
Neil Rieck <n.rieck@sympatico.ca> writes:

> Just listening to John Reagan talk about the hoops VSI needed to jump
> through when porting compilers to x86-64. Very cool stuff but way more
> complicated than I could have ever imagined.

Even most technical people, dare I say even most compiler writers, don't
even know about the problems, much less the solutions.

On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
> On 4/27/2021 10:26 AM, Neil Rieck wrote:
>> Just listening to John Reagan talk about the hoops VSI needed to jump
>> through when porting compilers to x86-64. Very cool stuff but way
>> more complicated than I could have ever imagined.
>
> Allowing old VMS code to still build and support new
> standard stuff has its challenges.
>
> Arne

I don't think that is the real issue.

Languages have well defined instructions. It is the job of a compiler
to implement the defined instructions. Now, how it does that can vary
widely between different systems. But the apps, which use the
instructions, should be able to count on the same results. Otherwise,
the definitions in the language would have changed.

So the challenge is to insure the language does the same thing on
different systems.

--
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 2021-04-27 16:57:48 +0000, Dave Froble said:

> On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
>> On 4/27/2021 10:26 AM, Neil Rieck wrote:
>>> Just listening to John Reagan talk about the hoops VSI needed to jump
>>> through when porting compilers to x86-64. Very cool stuff but way more
>>> complicated than I could have ever imagined.
>>
>> Allowing old VMS code to still build and support new standard stuff has
>> its challenges.
>>
>> Arne
>
> I don't think that is the real issue.

Yeah, it's the issue. Compatibility is often a compromise, and usually
one of various trade-offs, and compatibility accrues complexity over
time.

> Languages have well defined instructions. It is the job of a compiler
> to implement the defined instructions. Now, how it does that can vary
> widely between different systems. But the apps, which use the
> instructions, should be able to count on the same results. Otherwise,
> the definitions in the language would have changed.

It's the APIs and ABIs that are the difficulty. Not the hardware instructions.

> So the challenge is to insure the language does the same thing on
> different systems.

And that right there is the source of the compromises.

Vendors need enough compatibility to keep users from porting their apps
elsewhere, but also enough room for changes to ensure that the platform
can remain viable and secure over time.

The existing 32- and 64-bit morass within OpenVMS will only get more
complex, and more entrenched.

--
Pure Personal Opinion | HoffmanLabs LLC

On 4/27/2021 12:57 PM, Dave Froble wrote:
> On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
>> On 4/27/2021 10:26 AM, Neil Rieck wrote:
>>> Just listening to John Reagan talk about the hoops VSI needed to jump
>>> through when porting compilers to x86-64. Very cool stuff but way
>>> more complicated than I could have ever imagined.
>>
>> Allowing old VMS code to still build and support new
>> standard stuff has its challenges.
>
> I don't think that is the real issue.
>
> Languages have well defined instructions.  It is the job of a compiler
> to implement the defined instructions.  Now, how it does that can vary
> widely between different systems.  But the apps, which use the
> instructions, should be able to count on the same results.  Otherwise,
> the definitions in the language would have changed.
>
> So the challenge is to insure the language does the same thing on
> different systems.

I think it would be a lot easier for VSI if they just had
to implement ANSI/ISO and no extensions and not paying
any attention to maintain implementation specific features.

But that would break a lot of application. Probably
most applications as those in strict ANSI/ISO with
no extensions probably moved off VMS years ago.

Obviously this argument does not really apply to Basic or
Macro-32 due to lack of ANSI/ISO standard.

Arne

On 4/27/21 2:35 PM, Arne Vajhøj wrote:
> On 4/27/2021 12:57 PM, Dave Froble wrote:
>> On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
>>> On 4/27/2021 10:26 AM, Neil Rieck wrote:
>>>> Just listening to John Reagan talk about the hoops VSI needed to jump
>>>> through when porting compilers to x86-64. Very cool stuff but way
>>>> more complicated than I could have ever imagined.
>>>
>>> Allowing old VMS code to still build and support new
>>> standard stuff has its challenges.
>>
>> I don't think that is the real issue.
>>
>> Languages have well defined instructions.  It is the job of a compiler
>> to implement the defined instructions.  Now, how it does that can vary
>> widely between different systems.  But the apps, which use the
>> instructions, should be able to count on the same results.  Otherwise,
>> the definitions in the language would have changed.
>>
>> So the challenge is to insure the language does the same thing on
>> different systems.
>
> I think it would be a lot easier for VSI if they just had
> to implement ANSI/ISO and no extensions and not paying
> any attention to maintain implementation specific features.
>
> But that would break a lot of application. Probably
> most applications as those in strict ANSI/ISO with
> no extensions probably moved off VMS years ago.
>
> Obviously this argument does not really apply to Basic or
> Macro-32 due to lack of ANSI/ISO standard.
>

There was an ANSI BASIC. Was it rescinded?

bill

On 27/04/2021 19:35, Arne Vajhøj wrote:

> Obviously this argument does not really apply to Basic or
> Macro-32 due to lack of ANSI/ISO standard.
>
> Arne
>
>
>
I thought there were a few ANSI standards for BASIC. I even has one on
my Atari ST!

Chris

In article <s69lh3$thc$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> I think it would be a lot easier for VSI if they just had
> to implement ANSI/ISO and no extensions and not paying
> any attention to maintain implementation specific features.

My guess is that supporting extensions is just a bit of icing on a much
more difficult cake.

On 4/27/2021 2:46 PM, Bill Gunshannon wrote:
> On 4/27/21 2:35 PM, Arne Vajhøj wrote:
>> On 4/27/2021 12:57 PM, Dave Froble wrote:
>>> On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
>>>> On 4/27/2021 10:26 AM, Neil Rieck wrote:
>>>>> Just listening to John Reagan talk about the hoops VSI needed to jump
>>>>> through when porting compilers to x86-64. Very cool stuff but way
>>>>> more complicated than I could have ever imagined.
>>>>
>>>> Allowing old VMS code to still build and support new
>>>> standard stuff has its challenges.
>>>
>>> I don't think that is the real issue.
>>>
>>> Languages have well defined instructions.  It is the job of a
>>> compiler to implement the defined instructions.  Now, how it does
>>> that can vary widely between different systems.  But the apps, which
>>> use the instructions, should be able to count on the same results.
>>> Otherwise, the definitions in the language would have changed.
>>>
>>> So the challenge is to insure the language does the same thing on
>>> different systems.
>>
>> I think it would be a lot easier for VSI if they just had
>> to implement ANSI/ISO and no extensions and not paying
>> any attention to maintain implementation specific features.
>>
>> But that would break a lot of application. Probably
>> most applications as those in strict ANSI/ISO with
>> no extensions probably moved off VMS years ago.
>>
>> Obviously this argument does not really apply to Basic or
>> Macro-32 due to lack of ANSI/ISO standard.
>
> There was an ANSI BASIC.  Was it rescinded?

You are right - there was.

A bit of research found Minimal Basic in ANSI X3.60 /
ISO 6373 and Full Basic in ANSI X3.113 / ISO 10279 / ECMA-116.

Guess that shows how little I know about Basic.

Arne

On 4/27/2021 2:47 PM, Chris Townley wrote:
> On 27/04/2021 19:35, Arne Vajhøj wrote:
>> Obviously this argument does not really apply to Basic or
>> Macro-32 due to lack of ANSI/ISO standard.

> I thought there were a few ANSI standards for BASIC. I even has one on
> my Atari ST!

Yes.

I was wrong.

Arne

In article <s69n5v$1ne3$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> > There was an ANSI BASIC.  Was it rescinded?
>
> You are right - there was.
>
> A bit of research found Minimal Basic in ANSI X3.60 /
> ISO 6373 and Full Basic in ANSI X3.113 / ISO 10279 / ECMA-116.
>
> Guess that shows how little I know about Basic.

I guess you should have at least some basic knowledge of it. :-)

On Tuesday, April 27, 2021 at 2:46:53 PM UTC-4, Bill Gunshannon wrote:
> On 4/27/21 2:35 PM, Arne Vajhøj wrote:
> > On 4/27/2021 12:57 PM, Dave Froble wrote:
> >> On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
> >>> On 4/27/2021 10:26 AM, Neil Rieck wrote:
> >>>> Just listening to John Reagan talk about the hoops VSI needed to jump
> >>>> through when porting compilers to x86-64. Very cool stuff but way
> >>>> more complicated than I could have ever imagined.
> >>>
> >>> Allowing old VMS code to still build and support new
> >>> standard stuff has its challenges.
> >>
> >> I don't think that is the real issue.
> >>
> >> Languages have well defined instructions. It is the job of a compiler
> >> to implement the defined instructions. Now, how it does that can vary
> >> widely between different systems. But the apps, which use the
> >> instructions, should be able to count on the same results. Otherwise,
> >> the definitions in the language would have changed.
> >>
> >> So the challenge is to insure the language does the same thing on
> >> different systems.
> >
> > I think it would be a lot easier for VSI if they just had
> > to implement ANSI/ISO and no extensions and not paying
> > any attention to maintain implementation specific features.
> >
> > But that would break a lot of application. Probably
> > most applications as those in strict ANSI/ISO with
> > no extensions probably moved off VMS years ago.
> >
> > Obviously this argument does not really apply to Basic or
> > Macro-32 due to lack of ANSI/ISO standard.
> >
> There was an ANSI BASIC. Was it rescinded?
>
> bill
No, but nobody really cared. No Digital BASIC product did.

On Tuesday, April 27, 2021 at 2:35:19 PM UTC-4, Arne Vajhøj wrote:
> On 4/27/2021 12:57 PM, Dave Froble wrote:
> > On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
> >> On 4/27/2021 10:26 AM, Neil Rieck wrote:
> >>> Just listening to John Reagan talk about the hoops VSI needed to jump
> >>> through when porting compilers to x86-64. Very cool stuff but way
> >>> more complicated than I could have ever imagined.
> >>
> >> Allowing old VMS code to still build and support new
> >> standard stuff has its challenges.
> >
> > I don't think that is the real issue.
> >
> > Languages have well defined instructions. It is the job of a compiler
> > to implement the defined instructions. Now, how it does that can vary
> > widely between different systems. But the apps, which use the
> > instructions, should be able to count on the same results. Otherwise,
> > the definitions in the language would have changed.
> >
> > So the challenge is to insure the language does the same thing on
> > different systems.
> I think it would be a lot easier for VSI if they just had
> to implement ANSI/ISO and no extensions and not paying
> any attention to maintain implementation specific features.
>
> But that would break a lot of application. Probably
> most applications as those in strict ANSI/ISO with
> no extensions probably moved off VMS years ago.

Fortran without %IMMED or %DESCR gets really awkward to use on
OpenVMS. For C, the OS's choice to be dual-pointer size pushed all the
compilers in that direction. And the real non-standard stuff is all in the
CRTL having to deal with all the RMS stuff.

Since we already had those frontends in place, there was little effort to keep
all of that ancient stuff. Makes a good "recompile and go" story. It is the C++
that already jumped from Alpha to Itanium and now to x86 with different
frontends on each platform.

And even gcc and clang on Linux have various options to allow older code
variants. We're not alone in enabling tree-huggers.

>
> Obviously this argument does not really apply to Basic or
> Macro-32 due to lack of ANSI/ISO standard.
>
> Arne

On Tuesday, April 27, 2021 at 5:35:31 PM UTC-4, John Reagan wrote:
> On Tuesday, April 27, 2021 at 2:35:19 PM UTC-4, Arne Vajhøj wrote:
> > On 4/27/2021 12:57 PM, Dave Froble wrote:
> > > On 4/27/2021 10:44 AM, Arne Vajhøj wrote:
> > >> On 4/27/2021 10:26 AM, Neil Rieck wrote:
> > >>> Just listening to John Reagan talk about the hoops VSI needed to jump
> > >>> through when porting compilers to x86-64. Very cool stuff but way
> > >>> more complicated than I could have ever imagined.
> > >>
> > >> Allowing old VMS code to still build and support new
> > >> standard stuff has its challenges.
> > >
> > > I don't think that is the real issue.
> > >
> > > Languages have well defined instructions. It is the job of a compiler
> > > to implement the defined instructions. Now, how it does that can vary
> > > widely between different systems. But the apps, which use the
> > > instructions, should be able to count on the same results. Otherwise,
> > > the definitions in the language would have changed.
> > >
> > > So the challenge is to insure the language does the same thing on
> > > different systems.
> > I think it would be a lot easier for VSI if they just had
> > to implement ANSI/ISO and no extensions and not paying
> > any attention to maintain implementation specific features.
> >
> > But that would break a lot of application. Probably
> > most applications as those in strict ANSI/ISO with
> > no extensions probably moved off VMS years ago.
> Fortran without %IMMED or %DESCR gets really awkward to use on
> OpenVMS. For C, the OS's choice to be dual-pointer size pushed all the
> compilers in that direction. And the real non-standard stuff is all in the
> CRTL having to deal with all the RMS stuff.

and I forgot to mention Fortran %LOC which is the real showstopper for
building descriptors and itemlists. Along with similar "address of" builtins
across the other languages.