Maybe others have seen this, but I just got this announcement from VSI.
Regards, Jan-Erik.

After analyzing customer feedback, VMS Software Inc. has made the decision
to move hypervisor support on OpenVMS V9.2 to the top of our priority list.
We plan to extend support for the following: VMWare, KVM and Hyper-V. Kevin
Shaw, the CEO of VMS Software, Inc. and Stephen Nelson, VP Engineering will
present this update of the VSI x86 rollout strategy at the webinar on May
11th. [Registration at https://vmssoftware.com/about/webinars/]

Better hypervisor support will mean being able to run OpenVMS on any x86
hardware, which is a priority for many customers. However, this also means
that bare metal support will be delayed – although eventually the DL380 and
several other server models are planned to be supported. The first limited
production release of OpenVMS on x86, V9.2, is scheduled for July 2022.

On 5/5/2022 5:37 PM, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.

> After analyzing customer feedback, VMS Software Inc. has made the
> decision to move hypervisor support on OpenVMS V9.2 to the top of our
> priority list. We plan to extend support for the following: VMWare, KVM
> and Hyper-V. Kevin Shaw, the CEO of VMS Software, Inc. and Stephen
> Nelson, VP Engineering will present this update of the VSI x86 rollout
> strategy at the webinar on May 11th. [Registration at
> https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also
> means that bare metal support will be delayed – although eventually the
> DL380 and several other server models are planned to be supported.

I guess that makes sense:
- many want specifically to run in VM
- even those that don't can run in VM with little extra work
- VM is easy HW support wise
- physical is complicated HW support wise

> The
> first limited production release of OpenVMS on x86, V9.2, is scheduled
> for July 2022.

So July is it.

:-)

Arne

On 5/5/2022 5:37 PM, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.
> Regards, Jan-Erik.
>
>
>
> After analyzing customer feedback, VMS Software Inc. has made the decision to
> move hypervisor support on OpenVMS V9.2 to the top of our priority list. We plan
> to extend support for the following: VMWare, KVM and Hyper-V. Kevin Shaw, the
> CEO of VMS Software, Inc. and Stephen Nelson, VP Engineering will present this
> update of the VSI x86 rollout strategy at the webinar on May 11th. [Registration
> at https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also means that
> bare metal support will be delayed – although eventually the DL380 and several
> other server models are planned to be supported. The first limited production
> release of OpenVMS on x86, V9.2, is scheduled for July 2022.

Yeah, I was about to post the info, but you beat me to it.

:-)

Too bad about the "bare metal" support. Whatever will Phillip do?

:-)

--
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 6/05/2022 5:37 am, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.
> Regards, Jan-Erik.
>
>
>
> After analyzing customer feedback, VMS Software Inc. has made the
> decision to move hypervisor support on OpenVMS V9.2 to the top of our
> priority list. We plan to extend support for the following: VMWare, KVM
> and Hyper-V. Kevin Shaw, the CEO of VMS Software, Inc. and Stephen
> Nelson, VP Engineering will present this update of the VSI x86 rollout
> strategy at the webinar on May 11th. [Registration at
> https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also
> means that bare metal support will be delayed – although eventually the
> DL380 and several other server models are planned to be supported. The
> first limited production release of OpenVMS on x86, V9.2, is scheduled
> for July 2022.

Great Stuff!

On 2022-05-05, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also means
> that bare metal support will be delayed ? although eventually the DL380 and
> several other server models are planned to be supported. The first limited
> production release of OpenVMS on x86, V9.2, is scheduled for July 2022.

General hypervisor support is a far better tradeoff for VSI to be pushing
for at this point, rather than bare metal support on just a few hardware
boxes, especially given the general trends in the industry.

BTW, if it's a production release, does that mean all the compilers
will be ready by then to go with it ?

Simon.

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

On 2022-05-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/5/2022 5:37 PM, Jan-Erik Söderholm wrote:
>> The
>> first limited production release of OpenVMS on x86, V9.2, is scheduled
>> for July 2022.
>
> So July is it.
>
>:-)
>

Yes, but July 1st, or July 32nd ?

Also :-)

Simon.

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

On 5/6/2022 8:07 AM, Simon Clubley wrote:
> On 2022-05-05, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> Better hypervisor support will mean being able to run OpenVMS on any x86
>> hardware, which is a priority for many customers. However, this also means
>> that bare metal support will be delayed ? although eventually the DL380 and
>> several other server models are planned to be supported. The first limited
>> production release of OpenVMS on x86, V9.2, is scheduled for July 2022.
>
> General hypervisor support is a far better tradeoff for VSI to be pushing
> for at this point, rather than bare metal support on just a few hardware
> boxes, especially given the general trends in the industry.
>
> BTW, if it's a production release, does that mean all the compilers
> will be ready by then to go with it ?
>
> Simon.
>

