On 3/21/2025 11:19 AM, Arne Vajhøj wrote:

This just hit my inbox:

<quote>
...
Webinar: Compiler Considerations in Migrating to OpenVMS on x86
April 9th, 10:00 AM EDT / 4:00 PM CEDT
...
Join us for a technical deep dive with John Reagan, lead compiler
architect at VMS Software, who has been working on OpenVMS compilers
since 1983.

In this session, John will guide us through the evolution and current
state of OpenVMS compiler products for x86-64 systems. He will explore
the usage of LLVM compiler technology, key features of current and
upcoming releases, and share practical advice on common challenges when porting to x86-64.
...
</quote>

Those interested that has not received the invite should
contact their friendly VSI sales person and ask for one.

I think the link in the email invite is personal,
but the link in the LinkedIn announcement looks
non-personal, so here it is:

https://zoom.us/webinar/register/WN_Wi1nQFvdRBunZYiIrZ6uCw#/registration

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This just hit my inbox:

<quote>
...
Webinar: Compiler Considerations in Migrating to OpenVMS on x86
April 9th, 10:00 AM EDT / 4:00 PM CEDT
...
Join us for a technical deep dive with John Reagan, lead compiler
architect at VMS Software, who has been working on OpenVMS compilers
since 1983.

In this session, John will guide us through the evolution and current
state of OpenVMS compiler products for x86-64 systems. He will explore
the usage of LLVM compiler technology, key features of current and
upcoming releases, and share practical advice on common challenges when
porting to x86-64.
...
</quote>

Those interested that has not received the invite should
contact their friendly VSI sales person and ask for one.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/2025 11:19 AM, Arne Vajhøj wrote:

This just hit my inbox:

<quote>
...
Webinar: Compiler Considerations in Migrating to OpenVMS on x86
April 9th, 10:00 AM EDT / 4:00 PM CEDT
...
Join us for a technical deep dive with John Reagan, lead compiler
architect at VMS Software, who has been working on OpenVMS compilers
since 1983.

In this session, John will guide us through the evolution and current
state of OpenVMS compiler products for x86-64 systems. He will explore
the usage of LLVM compiler technology, key features of current and
upcoming releases, and share practical advice on common challenges when porting to x86-64.
...
</quote>

Those interested that has not received the invite should
contact their friendly VSI sales person and ask for one.

Arne

I'm working on my witty remarks now. However, given that I only have 45 minutes, I won't be able to perform my one-man show "BLISS, the musical!"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm working on my witty remarks now. However, given that I only have 45 minutes, I won't be able to perform my one-man show "BLISS, the musical!"

Streaming on Starlet+ when? :)

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 21/03/2025 à 20:43, John Reagan a écrit :

On 3/21/2025 11:19 AM, Arne Vajhøj wrote:

This just hit my inbox:

<quote>
...
Webinar: Compiler Considerations in Migrating to OpenVMS on x86
April 9th, 10:00 AM EDT / 4:00 PM CEDT
...
Join us for a technical deep dive with John Reagan, lead compiler
architect at VMS Software, who has been working on OpenVMS compilers
since 1983.

In this session, John will guide us through the evolution and current
state of OpenVMS compiler products for x86-64 systems. He will explore
the usage of LLVM compiler technology, key features of current and
upcoming releases, and share practical advice on common challenges
when porting to x86-64.
...
</quote>

Those interested that has not received the invite should
contact their friendly VSI sales person and ask for one.

Arne

I'm working on my witty remarks now.  However, given that I only have 45 minutes, I won't be able to perform my one-man show "BLISS, the musical!"

You'll have to be careful with old people. You know the Beatles song,
when I'm sixty-four. For my part, I have two questions that I started
asking at 64, a little less than ten years ago:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

Be patient, old people are nicknamed "ramblers." Ramblers, but good
sports, now you've been warned.

You will have two questions:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

You will have two questions.

Be patient.

Anyway, it'll be for us a great pleasure.

Gérard Calliet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/23/2025 6:00 AM, gcalliet wrote:

Le 21/03/2025 à 20:43, John Reagan a écrit :

I'm working on my witty remarks now.  However, given that I only have
45 minutes, I won't be able to perform my one-man show "BLISS, the
musical!"

You'll have to be careful with old people. You know the Beatles song,
when I'm sixty-four. For my part, I have two questions that I started
asking at 64, a little less than ten years ago:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

You will have two questions:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

You will have two questions.

