In article <t5bl41$unq$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> IIRC, the VMS support was completely stripped from FSF binutils/gcc
> in a later version of those toolkits.
>
> The VMS support (such as it was in the FSF GCC version) would need
> to be added back in and fixed, x86-64 VMS added as a gcc target
> (which should be easier for x86-64 than it for VMS Alpha) into
> gcc itself and then support for a x86-64 VMS target added into
> the Ada runtime itself.

This will be simplified, a bit, by x86-64 using ELF, as opposed to the
VAX or Alpha object languages. But that means only parts of the old
support need putting back.

John

On 5/9/2022 8:55 AM, Simon Clubley wrote:
> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> My guess is that VMS is one of the most diverse platforms
>> when it comes to native languages usage.
>>
>> *nix and Win are almost entirely C and C++.
>>
>> Mainframe has a strong presence of Cobol and PL/I
>> and today probably some C and C++ and maybe a little
>> bit of Fortran..
>>
>> On VMS all the languages are really widely used: Pascal,
>> Basic, Cobol, Fortran, C. The only one I am not sure about
>> is C++.
>
> [Now it's my turn. :-)]
>
> Hey, you forgot about Ada!
>
> On a more serious note, so did VSI, probably because all the Ada users
> have probably been forced away from VMS by now...

I must admit that I consider Ada on VMS as dead (along
with PL/I).

Arne

On 5/9/22 19:10, Arne Vajhøj wrote:
> On 5/9/2022 8:55 AM, Simon Clubley wrote:
>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> My guess is that VMS is one of the most diverse platforms
>>> when it comes to native languages usage.
>>>
>>> *nix and Win are almost entirely C and C++.
>>>
>>> Mainframe has a strong presence of Cobol and PL/I
>>> and today probably some C and C++ and maybe a little
>>> bit of Fortran..
>>>
>>> On VMS all the languages are really widely used: Pascal,
>>> Basic, Cobol, Fortran, C. The only one I am not sure about
>>> is C++.
>>
>> [Now it's my turn. :-)]
>>
>> Hey, you forgot about Ada!
>>
>> On a more serious note, so did VSI, probably because all the Ada users
>> have probably been forced away from VMS by now...
>
> I must admit that I consider Ada on VMS as dead (along
> with PL/I).
>

Not to mention APL. :-)

bill

On 5/9/2022 8:17 PM, Bill Gunshannon wrote:
> On 5/9/22 19:10, Arne Vajhøj wrote:
>> On 5/9/2022 8:55 AM, Simon Clubley wrote:
>>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> My guess is that VMS is one of the most diverse platforms
>>>> when it comes to native languages usage.
>>>>
>>>> *nix and Win are almost entirely C and C++.
>>>>
>>>> Mainframe has a strong presence of Cobol and PL/I
>>>> and today probably some C and C++ and maybe a little
>>>> bit of Fortran..
>>>>
>>>> On VMS all the languages are really widely used: Pascal,
>>>> Basic, Cobol, Fortran, C. The only one I am not sure about
>>>> is C++.
>>>
>>> [Now it's my turn. :-)]
>>>
>>> Hey, you forgot about Ada!
>>>
>>> On a more serious note, so did VSI, probably because all the Ada users
>>> have probably been forced away from VMS by now...
>>
>> I must admit that I consider Ada on VMS as dead (along
>> with PL/I).
>
> Not to mention APL.  :-)

That I did not even consider.

BTW, is APL a compiler or an interpreter?

Arne

On 5/9/22 20:34, Arne Vajhøj wrote:
> On 5/9/2022 8:17 PM, Bill Gunshannon wrote:
>> On 5/9/22 19:10, Arne Vajhøj wrote:
>>> On 5/9/2022 8:55 AM, Simon Clubley wrote:
>>>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> My guess is that VMS is one of the most diverse platforms
>>>>> when it comes to native languages usage.
>>>>>
>>>>> *nix and Win are almost entirely C and C++.
>>>>>
>>>>> Mainframe has a strong presence of Cobol and PL/I
>>>>> and today probably some C and C++ and maybe a little
>>>>> bit of Fortran..
>>>>>
>>>>> On VMS all the languages are really widely used: Pascal,
>>>>> Basic, Cobol, Fortran, C. The only one I am not sure about
>>>>> is C++.
>>>>
>>>> [Now it's my turn. :-)]
>>>>
>>>> Hey, you forgot about Ada!
>>>>
>>>> On a more serious note, so did VSI, probably because all the Ada users
>>>> have probably been forced away from VMS by now...
>>>
>>> I must admit that I consider Ada on VMS as dead (along
>>> with PL/I).
>>
>> Not to mention APL.  :-)
>
> That I did not even consider.
>
> BTW, is APL a compiler or an interpreter?

I have never seen an APL Compiler. Doesn't mean one never existed, but
what Ken Iverson created was an interpreted language. I still have a
few versions of APL running around here. It's a fun language to play
with and got more use than some people like to think. We had a student
get an internship with a financial office in Scranton. They had a
complete, in-house developed Information System for their business
written entirely in APL. My student really liked it and got very good
at it. I also think Marist in Poughkeepsie still teaches it as one
of their primary educational languages. Not a surprise when you look
at where they are located. :-)

