Re: VSI compiler webinar

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