Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: ISO: The Eiffel OO programming language and IDE, on VMS
Date: Wed, 26 Mar 2025 13:46:04 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vs10es$in7$1@reader1.panix.com>
References: <j7jutjdo007jkfp956ofp846ecb0nfpr32@4ax.com> <vs0qdf$1mlt9$1@dont-email.me> <vs0r3r$cr$1@reader1.panix.com> <vs0uid$1q5mh$1@dont-email.me>
Injection-Date: Wed, 26 Mar 2025 13:46:04 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="19175"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4430
Lines: 81

In article <vs0uid$1q5mh$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 3/26/2025 8:14 AM, Dan Cross wrote:
>> In article <vs0qdf$1mlt9$1@dont-email.me>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 3/26/2025 1:09 AM, David Meyer wrote:
>>>> Is there anything in the VSI licensing that would prevent a community of
>>>> VMS and Rust (for example) fans from developing a VMS port of a Rust
>>>> compiler and releasing the compiler as open source?
>>>
>>> No.
>>>
>>> VMS users can write or port all the compilers they want to. And
>>> they have done so in the past: old versions of GCC C and C++ ran on
>>> VMS VAX and VMS Alpha, old versions of Gnat Ada ran on VMS Alpha
>>> and VMS Itanium.
>>>
>>> The reason it is not happening is not license restrictions, but
>>> lack of interest (willing to do work type of interest - not
>>> it would be nice if somebody else did the work interest) in
>>> the VMS community.
>>>
>>> The specific discussion was about the LLVM compiler backend,
>>> that VSI use for their compilers. If VSI made that available
>>> (it is open source) then it would be easier for people to
>>> write or port new compilers using LLVM as backend.
>> 
>> The official Rust compiler is an interesting case in point, as
>> it's already built on LLVM.  Getting it running on VMS probably
>> wouldn't be that hard; getting it to output code targetting VMS
>> is probably harder, but certainly doable.
>
>Oversimplified I believe work would be:
>
>"frontend" - should not be VMS specific, but it is written
>in Rust so a bootstrapping process is needed - compiler bootstrapping
>is a known concept, but still some work

The bootstrapping part is pretty easy, actually: rustc is
inherently a cross-compiler.  One can start on Linux/BSD/macOS
or Windows whatever.  But it would require the VSI LLVM backend.
I also don't know how hard it would be to get the current
version of Rust running on the version of LLVM VSI is floating
internally for VMS; last time I checked, LLVM's internal
interfaces aren't stable, so things do shift from time to time;
at one point, Rust had a soft-fork of LLVM that they targetted,
but they tracked upstream pretty closely.  I don't know if that
is still true.

>"backend" - LLVM, if VSI release their VMS LLVM changes some integration
>work, if not a huge porting work

If by "backend" you mean code generation that targets VMS, then
that part is still pretty straight-forward: the VMS ABI on
x86_64 is basically the System V ABI, which is already well
supported.

>"library" - effort will depend on how much is directly calling the OS
>(meaning LIB$ or SYS$ calls on VMS) and how much it is utilizing the
>C RTL - I don't know that so it can be little or much work
>
>"VMS stuff" - installation script, VMS debugger support,
>the equivalent to the C descrip.h, starlet.h and lib$routines.h etc. -
>also some work (but when that work start then the goal post
>is in sight!)

This is the hardest bit of work.  Both figuring out how to
integrate VMS support into the Rust standard library, and how
to wrap functionality that falls outside of the purview of the
standard library into Rust's crate abstractions.  Building safe
(in the Rust sense) interfaces around VMS APIs sounds both
interesting and challenging.

>Certainly doable. It is being done all the time. Similar work has
>been done on VMS in the past.
>
>But still let us call it "non trivial".

Sure.  That's reasonable.

	- Dan C.