bill

On Mon, 2022-05-09 at 18:04 +0000, Simon Clubley wrote:

> The VMS support (such as it was in the FSF GCC version) would need to
> be added back in and fixed, x86-64 VMS added as a gcc target (which
> should be easier for x86-64 than it for VMS Alpha) into gcc itself
> and
> then support for a x86-64 VMS target added into the Ada runtime
> itself.
>
> Have fun. :-)

As another poster explained, the process for that will be considerably
simpler as VMS on x86_64 supports ELF and the all the heavy lifting for
generating x86_64 object code is already implemented.
--
Tactical Nuclear Kittens

Le 10/05/2022 à 01:10, Arne Vajhøj a écrit :
> On 5/9/2022 8:55 AM, Simon Clubley wrote:
>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> My guess is that VMS is one of the most diverse platforms
>>> when it comes to native languages usage.
>>>
>>> *nix and Win are almost entirely C and C++.
>>>
>>> Mainframe has a strong presence of Cobol and PL/I
>>> and today probably some C and C++ and maybe a little
>>> bit of Fortran..
>>>
>>> On VMS all the languages are really widely used: Pascal,
>>> Basic, Cobol, Fortran, C. The only one I am not sure about
>>> is C++.
>>
>> [Now it's my turn. :-)]
>>
>> Hey, you forgot about Ada!
>>
>> On a more serious note, so did VSI, probably because all the Ada users
>> have probably been forced away from VMS by now...
>
> I must admit that I consider Ada on VMS as dead (along
> with PL/I).
Except for who use it and who maintain it :)

Yes Adacore killed its support in 2015. Yes VSI cannot do anything until
today (no sufficient use cases).

But as "the king is dead, long live te king", "VMS is dead, long live
VMS",... who knows?
>
> Arne
>
>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Le 09/05/2022 à 20:04, Simon Clubley a écrit :
> On 2022-05-09, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
>>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> [Now it's my turn. :-)]
>>>
>>> Hey, you forgot about Ada!
>>>
>>> On a more serious note, so did VSI, probably because all the Ada
>>> users
>>> have probably been forced away from VMS by now...
>>
>> As soon as they make the compilers available, it should be
>> straightforward to port the GCC suite over to the x86_64 platform and
>> that'll include ADA if VSI doesn't port Ada over as well.
>>
>
> You have clearly never looked deeply into the gcc and binutils internals
> or you have way more knowledge about gcc internals than I do... :-)
>
> I looked at this for Alpha and I eventually gave up, because even with
> some VMS support still in gcc/binutils at that time, there appeared to
> be bits missing.
>
> I was able to compile gcc/binutils for VMS Alpha as a cross-compiler on
> a Linux host and was able to generate some C language Alpha binaries on
> Linux which ran ok on VMS Alpha but that was as far as I got.
>
> I was never able to get GNAT to build as a cross-compiler on Linux
> for VMS Alpha because I kept hitting an internal compiler error.
>
> IIRC, the VMS support was completely stripped from FSF binutils/gcc
> in a later version of those toolkits.
>
> The VMS support (such as it was in the FSF GCC version) would need to
> be added back in and fixed, x86-64 VMS added as a gcc target (which
> should be easier for x86-64 than it for VMS Alpha) into gcc itself and
> then support for a x86-64 VMS target added into the Ada runtime itself.
>
> Have fun. :-)
>
> Simon.
>
Agreed. A lot of things can be done upgrading the current
gcc/ada/itanium cross compiled chain (maintained and used here in
France). But it would be a nighmare doing the same for VMS/x86.

