Re: ISO: The Eiffel OO programming language and IDE, on VMS

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.