Note the wording, perhaps their "get out of jail free" card?

"first limited production release of OpenVMS on x86, V9.2, is scheduled for July
2022"

Key word, "limited".

My opinion, without native compilers, it would not be "production ready".

--
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 Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
> On 2022-05-05, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> >
> > Better hypervisor support will mean being able to run OpenVMS on any x86
> > hardware, which is a priority for many customers. However, this also means
> > that bare metal support will be delayed ? although eventually the DL380 and
> > several other server models are planned to be supported. The first limited
> > production release of OpenVMS on x86, V9.2, is scheduled for July 2022.
> General hypervisor support is a far better tradeoff for VSI to be pushing
> for at this point, rather than bare metal support on just a few hardware
> boxes, especially given the general trends in the industry.
>
> BTW, if it's a production release, does that mean all the compilers
> will be ready by then to go with it ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Other than Macro, compilers are layered products. If you want to use the
word "production" to mean "also has a minimum set of layered products",
then go for it.

For the record, we will not have all of the compilers ready as native compilers
by the release of V9.2. V9.2 includes a native Macro.

On Friday, May 6, 2022 at 10:07:58 AM UTC-4, Dave Froble wrote:
> On 5/6/2022 8:07 AM, Simon Clubley wrote:
> > On 2022-05-05, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> >>
> >> Better hypervisor support will mean being able to run OpenVMS on any x86
> >> hardware, which is a priority for many customers. However, this also means
> >> that bare metal support will be delayed ? although eventually the DL380 and
> >> several other server models are planned to be supported. The first limited
> >> production release of OpenVMS on x86, V9.2, is scheduled for July 2022..
> >
> > General hypervisor support is a far better tradeoff for VSI to be pushing
> > for at this point, rather than bare metal support on just a few hardware
> > boxes, especially given the general trends in the industry.
> >
> > BTW, if it's a production release, does that mean all the compilers
> > will be ready by then to go with it ?
> >
> > Simon.
> >
> Note the wording, perhaps their "get out of jail free" card?
> "first limited production release of OpenVMS on x86, V9.2, is scheduled for July
> 2022"
> Key word, "limited".
>
> My opinion, without native compilers, it would not be "production ready".
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486
Which compilers? Oh, never mind, you mean BASIC. :)

