Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: VSI compiler webinar
Date: Thu, 27 Mar 2025 19:22:24 -0400
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <vs4mjg$1aptp$1@dont-email.me>
References: <vrk01m$1pn8a$1@dont-email.me>
 <31202c11e7c49616ec97f1d5914f8d2803c2184b@i2pn2.org>
 <m4a4e3FoatU1@mid.individual.net> <vrpjdf$2r6bm$1@dont-email.me>
 <vrs90i$1gda7$1@dont-email.me>
 <ab0d386078f6a4641613f45b33d0246145357304@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Mar 2025 00:22:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7b664625f37ea09cdc15f765c3e12345";
	logging-data="1402809"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1UhDnNTML5//mpf3k+aEfOOoTgOVK6K4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:QPoubOc9e91sIk/wRh97CKTTT2o=
Content-Language: en-US
In-Reply-To: <ab0d386078f6a4641613f45b33d0246145357304@i2pn2.org>
Bytes: 5906

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