I will assume any VMS specific changes to LLVM will
eventually make it back to upstream LLVM project - it
makes sense for VSI to avoid having to merge those
changes every time they take a new version.

And as stated in another thread then I would love to
see VSI put all their open source usage in public
Github repo's.

But VMS LLVM is rather old (if I remember correctly then it
is, because it had to be build on Itanium with VMS C++
for cross compilers).

So I would rephrase the question as:

can VSI say whether they want to:
1) make VMS LLVM code available
2) upgrade LLVM
or:
1) upgrade LLVM
2) make VMS LLVM code available
?

:-)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 23/03/2025 à 19:20, Arne Vajhøj a écrit :

On 3/23/2025 6:00 AM, gcalliet wrote:

Le 21/03/2025 à 20:43, John Reagan a écrit :

I'm working on my witty remarks now.  However, given that I only have
45 minutes, I won't be able to perform my one-man show "BLISS, the
musical!"

You'll have to be careful with old people. You know the Beatles song,
when I'm sixty-four. For my part, I have two questions that I started
asking at 64, a little less than ten years ago:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

You will have two questions:

Could we collaborate on the Ada compiler?
When will we have access to the LLVM workshop?

You will have two questions.

I will assume any VMS specific changes to LLVM will
eventually make it back to upstream LLVM project - it
makes sense for VSI to avoid having to merge those
changes every time they take a new version.

And as stated in another thread then I would love to
see VSI put all their open source usage in public
Github repo's.

But VMS LLVM is rather old (if I remember correctly then it
is, because it had to be build on Itanium with VMS C++
for cross compilers).

So I would rephrase the question as:

can VSI say whether they want to:
  1) make VMS LLVM code available
  2) upgrade LLVM
or:
  1) upgrade LLVM
  2) make VMS LLVM code available
?

:-)

Arne

Understood. I agree on all that you said.

I'll add motivation. LLVM is a foundation for many interesting languages
or projects. These languages or projects ​​don't all have to be
certified by VSI, but they can be the basis for very important open
source developments.

Therefore, like any building block of an open source structure,
publishing and updating modifications allows anyone who wants to use
them to work, and it's up to the users of the building blocks to see how
to adapt to the changes.

John will give us the details of LLVM's age. From my perspective, it
seems to me that this is a characteristic and a general constraint for
open source development with VMS. It certainly requires a specific
programming art, but it doesn't prevent anything. What prevents it, we
agree on this, is the absence of the source code.

Finally, when the future is magnificent, VSI will be able to return its transformations to the LLVM main stream. We're not there yet, but we
have now a rich Open Source VMS workshop potentially available, if the
door is open.

Gérard Calliet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-23, Arne Vajhøj <arne@vajhoej.dk> wrote:

But VMS LLVM is rather old (if I remember correctly then it
is, because it had to be build on Itanium with VMS C++
for cross compilers).

You also need CMake to build current LLVM versions. John was working
on this at one time, but I don't know what the current status is.

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Mar 2025 11:10:42 +0100, gcalliet wrote:

Finally, when the future is magnificent, VSI will be able to return its transformations to the LLVM main stream.

Being able to return contributions to the main stream does depend somewhat
on not falling too far behind the main stream.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/24/2025 2:41 PM, Simon Clubley wrote:

On 2025-03-23, Arne Vajhøj <arne@vajhoej.dk> wrote:

But VMS LLVM is rather old (if I remember correctly then it
is, because it had to be build on Itanium with VMS C++
for cross compilers).

You also need CMake to build current LLVM versions. John was working
on this at one time, but I don't know what the current status is.

Simon.

Lots of good questions for sure! And be sure to come see me in person
in May in Malmö at the VSI Bootcamp. I'll be on display daily.

Yes, we are currently using clang/LLVM 10.0.1. It is bootstrapped using
a Linux version of the same code base with changes to create OpenVMS
objects (it knows about CRTL name mapping, argcounts, and all that
stuff). What we did was:

- start with the plain 10.0.1 sources and 10.0.1 binaries
- add code to clang/LLVM (much of the LLVM changes were just carried
over from the LLVM 3.4.2 codebase we used with the cross compilers)
- build that code on Linux creating a 10.0.1v compiler
- use that compiler to build it all again
- copy all the .o files over to an OpenVMS machine to put into OLBs
- link clang using those OLBs on OpenVMS
- use that clang on OpenVMS to build our G2L (GEM to LLVM converter)
- link all the legacy frontends (originally build with cross compilers
but now built with native compilers) with the G2L and LLVM libraries
- test & make kits
- and Bob's your uncle and much easier than learning to say the French R
sound