However, Adacore has a pure OpenSource project using LLVM
(https://github.com/AdaCore/gnat-llvm), and porting that to x86 will be
a lot more possible. Keep the secret: I'm justing begining this task.

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

On Tuesday, May 10, 2022 at 12:50:58 PM UTC+1, VMSgenerations working group wrote:
> Le 09/05/2022 à 20:04, Simon Clubley a écrit :
> > On 2022-05-09, Single Stage to Orbit <alex....@munted.eu> wrote:
> >> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
> >>> On 2022-05-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>>
> >>> [Now it's my turn. :-)]
> >>>
> >>> Hey, you forgot about Ada!
> >>>
> >>> On a more serious note, so did VSI, probably because all the Ada
> >>> users
> >>> have probably been forced away from VMS by now...
> >>
> >> As soon as they make the compilers available, it should be
> >> straightforward to port the GCC suite over to the x86_64 platform and
> >> that'll include ADA if VSI doesn't port Ada over as well.
> >>
> >
> > You have clearly never looked deeply into the gcc and binutils internals
> > or you have way more knowledge about gcc internals than I do... :-)
> >
> > I looked at this for Alpha and I eventually gave up, because even with
> > some VMS support still in gcc/binutils at that time, there appeared to
> > be bits missing.
> >
> > I was able to compile gcc/binutils for VMS Alpha as a cross-compiler on
> > a Linux host and was able to generate some C language Alpha binaries on
> > Linux which ran ok on VMS Alpha but that was as far as I got.
> >
> > I was never able to get GNAT to build as a cross-compiler on Linux
> > for VMS Alpha because I kept hitting an internal compiler error.
> >
> > IIRC, the VMS support was completely stripped from FSF binutils/gcc
> > in a later version of those toolkits.
> >
> > The VMS support (such as it was in the FSF GCC version) would need to
> > be added back in and fixed, x86-64 VMS added as a gcc target (which
> > should be easier for x86-64 than it for VMS Alpha) into gcc itself and
> > then support for a x86-64 VMS target added into the Ada runtime itself.
> >
> > Have fun. :-)
> >
> > Simon.
> >
> Agreed. A lot of things can be done upgrading the current
> gcc/ada/itanium cross compiled chain (maintained and used here in
> France). But it would be a nighmare doing the same for VMS/x86.
>
> However, Adacore has a pure OpenSource project using LLVM
> (https://github.com/AdaCore/gnat-llvm), and porting that to x86 will be
> a lot more possible. Keep the secret: I'm justing begining this task.
> --
> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
> https://www.avast.com/antivirus

that sounds like a good idea :-)

On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:

>
> On another note, I think it'll be interesting to get Rust running on
> this platform as well.
> --
> Tactical Nuclear Kittens

If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.

On 2022-05-10, plugh <jchimene@gmail.com> wrote:
> On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
>
>>
>> On another note, I think it'll be interesting to get Rust running on
>> this platform as well.
>> --
>> Tactical Nuclear Kittens
>
> If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.

Once again, as I and others have pointed out yet again just recently,
there is a VSI Alpha hobbyist program.

It's only the HPE program that is dead.

I'm running VSI Alpha VMS just fine on the VSI hobbyist program at
home (even if I have to run FreeAXP on an old Windows box to do so).

Simon.

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