BASIC will not be ready in the July timeframe (even if you include July 32nd).
As I've mentioned before, BASIC presents an additional challenge on how it
describes the MAP statement to GEM. Our current G2L converter struggles
with describing it to the LLVM 3.4.2 used in the cross-compilers. The native
compilers are based on a much newer LLVM which I think/hope has a better
interface to allow us to describe them from G2L. However, I also worry that I
have to go into the BASIC frontend and do some changes (which would be
unique since G2L has been able to mimic GEM so far even with other frontends
that don't correctly create GEM symbol tables/IR)

On 5/6/2022 11:21 AM, John Reagan wrote:
> On Friday, May 6, 2022 at 10:07:58 AM UTC-4, Dave Froble wrote:
>> On 5/6/2022 8:07 AM, Simon Clubley wrote:
>>> On 2022-05-05, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>>
>>>> Better hypervisor support will mean being able to run OpenVMS on any x86
>>>> hardware, which is a priority for many customers. However, this also means
>>>> that bare metal support will be delayed ? although eventually the DL380 and
>>>> several other server models are planned to be supported. The first limited
>>>> production release of OpenVMS on x86, V9.2, is scheduled for July 2022.
>>>
>>> General hypervisor support is a far better tradeoff for VSI to be pushing
>>> for at this point, rather than bare metal support on just a few hardware
>>> boxes, especially given the general trends in the industry.
>>>
>>> BTW, if it's a production release, does that mean all the compilers
>>> will be ready by then to go with it ?
>>>
>>> Simon.
>>>
>> Note the wording, perhaps their "get out of jail free" card?
>> "first limited production release of OpenVMS on x86, V9.2, is scheduled for July
>> 2022"
>> Key word, "limited".
>>
>> My opinion, without native compilers, it would not be "production ready".
>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
> Which compilers? Oh, never mind, you mean BASIC. :)
>
> BASIC will not be ready in the July timeframe (even if you include July 32nd).
> As I've mentioned before, BASIC presents an additional challenge on how it
> describes the MAP statement to GEM. Our current G2L converter struggles
> with describing it to the LLVM 3.4.2 used in the cross-compilers. The native
> compilers are based on a much newer LLVM which I think/hope has a better
> interface to allow us to describe them from G2L. However, I also worry that I
> have to go into the BASIC frontend and do some changes (which would be
> unique since G2L has been able to mimic GEM so far even with other frontends
> that don't correctly create GEM symbol tables/IR)
>

No problem John. I have faith in you. I'm also aware that you're faced with a
rather large task. Take your time, do it right.

--
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 5/6/2022 11:15 AM, John Reagan wrote:
> On Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
>> BTW, if it's a production release, does that mean all the compilers
>> will be ready by then to go with it ?

> Other than Macro, compilers are layered products. If you want to use the
> word "production" to mean "also has a minimum set of layered products",
> then go for it.
>
> For the record, we will not have all of the compilers ready as native compilers
> by the release of V9.2. V9.2 includes a native Macro.

What are current ETA's for the various native compilers?

Arne

On 5/6/2022 3:42 PM, Arne Vajhøj wrote:
> On 5/6/2022 11:15 AM, John Reagan wrote:
>> On Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
>>> BTW, if it's a production release, does that mean all the compilers
>>> will be ready by then to go with it ?
>
>> Other than Macro, compilers are layered products. If you want to use the
>> word "production" to mean "also has a minimum set of layered products",
>> then go for it.
>>
>> For the record, we will not have all of the compilers ready as native compilers
>> by the release of V9.2. V9.2 includes a native Macro.
>
> What are current ETA's for the various native compilers?
>
> Arne
>

Seems to me, if they knew that, some of them would already be available.
Knowing what is needed to be done just needs man hours. Trying to figure out
what must be done sort of waits for "eurika, I've figured it out", and that is
sort of tough to schedule.

--
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 Friday, May 6, 2022 at 3:43:05 PM UTC-4, Arne Vajhøj wrote:
> On 5/6/2022 11:15 AM, John Reagan wrote:
> > On Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
> >> BTW, if it's a production release, does that mean all the compilers
> >> will be ready by then to go with it ?
> > Other than Macro, compilers are layered products. If you want to use the
> > word "production" to mean "also has a minimum set of layered products",
> > then go for it.
> >
> > For the record, we will not have all of the compilers ready as native compilers
> > by the release of V9.2. V9.2 includes a native Macro.
> What are current ETA's for the various native compilers?
>
> Arne
Didn't I just do that a few weeks ago? I think I did. We're working on native
BLISS, native C, and native C++ right now. All three are in various stages of "done".
We've been tracking down a memory corrupter in the native C compiler for a week now.
We're doing it the hard way with printf's, etc. since SET WATCH isn't working in the
debugger yet. All of these are shaking out bugs in the cross-compilers that we
build them with, finding latent incorrect code, etc. My hand-wave is late summer
but I keep getting surprised (sometimes in the good way, sometimes in the bad way)

On 05/06/22 23:20, John Reagan wrote:
> On Friday, May 6, 2022 at 3:43:05 PM UTC-4, Arne Vajhøj wrote:
>> On 5/6/2022 11:15 AM, John Reagan wrote:
>>> On Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
>>>> BTW, if it's a production release, does that mean all the compilers
>>>> will be ready by then to go with it ?
>>> Other than Macro, compilers are layered products. If you want to use the
>>> word "production" to mean "also has a minimum set of layered products",
>>> then go for it.
>>>
>>> For the record, we will not have all of the compilers ready as native compilers
>>> by the release of V9.2. V9.2 includes a native Macro.
>> What are current ETA's for the various native compilers?
>>
>> Arne
> Didn't I just do that a few weeks ago? I think I did. We're working on native
> BLISS, native C, and native C++ right now. All three are in various stages of "done".
> We've been tracking down a memory corrupter in the native C compiler for a week now.
> We're doing it the hard way with printf's, etc. since SET WATCH isn't working in the
> debugger yet. All of these are shaking out bugs in the cross-compilers that we
> build them with, finding latent incorrect code, etc. My hand-wave is late summer
> but I keep getting surprised (sometimes in the good way, sometimes in the bad way)

I would expect a C compiler to be part of an OS these days, or
just a package download, not so much C++. Even early unix
machines had a minimum of pcc, which was enough to build an
early gcc and associated tools. An OS is useless without
that, unless you are to run prepackaged apps...

Chris

On 5/6/2022 6:20 PM, John Reagan wrote:
> On Friday, May 6, 2022 at 3:43:05 PM UTC-4, Arne Vajhøj wrote:
>> On 5/6/2022 11:15 AM, John Reagan wrote:
>>> On Friday, May 6, 2022 at 8:07:38 AM UTC-4, Simon Clubley wrote:
>>>> BTW, if it's a production release, does that mean all the compilers
>>>> will be ready by then to go with it ?
>>> Other than Macro, compilers are layered products. If you want to use the
>>> word "production" to mean "also has a minimum set of layered products",
>>> then go for it.
>>>
>>> For the record, we will not have all of the compilers ready as native compilers
>>> by the release of V9.2. V9.2 includes a native Macro.

>> What are current ETA's for the various native compilers?

> Didn't I just do that a few weeks ago? I think I did.

You did. Early April. But I was curious for whether there were an
update.

I think it is fair to say that native compilers are important
for the perception of how "ready" VMS x86-64 is.

That is not necessarily a good or fair criteria, but the criteria
is applied in the world we live in.

> We're working on native
> BLISS, native C, and native C++ right now. All three are in various stages of "done".
> We've been tracking down a memory corrupter in the native C compiler for a week now.
> We're doing it the hard way with printf's, etc. since SET WATCH isn't working in the
> debugger yet. All of these are shaking out bugs in the cross-compilers that we
> build them with, finding latent incorrect code, etc. My hand-wave is late summer
> but I keep getting surprised (sometimes in the good way, sometimes in the bad way)

OK.

Arne

On Fri, 2022-05-06 at 08:15 -0700, John Reagan wrote:

> For the record, we will not have all of the compilers ready as native
> compilers by the release of V9.2.  V9.2 includes a native Macro.

Perfect, that can be used to bootstrap a compilier. it's just a matter
of writing something in macro that can be used to compile the compilier
itself until it can compile itself.
--
Tactical Nuclear Kittens

So, is native Pascal planned? It would be fun to get something like VMS Moria up and running, which should in theory be possible with Pascal and Macro.. Alternatively, has anybody with access to the current cross-compilers tried to build it? It likely wouldn't take long and would be amusing to see pop up in the list of officially supported open source* packages.

Mike

* VMS Moria isn't technically open source as the license contains a prohibition on commercial use. But I suspect that simply compiling it and offering it as a free download wouldn't count as commercial.

On Friday, May 6, 2022 at 6:20:57 PM UTC-4, xyzz...@gmail.com wrote:

> Didn't I just do that a few weeks ago? I think I did. We're working on native
> BLISS, native C, and native C++ right now. All three are in various stages of "done".
> We've been tracking down a memory corrupter in the native C compiler for a week now.
> We're doing it the hard way with printf's, etc. since SET WATCH isn't working in the
> debugger yet. All of these are shaking out bugs in the cross-compilers that we
> build them with, finding latent incorrect code, etc. My hand-wave is late summer
> but I keep getting surprised (sometimes in the good way, sometimes in the bad way)

On Saturday, May 7, 2022 at 10:03:30 PM UTC-4, Mike K. wrote:
> So, is native Pascal planned? It would be fun to get something like VMS Moria up and running, which should in theory be possible with Pascal and Macro. Alternatively, has anybody with access to the current cross-compilers tried to build it? It likely wouldn't take long and would be amusing to see pop up in the list of officially supported open source* packages.
>
> Mike
>
> * VMS Moria isn't technically open source as the license contains a prohibition on commercial use. But I suspect that simply compiling it and offering it as a free download wouldn't count as commercial.
> On Friday, May 6, 2022 at 6:20:57 PM UTC-4, xyzz...@gmail.com wrote:
>
> > Didn't I just do that a few weeks ago? I think I did. We're working on native
> > BLISS, native C, and native C++ right now. All three are in various stages of "done".
> > We've been tracking down a memory corrupter in the native C compiler for a week now.
> > We're doing it the hard way with printf's, etc. since SET WATCH isn't working in the
> > debugger yet. All of these are shaking out bugs in the cross-compilers that we
> > build them with, finding latent incorrect code, etc. My hand-wave is late summer
> > but I keep getting surprised (sometimes in the good way, sometimes in the bad way)
Yes, all native compilers are planned. I don't expect Pascal to be a challenge once we get
the bugs from BLISS and C shaken out. I might have the Moria kit somewhere but it might
take a while before I find time to try the cross-compiler with it.

On 5/8/2022 2:11 PM, John Reagan wrote:
> Yes, all native compilers are planned. I don't expect Pascal to be a challenge once we get
> the bugs from BLISS and C shaken out. I might have the Moria kit somewhere but it might
> take a while before I find time to try the cross-compiler with it.

My guess is that VMS is one of the most diverse platforms
when it comes to native languages usage.

*nix and Win are almost entirely C and C++.

Mainframe has a strong presence of Cobol and PL/I
and today probably some C and C++ and maybe a little
bit of Fortran..

On VMS all the languages are really widely used: Pascal,
Basic, Cobol, Fortran, C. The only one I am not sure about
is C++.

Arne

In article <627816cf$0$705$14726298@news.sunsite.dk>, arne@vajhoej.dk
(Arne Vajh�j) wrote:

> My guess is that VMS is one of the most diverse platforms
> when it comes to native languages usage.
>
> On VMS all the languages are really widely used: Pascal,
> Basic, Cobol, Fortran, C. The only one I am not sure about
> is C++.

A good C++ compiler will be necessary to get ISVs to start supporting VMS.
(It's also required for compiling the LLVM backend for native compilers
on x86.)

John

On 5/8/2022 3:40 PM, John Dallman wrote:
> In article <627816cf$0$705$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> My guess is that VMS is one of the most diverse platforms
>> when it comes to native languages usage.
>>
>> On VMS all the languages are really widely used: Pascal,
>> Basic, Cobol, Fortran, C. The only one I am not sure about
>> is C++.
>
> A good C++ compiler will be necessary to get ISVs to start supporting VMS.
> (It's also required for compiling the LLVM backend for native compilers
> on x86.)

Oh yes.

C++ is needed for a lot of platform type stuff.

LLVM, OpenJDK etc..

I was not indicating that C++ was not needed. I was just trying to
say that I don't think there are that many VMS C++ custom
business applications out there.

Arne

On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> My guess is that VMS is one of the most diverse platforms
> when it comes to native languages usage.
>
> *nix and Win are almost entirely C and C++.
>
> Mainframe has a strong presence of Cobol and PL/I
> and today probably some C and C++ and maybe a little
> bit of Fortran..
>
> On VMS all the languages are really widely used: Pascal,
> Basic, Cobol, Fortran, C. The only one I am not sure about
> is C++.
>

[Now it's my turn. :-)]

Hey, you forgot about Ada!

On a more serious note, so did VSI, probably because all the Ada users
have probably been forced away from VMS by now...

Simon.

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

On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> [Now it's my turn. :-)]
>
> Hey, you forgot about Ada!
>
> On a more serious note, so did VSI, probably because all the Ada
> users
> have probably been forced away from VMS by now...

As soon as they make the compilers available, it should be
straightforward to port the GCC suite over to the x86_64 platform and
that'll include ADA if VSI doesn't port Ada over as well.

On another note, I think it'll be interesting to get Rust running on
this platform as well.
--
Tactical Nuclear Kittens

On Monday, May 9, 2022 at 3:01:27 PM UTC+1, Single Stage to Orbit wrote:
> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
> > On 2022-05-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >
> > [Now it's my turn. :-)]
> >
> > Hey, you forgot about Ada!
> >
> > On a more serious note, so did VSI, probably because all the Ada
> > users
> > have probably been forced away from VMS by now...
> As soon as they make the compilers available, it should be
> straightforward to port the GCC suite over to the x86_64 platform and
> that'll include ADA if VSI doesn't port Ada over as well.
>
> On another note, I think it'll be interesting to get Rust running on
> this platform as well.
> --
> Tactical Nuclear Kittens

A supported ADA compiler for OpenVMS is wanted.

On 2022-05-09, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> [Now it's my turn. :-)]
>>
>> Hey, you forgot about Ada!
>>
>> On a more serious note, so did VSI, probably because all the Ada
>> users
>> have probably been forced away from VMS by now...
>
> As soon as they make the compilers available, it should be
> straightforward to port the GCC suite over to the x86_64 platform and
> that'll include ADA if VSI doesn't port Ada over as well.
>

You have clearly never looked deeply into the gcc and binutils internals
or you have way more knowledge about gcc internals than I do... :-)

I looked at this for Alpha and I eventually gave up, because even with
some VMS support still in gcc/binutils at that time, there appeared to
be bits missing.

I was able to compile gcc/binutils for VMS Alpha as a cross-compiler on
a Linux host and was able to generate some C language Alpha binaries on
Linux which ran ok on VMS Alpha but that was as far as I got.

I was never able to get GNAT to build as a cross-compiler on Linux
for VMS Alpha because I kept hitting an internal compiler error.

IIRC, the VMS support was completely stripped from FSF binutils/gcc
in a later version of those toolkits.

The VMS support (such as it was in the FSF GCC version) would need to
be added back in and fixed, x86-64 VMS added as a gcc target (which
should be easier for x86-64 than it for VMS Alpha) into gcc itself and
then support for a x86-64 VMS target added into the Ada runtime itself.

Have fun. :-)

Simon.

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