As for native building, we do have a CMake ported and are currently
working on native building that 10.0.1v source tree on OpenVMS V9.2-3
including some work to CMake to make it easier for symbol vector
management for LIBCXX/LIBCXXABI. Not quite to testing yet.

We have also downloaded the latest LLVM (either 20.1.0 or 20.1.1, I'd
have to go check). As a first step, we've been able to compile that on
Linux using the same 10.0.1v compiler that we use today. The LLVM 20
code base is much larger as you can imagine and we're working on linking
up the LIBCXX/LIBCXXABI libraries right now. The number of LLVM
libraries is also different. We've merged in some but not all of the
OpenVMS additions but nothing tested yet. We'll have to upgrade our G2L
since the internal LLVM IR is not guaranteed to be upward compatible and they've changed several of the interfaces over the last few years. And
to make it even more painful, LLVM 20 now requires a newer CMake version
than the one we ported. Ugh! We'll do it again and then look at
providing it online as well.

As for merging our code back into the actually LLVM repo, that's still a
work in progress. Once we switch to LLVM 20, we will be in a much
better position to make the case to the LLVM community. I think it will
be an easier discussion for the LLVM changes. The clang changes might
be a tougher sell since our addition of dual-sized pointers, listing
files, etc might scare off a few people. It would be difficult for the
build bots to build (we would have to provide and manage some systems).

Making our VSI git repositories visible would be another choice.
However, if you haven't noticed,

https://arstechnica.com/gadgets/2025/03/google-makes-android-development-private-will-continue-open-source-releases/

Besides the sources (and scripts), I'd like to make another kit of
pre-built images (and perhaps the LLVM libraries) that come out of the
LLVM build today. There are some of the LLVM tools that are only useful
to compiler developers like llvm-dis but there are some tools like clang-format, llvm-objdump, llvm-dwarfdump, llvm-nm, etc that others
might want. For example, the X86ASM product on the support portal is
just the llvm-mc tool. llvm-mc is quite powerful as both an assembler
AND disassembler. It can even convert between AMD and Intel syntax as a
party trick.

G2L, while completely written by VSI, would only be useful if you have a compiler frontend that generates GEM CIL. And G2L does use GEM headers
so that's where the existing HPE copyrights start to appear.

Vi ses snart i Malmö

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/27/2025 6:22 PM, John Reagan wrote:

Yes, we are currently using clang/LLVM 10.0.1.  It is bootstrapped using
a Linux version of the same code base with changes to create OpenVMS
objects (it knows about CRTL name mapping, argcounts, and all that
stuff).  What we did was:

- start with the plain 10.0.1 sources and 10.0.1 binaries
- add code to clang/LLVM (much of the LLVM changes were just carried
over from the LLVM 3.4.2 codebase we used with the cross compilers)
- build that code on Linux creating a 10.0.1v compiler
- use that compiler to build it all again
- copy all the .o files over to an OpenVMS machine to put into OLBs
- link clang using those OLBs on OpenVMS
- use that clang on OpenVMS to build our G2L (GEM to LLVM converter)
- link all the legacy frontends (originally build with cross compilers
but now built with native compilers) with the G2L and LLVM libraries
- test & make kits
- and Bob's your uncle and much easier than learning to say the French R sound

Ah - so 3.4.2 was only Itanium cross compiling while native use 10.0.1 -
that makes a release even more interesting!! :-)

As for native building, we do have a CMake ported and are currently
working on native building that 10.0.1v source tree on OpenVMS V9.2-3 including some work to CMake to make it easier for symbol vector
management for LIBCXX/LIBCXXABI.  Not quite to testing yet.

Do you plan on releasing CMake for VMS?

Please say yes. :-)

We have also downloaded the latest LLVM (either 20.1.0 or 20.1.1, I'd
have to go check).  As a first step, we've been able to compile that on Linux using the same 10.0.1v compiler that we use today.  The LLVM 20
code base is much larger as you can imagine and we're working on linking
up the LIBCXX/LIBCXXABI libraries right now.  The number of LLVM
libraries is also different.  We've merged in some but not all of the OpenVMS additions but nothing tested yet.  We'll have to upgrade our G2L since the internal LLVM IR is not guaranteed to be upward compatible and they've changed several of the interfaces over the last few years.  And
to make it even more painful, LLVM 20 now requires a newer CMake version
than the one we ported.  Ugh!  We'll do it again and then look at
providing it online as well.