On Tuesday, May 10, 2022 at 10:27:46 AM UTC-7, Simon Clubley wrote:
> On 2022-05-10, plugh <jchi...@gmail.com> wrote:
> > If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.
> Once again, as I and others have pointed out yet again just recently,
> there is a VSI Alpha hobbyist program.
>
> It's only the HPE program that is dead.
>
> I'm running VSI Alpha VMS just fine on the VSI hobbyist program at
> home (even if I have to run FreeAXP on an old Windows box to do so).
> Simon.

I appreciate the enthusiasm, but it's emulators all the way down.

I'm won't do this kind of work in that environment. Quoth the Mickey, "Hey kids, let's port Rust to the PDP/8!"

jec

-- Microsoft free since 2003

On 2022-05-10, plugh <jchimene@gmail.com> wrote:
> On Tuesday, May 10, 2022 at 10:27:46 AM UTC-7, Simon Clubley wrote:
>> On 2022-05-10, plugh <jchi...@gmail.com> wrote:
>> > If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.
>> Once again, as I and others have pointed out yet again just recently,
>> there is a VSI Alpha hobbyist program.
>>
>> It's only the HPE program that is dead.
>>
>> I'm running VSI Alpha VMS just fine on the VSI hobbyist program at
>> home (even if I have to run FreeAXP on an old Windows box to do so).
>> Simon.
>
> I appreciate the enthusiasm, but it's emulators all the way down.
>
> I'm won't do this kind of work in that environment. Quoth the Mickey, "Hey kids, let's port Rust to the PDP/8!"
>

Well, you would be famous if you pulled off the last sentence... :-)

Whether that's "good" or "bad" famous remains to be seen... :-)

Simon.

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

On Tuesday, May 10, 2022 at 10:39:42 AM UTC-7, Simon Clubley wrote:
> On 2022-05-10, plugh <jchi...@gmail.com> wrote:
> > On Tuesday, May 10, 2022 at 10:27:46 AM UTC-7, Simon Clubley wrote:
> >> On 2022-05-10, plugh <jchi...@gmail.com> wrote:
> >> > If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.
> >> Once again, as I and others have pointed out yet again just recently,
> >> there is a VSI Alpha hobbyist program.
> >>
> >> It's only the HPE program that is dead.
> >>
> >> I'm running VSI Alpha VMS just fine on the VSI hobbyist program at
> >> home (even if I have to run FreeAXP on an old Windows box to do so).
> >> Simon.
> >
> > I appreciate the enthusiasm, but it's emulators all the way down.
> >
> > I'm won't do this kind of work in that environment. Quoth the Mickey, "Hey kids, let's port Rust to the PDP/8!"
> >
> Well, you would be famous if you pulled off the last sentence... :-)
>
> Whether that's "good" or "bad" famous remains to be seen... :-)
> Simon.

Per aspera ad astra!

On 05/10/22 19:06, plugh wrote:
> On Tuesday, May 10, 2022 at 10:39:42 AM UTC-7, Simon Clubley wrote:
>> On 2022-05-10, plugh<jchi...@gmail.com> wrote:
>>> On Tuesday, May 10, 2022 at 10:27:46 AM UTC-7, Simon Clubley wrote:
>>>> On 2022-05-10, plugh<jchi...@gmail.com> wrote:
>>>>> If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.
>>>> Once again, as I and others have pointed out yet again just recently,
>>>> there is a VSI Alpha hobbyist program.
>>>>
>>>> It's only the HPE program that is dead.
>>>>
>>>> I'm running VSI Alpha VMS just fine on the VSI hobbyist program at
>>>> home (even if I have to run FreeAXP on an old Windows box to do so).
>>>> Simon.
>>>
>>> I appreciate the enthusiasm, but it's emulators all the way down.
>>>
>>> I'm won't do this kind of work in that environment. Quoth the Mickey, "Hey kids, let's port Rust to the PDP/8!"
>>>
>> Well, you would be famous if you pulled off the last sentence... :-)
>>
>> Whether that's "good" or "bad" famous remains to be seen... :-)
>> Simon.
>
> Per aspera ad astra!

Per Ardua ad Astra :-)...

On Tuesday, May 10, 2022 at 3:51:48 PM UTC-7, chris wrote:
> On 05/10/22 19:06, plugh wrote:
> > Per aspera ad astra!
> Per Ardua ad Astra :-)...

Yeah, I did say "storm the castle". I'll pay attention to that disabled checkbox. There used to be monitoring services for such things.

On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
> > On 2022-05-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >
> > [Now it's my turn. :-)]
> >
> > Hey, you forgot about Ada!
> >
> > On a more serious note, so did VSI, probably because all the Ada
> > users
> > have probably been forced away from VMS by now...
> As soon as they make the compilers available, it should be
> straightforward to port the GCC suite over to the x86_64 platform and
> that'll include ADA if VSI doesn't port Ada over as well.
>
> On another note, I think it'll be interesting to get Rust running on
> this platform as well.
> --
> Tactical Nuclear Kittens
As I understand the current memory model, the stack is 32 bits, the heap 64.. What impact if any will that have?

On 5/10/2022 7:05 PM, plugh wrote:
> On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
>> As soon as they make the compilers available, it should be
>> straightforward to port the GCC suite over to the x86_64 platform and
>> that'll include ADA if VSI doesn't port Ada over as well.
>>
>> On another note, I think it'll be interesting to get Rust running on
>> this platform as well.

> As I understand the current memory model, the stack is 32 bits, the heap 64. What impact if any will that have?

There is:
* a stack P1 that can be accessed via both 32 and 64 bit pointers
* a heap P0 that can be accessed via both 32 and 64 bit pointers
* a heap P2 that can be accessed only via 64 bit pointers

I don't think that P1 and P2 being "different" will cause
a problem, but I suspect they will get problems with the
32 and 64 bit pointers situation.

all 32 bit pointers : 1980ish
all 64 bit pointers : not able to use some VMS API's
both 32 and 64 bit pointers : compiler changes required

Arne

On Tuesday, May 10, 2022 at 4:48:52 PM UTC-7, Arne Vajhøj wrote:
> On 5/10/2022 7:05 PM, plugh wrote:
> > On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
> >> As soon as they make the compilers available, it should be
> >> straightforward to port the GCC suite over to the x86_64 platform and
> >> that'll include ADA if VSI doesn't port Ada over as well.
> >>
> >> On another note, I think it'll be interesting to get Rust running on
> >> this platform as well.
> > As I understand the current memory model, the stack is 32 bits, the heap 64. What impact if any will that have?
> There is:
> * a stack P1 that can be accessed via both 32 and 64 bit pointers
> * a heap P0 that can be accessed via both 32 and 64 bit pointers
> * a heap P2 that can be accessed only via 64 bit pointers
>
> I don't think that P1 and P2 being "different" will cause
> a problem, but I suspect they will get problems with the
> 32 and 64 bit pointers situation.
>
> all 32 bit pointers : 1980ish
> all 64 bit pointers : not able to use some VMS API's
> both 32 and 64 bit pointers : compiler changes required
>
> Arne

Don't quote me on this, but I'm not entirely sure compiler changes are required.
I was starting some research on this a few weeks ago, based on the design of the Rust Core Library
https://doc.rust-lang.org/core/
in which there's no heap allocation.

On 05/11/22 00:05, plugh wrote:
> On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
>> On Mon, 2022-05-09 at 12:55 +0000, Simon Clubley wrote:
>>> On 2022-05-08, Arne Vajhøj<ar...@vajhoej.dk> wrote:
>>>
>>> [Now it's my turn. :-)]
>>>
>>> Hey, you forgot about Ada!
>>>
>>> On a more serious note, so did VSI, probably because all the Ada
>>> users
>>> have probably been forced away from VMS by now...
>> As soon as they make the compilers available, it should be
>> straightforward to port the GCC suite over to the x86_64 platform and
>> that'll include ADA if VSI doesn't port Ada over as well.
>>
>> On another note, I think it'll be interesting to get Rust running on
>> this platform as well.
>> --
>> Tactical Nuclear Kittens
> As I understand the current memory model, the stack is 32 bits, the heap 64. What impact if any will that have?

Well, that gives you 4Gb stack space, which should be enough for most,
while ]the 64 bit heap, virtualised of course, should be enough for any
real world process. Depending on OS limits, of course...

Chri

On 5/10/2022 8:40 PM, chris wrote:
> On 05/11/22 00:05, plugh wrote:
>> As I understand the current memory model, the stack is 32 bits, the
>> heap 64. What impact if any will that have?
>
> Well, that gives you 4Gb stack space, which should be enough for most,
> while ]the 64 bit heap, virtualised of course, should be enough for any
> real world process. Depending on OS limits, of course...