As for merging our code back into the actually LLVM repo, that's still a
work in progress.  Once we switch to LLVM 20, we will be in a much
better position to make the case to the LLVM community.  I think it will
be an easier discussion for the LLVM changes.

Obviously.

But it will also take longer time.

  The clang changes might
be a tougher sell since our addition of dual-sized pointers, listing
files, etc might scare off a few people. It would be difficult for the
build bots to build (we would have to provide and manage some systems).

I don't think clang changes are as interesting as LLVM changes.

You provide C and C++. No point in community to do another C or C++.

But maybe (just maybe) the community could do some languages that
VSI does not provide utilizing the LLVM backend.

Making our VSI git repositories visible would be another choice.
However, if you haven't noticed,

https://arstechnica.com/gadgets/2025/03/google-makes-android- development-private-will-continue-open-source-releases/

Google & Android and VSI & VMS are in very different states.

Besides the sources (and scripts), I'd like to make another kit of pre-
built images (and perhaps the LLVM libraries) that come out of the LLVM
build today.  There are some of the LLVM tools that are only useful to compiler developers like llvm-dis but there are some tools like clang- format, llvm-objdump, llvm-dwarfdump, llvm-nm, etc that others might
want.  For example, the X86ASM product on the support portal is just the llvm-mc tool.  llvm-mc is quite powerful as both an assembler AND disassembler.  It can even convert between AMD and Intel syntax as a
party trick.

Go for it!

Please.

G2L, while completely written by VSI, would only be useful if you have a compiler frontend that generates GEM CIL.  And G2L does use GEM headers
so that's where the existing HPE copyrights start to appear.

Are there any non-VSI compilers using GEM? Kednos PL/I? Synergex DBL?

If there are then maybe some interest. Assuming IPR can be worked out.

Not relevant for the "new stuff".

Vi ses snart i Malmö

:-)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:

Are there any non-VSI compilers using GEM? Kednos PL/I? Synergex DBL?

I wonder what happened to the Synergex discussions ?

I don't know if the VMS Synergex users have moved to another platform
by now, but certainly up to a few years ago, I can imagine there would
be a good number of those users who would seriously consider moving
their applications to x86-64 VMS.

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/28/2025 3:24 PM, Simon Clubley wrote:

On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:

Are there any non-VSI compilers using GEM? Kednos PL/I? Synergex DBL?

I wonder what happened to the Synergex discussions ?

I don't know if the VMS Synergex users have moved to another platform
by now, but certainly up to a few years ago, I can imagine there would
be a good number of those users who would seriously consider moving
their applications to x86-64 VMS.

I have not heard anything about DBL since 1-2-3 years ago it was
stated that they had no plans to port to VMS x86-64.

I assume that they still support VMS Alpha and VMS Itanium.

I don't even know if they use GEM, but given that DEC sold to
them in 1993 when Alpha existed, then it is a possibility that
they use GEM and could benefit of the GEM to LLVM + LLVM
backend, *if* they were to port to VMS x86-64.

Strategically I think Synergex is betting on DBL for .NET (so
a port of .NET to VMS x86-64 would get DBL).

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/2025 11:30 AM, Arne Vajhøj wrote:

On 3/21/2025 11:19 AM, Arne Vajhøj wrote:

This just hit my inbox:

<quote>
...
Webinar: Compiler Considerations in Migrating to OpenVMS on x86
April 9th, 10:00 AM EDT / 4:00 PM CEDT
...
Join us for a technical deep dive with John Reagan, lead compiler
architect at VMS Software, who has been working on OpenVMS compilers
since 1983.

In this session, John will guide us through the evolution and current
state of OpenVMS compiler products for x86-64 systems. He will explore
the usage of LLVM compiler technology, key features of current and
upcoming releases, and share practical advice on common challenges
when porting to x86-64.
...
</quote>

Those interested that has not received the invite should
contact their friendly VSI sales person and ask for one.

I think the link in the email invite is personal,
but the link in the LinkedIn announcement looks
non-personal, so here it is:

https://zoom.us/webinar/register/WN_Wi1nQFvdRBunZYiIrZ6uCw#/registration

It is available now at:

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

and related to the LLVM toolchain and other languages question
then listen to 53:30-55:00.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)