P1 is only 1 GB. Or probably more relevant P1 + P0 is 2 GB as I assume
the stack could grow below 0x0000000040000000.

Arne

On 5/10/2022 8:39 PM, plugh wrote:
> On Tuesday, May 10, 2022 at 4:48:52 PM UTC-7, Arne Vajhøj wrote:
>> On 5/10/2022 7:05 PM, plugh wrote:
>>> On Monday, May 9, 2022 at 7:01:27 AM UTC-7, Single Stage to Orbit wrote:
>>>> As soon as they make the compilers available, it should be
>>>> straightforward to port the GCC suite over to the x86_64 platform and
>>>> that'll include ADA if VSI doesn't port Ada over as well.
>>>>
>>>> On another note, I think it'll be interesting to get Rust running on
>>>> this platform as well.
>>> As I understand the current memory model, the stack is 32 bits, the heap 64. What impact if any will that have?
>> There is:
>> * a stack P1 that can be accessed via both 32 and 64 bit pointers
>> * a heap P0 that can be accessed via both 32 and 64 bit pointers
>> * a heap P2 that can be accessed only via 64 bit pointers
>>
>> I don't think that P1 and P2 being "different" will cause
>> a problem, but I suspect they will get problems with the
>> 32 and 64 bit pointers situation.
>>
>> all 32 bit pointers : 1980ish
>> all 64 bit pointers : not able to use some VMS API's
>> both 32 and 64 bit pointers : compiler changes required
>
> Don't quote me on this, but I'm not entirely sure compiler changes are required.
> I was starting some research on this a few weeks ago, based on the design of the Rust Core Library
> https://doc.rust-lang.org/core/
> in which there's no heap allocation.

Rust use heap.

That library you link to apparently does not use heap.

Arne

On 5/10/2022 7:44 AM, VMSgenerations working group wrote:
> Le 10/05/2022 à 01:10, Arne Vajhøj a écrit :
>> On 5/9/2022 8:55 AM, Simon Clubley wrote:
>>> On 2022-05-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> My guess is that VMS is one of the most diverse platforms
>>>> when it comes to native languages usage.
>>>>
>>>> *nix and Win are almost entirely C and C++.
>>>>
>>>> Mainframe has a strong presence of Cobol and PL/I
>>>> and today probably some C and C++ and maybe a little
>>>> bit of Fortran..
>>>>
>>>> On VMS all the languages are really widely used: Pascal,
>>>> Basic, Cobol, Fortran, C. The only one I am not sure about
>>>> is C++.
>>>
>>> [Now it's my turn. :-)]
>>>
>>> Hey, you forgot about Ada!
>>>
>>> On a more serious note, so did VSI, probably because all the Ada users
>>> have probably been forced away from VMS by now...
>>
>> I must admit that I consider Ada on VMS as dead (along
>> with PL/I).
> Except for who use it and who maintain it :)
>
> Yes Adacore killed its support in 2015. Yes VSI cannot do anything until
> today (no sufficient use cases).

Yes.

But with all due respect for the great work you do then it is not
the same as VSI or ACT.

Arne

On Tuesday, May 10, 2022 at 5:47:17 PM UTC-7, Arne Vajhøj wrote:
> On 5/10/2022 8:39 PM, plugh wrote:
> Rust use^W CAN heap.
>
> That library you link to apparently does not use heap.

Correct. It's for embedded systems.

And
..
..
..

experimentation.....

--
It's over there...