Le 11/05/2022 à 02:50, Arne Vajhøj a écrit :
> 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.
>
HP and VSI didn't do anything on Ada Itanium. All was done by Adacore.
And I have just rebuilt the work done by Adacore from sources on FSF.

Quite same thing taking the work done by Adacore on gnat-llvm and
rebuilting it on VMS/x86. Only "quite" because there will be changes to
adapt with VMS {llvm,c++,cmake} uses. On gnat-gcc the adaptation to VMS
was already done (but it is horrible cross-compiled ): ).

My question: if everything used on VMS has to be "the same as VSI", do
you think the ecosystem has a chance to survive? And, about Adacore, no,
no, a lot of things are done using, rebuilding gnat-ada (not just me),
and there are "not the same as Adacore".

By the way, Ada did survive because of the mix business plan between
Open Source and proprietary options. Because Adacore helped to create a
community who "does things". Samething with VMS: it is because we can
use a lot of things issued from Open Source that VMS can survive, and
this things "are not VSI".

But you are right, the project is a little bit too bold. What to do?

> Arne
>
>
>

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

On 5/11/2022 2:12 PM, Gérard Calliet wrote:
> HP and VSI didn't do anything on Ada Itanium. All was done by Adacore.
> And I have just rebuilt the work done by Adacore from sources on FSF.
>
> Quite same thing taking the work done by Adacore on gnat-llvm and
> rebuilting it on VMS/x86. Only "quite" because there will be changes to
> adapt with VMS {llvm,c++,cmake} uses. On gnat-gcc the adaptation to VMS
> was already done (but it is horrible cross-compiled ): ).

I know it is a big project.

I dabbled a little bit into GCC on VMS around version
1.somethingaround40.

> My question: if everything used on VMS has to be "the same as VSI",

I don't think everything has to be same as VSI.

But for compilers specifically I think they should generate code
compatible with VSI compilers.

> do
> you think the ecosystem has a chance to survive?

I hope so.

VSI got a hobbyist program and an ISV program.

That should hopefully help both open source on VMS and
commercial third party products on VMS.

> By the way, Ada did survive because of the mix business plan between
> Open Source and proprietary options. Because Adacore helped to create a
> community who "does things". Samething with VMS: it is because we can
> use a lot of things issued from Open Source that VMS can survive, and
> this things "are not VSI".

VSI like most other commercial software companies (IBM, Oracle, MS,
SAP etc.) are using open source.

There is also a small VMS open source community, but to be
frank - it is way too small - we need more people maintaining
old ports and creating new ports.

And

On 5/9/2022 9:19 PM, Bill Gunshannon wrote:
> On 5/9/22 20:34, Arne Vajhøj wrote:
>> On 5/9/2022 8:17 PM, Bill Gunshannon wrote:
>>> 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.  :-)

You can get APL almost anywhere.

https://github.com/dzaima/APL should be a pretty good APL
implementation and only requires Java 8+ to run.

Arne

Le 11/05/2022 à 20:32, Arne Vajhøj a écrit :
>
> There is also a small VMS open source community, but to be
> frank - it is way too small - we need more people maintaining
> old ports and creating new ports
indeed

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

On 2022-05-11, Gérard Calliet <gerard.calliet@pia-sofer.fr> wrote:
> HP and VSI didn't do anything on Ada Itanium. All was done by Adacore.
> And I have just rebuilt the work done by Adacore from sources on FSF.
>

And you were fortunate in that the state of Itanium VMS in the FSF
sources appeared to be in a far better state than those for Alpha VMS
appeared to be.

Unfortunately, there's no such thing as an Itanium full system emulator
or that's what I would have been running in my efforts instead of Alpha.

> Quite same thing taking the work done by Adacore on gnat-llvm and
> rebuilting it on VMS/x86. Only "quite" because there will be changes to
> adapt with VMS {llvm,c++,cmake} uses. On gnat-gcc the adaptation to VMS
> was already done (but it is horrible cross-compiled ): ).
>

The cross-compiled part of this isn't really a problem for me because
I am well used to that development model for embedded work.

I would have had no problem with using Linux as a development host for
VMS work and then only using VMS to run the final binaries after they
had been generated on a Linux box.

One of the advantages of that approach would have been the ability to
take full advantage of the richer development environment that exists
on Linux when compared to VMS.

Simon.

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

Le 12/05/2022 à 14:47, Simon Clubley a écrit :
> On 2022-05-11, Gérard Calliet <gerard.calliet@pia-sofer.fr> wrote:
>> HP and VSI didn't do anything on Ada Itanium. All was done by Adacore.
>> And I have just rebuilt the work done by Adacore from sources on FSF.
>>
>
> And you were fortunate in that the state of Itanium VMS in the FSF
> sources appeared to be in a far better state than those for Alpha VMS
> appeared to be.
I think it's because Adacore had to maintain Ada on Itanium. Not on
Alpha where there were Dec Ada, as you know.

Unfortunitly, they stopped the support in 2015, and didn't publish for
VMS after that. So we don't have anything good on versions 5 and newer.
It is the time gcc became built on c++.

I'm sure Adacore did a lot of things for VMS and gcc version 5, but,
because of the stop of support, stopped the publication. I heard they
said it was a nightmare speaking with HP ingineering at that time.

A lot more bold project I have in the future, if business makes me live,
is upgrading my gnat-ada build for itanium, building gcc-c++, and
upgrading with it. Because I'm sure there will be Itanium around at
least for five or ten years, and they deserve a good Ada.
>
> Unfortunately, there's no such thing as an Itanium full system emulator
> or that's what I would have been running in my efforts instead of Alpha.
>
>> Quite same thing taking the work done by Adacore on gnat-llvm and
>> rebuilting it on VMS/x86. Only "quite" because there will be changes to
>> adapt with VMS {llvm,c++,cmake} uses. On gnat-gcc the adaptation to VMS
>> was already done (but it is horrible cross-compiled ): ).
>>
>
> The cross-compiled part of this isn't really a problem for me because
> I am well used to that development model for embedded work.
I understand. But with VMS purism, it is a little bad using no complete
native environment.
>
> I would have had no problem with using Linux as a development host for
> VMS work and then only using VMS to run the final binaries after they
> had been generated on a Linux box
>
> One of the advantages of that approach would have been the ability to
> take full advantage of the richer development environment that exists
> on Linux when compared to VMS.
Agreed. And perhaps you know we'll be able to do a lot more of
cross-work with VMS/x86 . VSI themselves play like that to build
somethings and try in the first phases of development on x86. As I
understood something John Reagan had explained.

It is for me the actual workshop, beginning use (trying) of gnat-llvm on
VMS/x86. Absolutly exiting.
>
> Simon.
>

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

On Thursday, May 5, 2022 at 10:37:42 PM UTC+1, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.
> Regards, Jan-Erik.
>
>
>
> After analyzing customer feedback, VMS Software Inc. has made the decision
> to move hypervisor support on OpenVMS V9.2 to the top of our priority list.
> We plan to extend support for the following: VMWare, KVM and Hyper-V. Kevin
> Shaw, the CEO of VMS Software, Inc. and Stephen Nelson, VP Engineering will
> present this update of the VSI x86 rollout strategy at the webinar on May
> 11th. [Registration at https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also means
> that bare metal support will be delayed – although eventually the DL380 and
> several other server models are planned to be supported. The first limited
> production release of OpenVMS on x86, V9.2, is scheduled for July 2022.

VSI Webinar 11 May x86 port update
now on YouTube https://youtu.be/eH8gAjoOkXI

On 05/05/2022 23:37, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.
> Regards, Jan-Erik.
>
>
>
> After analyzing customer feedback, VMS Software Inc. has made the decision to move hypervisor support on OpenVMS V9.2 to the top of our priority list. We plan to extend support for the following: VMWare, KVM and Hyper-V. Kevin Shaw, the CEO of VMS Software, Inc. and Stephen Nelson, VP Engineering will present this update of the VSI x86 rollout strategy at the webinar on May 11th. [Registration at https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86 hardware, which is a priority for many customers. However, this also means that bare metal support will be delayed – although eventually the DL380 and several other server models are planned to be supported. The first limited production release of OpenVMS on x86, V9.2, is scheduled for July 2022.

I wonder if "support" means developing some paravirtualisation drivers, aka vmtools.

If OpenVMS VMs cannot be shut down properly by the hypervisor but requires timed or manual work on the OS, it will be difficult to sell this to customers used to hypervisor-based operation.

On 05/11/22 01:44, Arne Vajhøj wrote:
> 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
>

Those numbers were theoretical, but X86-64 will have hardware memory
management capability for more than that. I'm using proliant G8 series
for work, as an economical sweet spot from a cost pov, but they are
often advertised with 16 to 64Gb typically, so one has to ask, where
is the limitation ?, In the OS, or what ?...

Chris

On 2022-05-14 22:28:43 +0000, chris said:

> On 05/11/22 01:44, Arne Vajhøj wrote:
>>
>> P1 is only 1 GB. Or probably more relevant P1 + P0 is 2 GB as I assume
>> the stack could grow below 0x0000000040000000.
>>
>
> Those numbers were theoretical, but X86-64 will have hardware memory
> management capability for more than that. I'm using proliant G8 series
> for work, as an economical sweet spot from a cost pov, but they are
> often advertised with 16 to 64Gb typically, so one has to ask, where is
> the limitation ?, In the OS, or what ?...

Apologies on any bit-width errors latent in the following.

This posting differentiates virtual addressing from physical
addressing, and largely ignores discussions around physical addressing
including about 48-bit physical addressing limit on many recent x86-64
boxes, and the 5-level page tables (providing 57 bits, physical)
available on certain current x86-64 processors.

OpenVMS uses what amounts to segmented virtual addressing, and the
OpenVMS virtual address space design ties directly back to VAX. This
at least through OpenVMS I64, and haven't checked OpenVMS x86-64 here.

VAX had P0 user space where ~all VAX user apps and user data resides,
00000000 to 3FFFFFFF, P1 from 40000000 to 7FFFFFFF for the control
region and CLI and baggage, and the remainder for S0 system space, and
later S1 for more system space with VAX Extended Virtual Addressing.
I'll here ignore VAX Extended Physical Addressing.

Each of these P0, P1, S0, and S2 spaces are 30 bits of virtual addressing.

Alpha uses 64-bit virtual and always has, and preserves the existing
VAX 32-bit design with P0 and P1 at the lowest addresses
(00000000.00000000 to 00000000.7FFFFFFF), with S0 and S1 at the highest
(FFFFFFFF.80000000 to FFFFFFFF.FFFFFFFF, and adds P2 and S2 into the
great huge gap between those two ranges. OpenVMS Alpha V7.0 opened up
user access for P2 and S2 addressing.

As part of allowing existing 32-bit applications to continue to operate
on OpenVMS, app developers working on new apps now get to deal with
what is located where, and which API calls to use for addressing.

Apps use 64-bit pointers, but OpenVMS and its preference for upward
compatibility means existing and new apps are an aggregation of older
32- and newer 64-bit calls where needed, and all eventually
sign-extended to 64-bit virtual addresses at run-time by the processor.

As an implementation detail, all of the virtual address bits and all of
the physical address bits are not (yet) fully implemented, but we're
getting closer. Alpha provided 43 bits virtual. x86-64 now does 57-bits
physical. Etc.

This OpenVMS segmented virtual address space design works spectacularly
for those folks that are dependent on 32-bit apps and libraries and
their related APIs, but it tends to be a confusing morass for new work,
particularly for anybody familiar with 64-bit flat virtual addressing
and not having to deal with this stuff. (For those of a certain age and
experience, this is not as ugly as TKB by any stretch, but it's still
ugly.)

OpenVMS has been incrementally allowing hunks of stuff to migrate into
P2 and S2 space, though the documentation here tends to be scattershot,
and you have to find and use the necessary switches to get your code
and data out of the default P0 address range.

OpenVMS is the only operating system I'm aware of that chose this
hybrid addressing path; of both 32-bit and 64-bit APIs mixed within the
same executable images. Most other platforms decided to allow 32-bit
and 64-bit apps and processes to coexist in parallel. But not
co-resident within an app at run-time. This transition usually with a
decade or more to allow apps to be migrated to 64-bit APIs for those
platforms that have decided to deprecate and remove the older and
problematic 32-bit APIs. As an example, macOS 10.15 "Catalina" removed
32-bit app and API support, and completed the migration started back
around 10.5 "Leopard"; a ~decade ago.

I'm here ignoring the existence of so-called multi-architecture or
so-called fat binaries, which can provide 32- and 64-bit code and code
for multiple architectures within the file containing the binary. The
equivalent of the image activator picks the appropriate executable code
and maps it into virtual memory and transfers control to the
appropriate contents from those architectures available within the
binary. For this particular posting, I'm referring to the run-time
address space and run-time APIs in use. Not to multi-architecture
binaries.

Microsoft Windows further runs parallel 32- and 64-bit software
distributions, in addition to 32- and 64-bit apps.

For the long-archived 64-bit manual with some background on the topic:
http://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467ptoc.htm

There was a long discussion of this addressing topic here in
comp.os.vms newsgroup a while back, too. Which showed that a whole lot
of folks haven't yet written apps for 64-bit address space. Which is
fine. Where things get confusing is with which APIs (32-bit or 64-bit)
work where, whether API calls or descriptors or itemlists or otherwise.
And compilers and other factors, for that matter. BASIC has not yet
added support for 64-bit.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/14/2022 6:28 PM, chris wrote:
> On 05/11/22 01:44, Arne Vajhøj wrote:
>> 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.
>
> Those numbers were theoretical,

I believe they are very actual. VAX, Alpha, Itanium, x86-64.

> but X86-64 will have hardware memory
> management capability for more than that.

Alpha, Itanium and x86-64 are 64 bit machines.

But that does not change P0 and P1 space in VMS.

> I'm using proliant G8 series
> for work, as an economical sweet spot from a cost pov, but they are
> often advertised with 16 to 64Gb typically, so one has to ask, where
> is the limitation ?, In the OS, or what ?...

VMS design. Due to VAX compatibility decisions made 30 years ago.

Arne

On 5/14/2022 7:32 PM, Stephen Hoffman wrote:
> VAX had P0 user space where ~all VAX user apps and user data resides,
> 00000000 to 3FFFFFFF, P1 from 40000000 to 7FFFFFFF for the control
> region and CLI and baggage, and the remainder for S0 system space, and
> later S1 for more system space with VAX Extended Virtual Addressing.
> I'll here ignore VAX Extended Physical Addressing.
>
> Each of these P0, P1, S0, and S2 spaces are 30 bits of virtual addressing.
>
> Alpha uses 64-bit virtual and always has, and preserves the existing VAX
> 32-bit design with P0 and P1 at the lowest addresses (00000000.00000000
> to 00000000.7FFFFFFF), with S0 and S1 at the highest (FFFFFFFF.80000000
> to FFFFFFFF.FFFFFFFF, and adds P2 and S2 into the great huge gap between
> those two ranges. OpenVMS Alpha V7.0 opened up user access for P2 and S2
> addressing.
>
> As part of allowing existing 32-bit applications to continue to operate
> on OpenVMS, app developers working on new apps now get to deal with what
> is located where, and which API calls to use for addressing.
>
> Apps use 64-bit pointers, but OpenVMS and its preference for upward
> compatibility means existing and new apps are an aggregation of older
> 32- and newer 64-bit calls where needed, and all eventually
> sign-extended to 64-bit virtual addresses at run-time by the processor.

> This OpenVMS segmented virtual address space design works spectacularly
> for those folks that are dependent on 32-bit apps and libraries and
> their related APIs, but it tends to be a confusing morass for new work,
> particularly for anybody familiar with 64-bit flat virtual addressing
> and not having to deal with this stuff. (For those of a certain age and
> experience, this is not as ugly as TKB by any stretch, but it's still
> ugly.)
>
> OpenVMS has been incrementally allowing hunks of stuff to migrate into
> P2 and S2 space, though the documentation here tends to be scattershot,
> and you have to find and use the necessary switches to get your code and
> data out of the default P0 address range.
>
> OpenVMS is the only operating system I'm aware of that chose this hybrid
> addressing path; of both 32-bit and 64-bit APIs mixed within the same
> executable images. Most other platforms decided to allow 32-bit and
> 64-bit apps and processes to coexist in parallel. But not co-resident
> within an app at run-time. This transition usually with a decade or more
> to allow apps to be migrated to 64-bit APIs for those platforms that
> have decided to deprecate and remove the older and problematic 32-bit
> APIs.  As an example, macOS 10.15 "Catalina" removed 32-bit app and API
> support, and completed the migration started back around 10.5 "Leopard";
> a ~decade ago.

> Microsoft Windows further runs parallel 32- and 64-bit software
> distributions, in addition to 32- and 64-bit apps.

I think it is muddling the matters when people talk about 32 vs 64
bit applications and even worse 32 vs 64 bit mode.

VMS does not have any of that. Unlike Windows, Linux, macOS etc..

VMS has 32 and 64 bit pointers. And the granularity is not
by program but by pointer. You can have a short program with 4 pointers
where 2 are 64 bit and 2 are 32 bit.

Some compilers only generate 32 bit pointers. And even if the compiler
supports both then unless explicit messing around is done pointers
are either all 32 bit or all 64 bit. But messing around is certainly
possible.

All done for compatibility reasons.

And potentially a PITA. Having data in P2 space requiring
a 64 bit pointer to access and an API that only accept
32 bit pointers is not so fun.

Arne

On 05/15/22 14:25, Arne Vajhøj wrote:
> On 5/14/2022 7:32 PM, Stephen Hoffman wrote:
>> VAX had P0 user space where ~all VAX user apps and user data resides,
>> 00000000 to 3FFFFFFF, P1 from 40000000 to 7FFFFFFF for the control
>> region and CLI and baggage, and the remainder for S0 system space, and
>> later S1 for more system space with VAX Extended Virtual Addressing.
>> I'll here ignore VAX Extended Physical Addressing.
>>
>> Each of these P0, P1, S0, and S2 spaces are 30 bits of virtual
>> addressing.
>>
>> Alpha uses 64-bit virtual and always has, and preserves the existing
>> VAX 32-bit design with P0 and P1 at the lowest addresses
>> (00000000.00000000 to 00000000.7FFFFFFF), with S0 and S1 at the
>> highest (FFFFFFFF.80000000 to FFFFFFFF.FFFFFFFF, and adds P2 and S2
>> into the great huge gap between those two ranges. OpenVMS Alpha V7.0
>> opened up user access for P2 and S2 addressing.
>>
>> As part of allowing existing 32-bit applications to continue to
>> operate on OpenVMS, app developers working on new apps now get to deal
>> with what is located where, and which API calls to use for addressing.
>>
>> Apps use 64-bit pointers, but OpenVMS and its preference for upward
>> compatibility means existing and new apps are an aggregation of older
>> 32- and newer 64-bit calls where needed, and all eventually
>> sign-extended to 64-bit virtual addresses at run-time by the processor.
>
>> This OpenVMS segmented virtual address space design works
>> spectacularly for those folks that are dependent on 32-bit apps and
>> libraries and their related APIs, but it tends to be a confusing
>> morass for new work, particularly for anybody familiar with 64-bit
>> flat virtual addressing and not having to deal with this stuff. (For
>> those of a certain age and experience, this is not as ugly as TKB by
>> any stretch, but it's still ugly.)
>>
>> OpenVMS has been incrementally allowing hunks of stuff to migrate into
>> P2 and S2 space, though the documentation here tends to be
>> scattershot, and you have to find and use the necessary switches to
>> get your code and data out of the default P0 address range.
>>
>> OpenVMS is the only operating system I'm aware of that chose this
>> hybrid addressing path; of both 32-bit and 64-bit APIs mixed within
>> the same executable images. Most other platforms decided to allow
>> 32-bit and 64-bit apps and processes to coexist in parallel. But not
>> co-resident within an app at run-time. This transition usually with a
>> decade or more to allow apps to be migrated to 64-bit APIs for those
>> platforms that have decided to deprecate and remove the older and
>> problematic 32-bit APIs. As an example, macOS 10.15 "Catalina"
>> removed 32-bit app and API support, and completed the migration
>> started back around 10.5 "Leopard"; a ~decade ago.
>
>> Microsoft Windows further runs parallel 32- and 64-bit software
>> distributions, in addition to 32- and 64-bit apps.
>
> I think it is muddling the matters when people talk about 32 vs 64
> bit applications and even worse 32 vs 64 bit mode.
>
> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>
> VMS has 32 and 64 bit pointers. And the granularity is not
> by program but by pointer. You can have a short program with 4 pointers
> where 2 are 64 bit and 2 are 32 bit.
>
> Some compilers only generate 32 bit pointers. And even if the compiler
> supports both then unless explicit messing around is done pointers
> are either all 32 bit or all 64 bit. But messing around is certainly
> possible.
>
> All done for compatibility reasons.
>
> And potentially a PITA. Having data in P2 space requiring
> a 64 bit pointer to access and an API that only accept
> 32 bit pointers is not so fun.
>
> Arne
>

The question still remains, what are the limits to memory size
that can be seen at boot time and fully used by VMS ?...

Chris

On 05/15/22 00:32, Stephen Hoffman wrote:
> On 2022-05-14 22:28:43 +0000, chris said:
>
>> On 05/11/22 01:44, Arne Vajhøj wrote:
>>>
>>> P1 is only 1 GB. Or probably more relevant P1 + P0 is 2 GB as I
>>> assume the stack could grow below 0x0000000040000000.
>>>
>>
>> Those numbers were theoretical, but X86-64 will have hardware memory
>> management capability for more than that. I'm using proliant G8 series
>> for work, as an economical sweet spot from a cost pov, but they are
>> often advertised with 16 to 64Gb typically, so one has to ask, where
>> is the limitation ?, In the OS, or what ?...
>
> Apologies on any bit-width errors latent in the following.
>
> This posting differentiates virtual addressing from physical addressing,
> and largely ignores discussions around physical addressing including
> about 48-bit physical addressing limit on many recent x86-64 boxes, and
> the 5-level page tables (providing 57 bits, physical) available on
> certain current x86-64 processors.
>
> OpenVMS uses what amounts to segmented virtual addressing, and the
> OpenVMS virtual address space design ties directly back to VAX. This at
> least through OpenVMS I64, and haven't checked OpenVMS x86-64 here.
>
> VAX had P0 user space where ~all VAX user apps and user data resides,
> 00000000 to 3FFFFFFF, P1 from 40000000 to 7FFFFFFF for the control
> region and CLI and baggage, and the remainder for S0 system space, and
> later S1 for more system space with VAX Extended Virtual Addressing.
> I'll here ignore VAX Extended Physical Addressing.
>
> Each of these P0, P1, S0, and S2 spaces are 30 bits of virtual addressing.
>
> Alpha uses 64-bit virtual and always has, and preserves the existing VAX
> 32-bit design with P0 and P1 at the lowest addresses (00000000.00000000
> to 00000000.7FFFFFFF), with S0 and S1 at the highest (FFFFFFFF.80000000
> to FFFFFFFF.FFFFFFFF, and adds P2 and S2 into the great huge gap between
> those two ranges. OpenVMS Alpha V7.0 opened up user access for P2 and S2
> addressing.
>
> As part of allowing existing 32-bit applications to continue to operate
> on OpenVMS, app developers working on new apps now get to deal with what
> is located where, and which API calls to use for addressing.
>
> Apps use 64-bit pointers, but OpenVMS and its preference for upward
> compatibility means existing and new apps are an aggregation of older
> 32- and newer 64-bit calls where needed, and all eventually
> sign-extended to 64-bit virtual addresses at run-time by the processor.
>
> As an implementation detail, all of the virtual address bits and all of
> the physical address bits are not (yet) fully implemented, but we're
> getting closer. Alpha provided 43 bits virtual. x86-64 now does 57-bits
> physical. Etc.
>
> This OpenVMS segmented virtual address space design works spectacularly
> for those folks that are dependent on 32-bit apps and libraries and
> their related APIs, but it tends to be a confusing morass for new work,
> particularly for anybody familiar with 64-bit flat virtual addressing
> and not having to deal with this stuff. (For those of a certain age and
> experience, this is not as ugly as TKB by any stretch, but it's still
> ugly.)
>
> OpenVMS has been incrementally allowing hunks of stuff to migrate into
> P2 and S2 space, though the documentation here tends to be scattershot,
> and you have to find and use the necessary switches to get your code and
> data out of the default P0 address range.
>
> OpenVMS is the only operating system I'm aware of that chose this hybrid
> addressing path; of both 32-bit and 64-bit APIs mixed within the same
> executable images. Most other platforms decided to allow 32-bit and
> 64-bit apps and processes to coexist in parallel. But not co-resident
> within an app at run-time. This transition usually with a decade or more
> to allow apps to be migrated to 64-bit APIs for those platforms that
> have decided to deprecate and remove the older and problematic 32-bit
> APIs. As an example, macOS 10.15 "Catalina" removed 32-bit app and API
> support, and completed the migration started back around 10.5 "Leopard";
> a ~decade ago.
>
> I'm here ignoring the existence of so-called multi-architecture or
> so-called fat binaries, which can provide 32- and 64-bit code and code
> for multiple architectures within the file containing the binary. The
> equivalent of the image activator picks the appropriate executable code
> and maps it into virtual memory and transfers control to the appropriate
> contents from those architectures available within the binary. For this
> particular posting, I'm referring to the run-time address space and
> run-time APIs in use. Not to multi-architecture binaries.
>
> Microsoft Windows further runs parallel 32- and 64-bit software
> distributions, in addition to 32- and 64-bit apps.
>
> For the long-archived 64-bit manual with some background on the topic:
> http://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467ptoc.htm
>
> There was a long discussion of this addressing topic here in comp.os.vms
> newsgroup a while back, too. Which showed that a whole lot of folks
> haven't yet written apps for 64-bit address space. Which is fine. Where
> things get confusing is with which APIs (32-bit or 64-bit) work where,
> whether API calls or descriptors or itemlists or otherwise. And
> compilers and other factors, for that matter. BASIC has not yet added
> support for 64-bit.
>
>

Thanks for the extensive reply, though still not quite sure what the
limits of usable memory are. Last VNS here was 5.4 / Vax and istr, the
overall limit was 4Gb, split nto 2 x 2 GB sections...

Chris

On 5/15/2022 1:59 PM, chris wrote:
> On 05/15/22 14:25, Arne Vajhøj wrote:
>> I think it is muddling the matters when people talk about 32 vs 64
>> bit applications and even worse 32 vs 64 bit mode.
>>
>> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>>
>> VMS has 32 and 64 bit pointers. And the granularity is not
>> by program but by pointer. You can have a short program with 4 pointers
>> where 2 are 64 bit and 2 are 32 bit.
>>
>> Some compilers only generate 32 bit pointers. And even if the compiler
>> supports both then unless explicit messing around is done pointers
>> are either all 32 bit or all 64 bit. But messing around is certainly
>> possible.
>>
>> All done for compatibility reasons.
>>
>> And potentially a PITA. Having data in P2 space requiring
>> a 64 bit pointer to access and an API that only accept
>> 32 bit pointers is not so fun.
>
> The question still remains, what are the limits to memory size
> that can be seen at boot time and fully used by VMS ?...

The above is all about virtual addresses aka what is
seen by a process.

Physical memory in a system is a completely different
issue.

VAX had a hard architectural limit that was reached.

I believe that on Alpha, Itanium and x86-64 it is a matter
about what the hardware implementation support, because
the architectural limit is bloody huge.

I believe the x86-64 architectural limit currently is
48 bit aka 256 TB or 52 bit aka 4 EB. But you can't buy
a board and RAM modules that can supply that.

Arne

In article <628153e3$0$694$14726298@news.sunsite.dk>, arne@vajhoej.dk
(Arne Vajh�j) wrote:

> I believe that on Alpha, Itanium and x86-64 it is a matter
> about what the hardware implementation support, because
> the architectural limit is bloody huge.

That's right, if a little understated.

> I believe the x86-64 architectural limit currently is
> 48 bit aka 256 TB or 52 bit aka 4 EB. But you can't buy
> a board and RAM modules that can supply that.

Currently, 48-bit physical addressing is the limit. The current page
table format allows for 52-bit, which gives you 4 petabytes.

ARM64 likewise goes up to 48-bit physical addressing at present, as does
RISC-V. I can't rapidly figure out the limit on IBM Z; the terminology is
weird.

John

On 2022-05-15 19:26:22 +0000, Arne Vajhj said:

> I believe the x86-64 architectural limit currently is
> 48 bit aka 256 TB or 52 bit aka 4 EB. But you can't buy
> a board and RAM modules that can supply that.

From the post:

> This posting differentiates virtual addressing from physical
> addressing, and largely ignores discussions around physical addressing
> including about 48-bit physical addressing limit on many recent x86-64
> boxes, and the 5-level page tables (providing 57 bits, physical)
> available on certain current x86-64 processors.

48, and 57 bits.

48 is near filled.

HPE Superdome Flex presently supports 32 sockets and 48 terabytes.

That'd be a stretch for OpenVMS SMP support, and the rest of the system.

Any servers approaching the five-level 57-bit physical memory
availability, not so much.

I don't expect to meet a fully-populated Superdome Flex running OpenVMS
anytime soon.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/15/2022 3:55 PM, John Dallman wrote:
> In article <628153e3$0$694$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> I believe that on Alpha, Itanium and x86-64 it is a matter
>> about what the hardware implementation support, because
>> the architectural limit is bloody huge.
>
> That's right, if a little understated.
>
>> I believe the x86-64 architectural limit currently is
>> 48 bit aka 256 TB or 52 bit aka 4 EB. But you can't buy
>> a board and RAM modules that can supply that.
>
> Currently, 48-bit physical addressing is the limit. The current page
> table format allows for 52-bit, which gives you 4 petabytes.

Ooops.

4 PB not 4 EB.

Thanks.

Arne

On 5/15/2022 4:16 PM, Stephen Hoffman wrote:
> On 2022-05-15 19:26:22 +0000, Arne Vajhj said:
>> I believe the x86-64 architectural limit currently is
>> 48 bit aka 256 TB or 52 bit aka 4 EB. But you can't buy
>> a board and RAM modules that can supply that.
>
> From the post:
>
>> This posting differentiates virtual addressing from physical
>> addressing, and largely ignores discussions around physical addressing
>> including about 48-bit physical addressing limit on many recent x86-64
>> boxes, and the 5-level page tables (providing 57 bits, physical)
>> available on certain current x86-64 processors.
>
> 48, and 57 bits.
>
> 48 is near filled.
>
> HPE Superdome Flex presently supports 32 sockets and 48 terabytes.
>
> That'd be a stretch for OpenVMS SMP support, and the rest of the system.
>
> Any servers approaching the five-level 57-bit physical memory
> availability, not so much.

This thing:

https://en.wikipedia.org/wiki/Intel_5-level_paging

57 bit = 128 PB

But other sources talk about 52 bit and 4 PB (not 4 EB). But that seems
to be 4 level with PAE (not to be confused with 32 bit PAE).

Maybe we should just call it "a lot".

:-)

> I don't expect to meet a fully-populated Superdome Flex running OpenVMS
> anytime soon.

No demand.

Arne

On 2022-05-15 13:25:19 +0000, Arne Vajhj said:

> I think it is muddling the matters when people talk about 32 vs 64 bit
> applications and even worse 32 vs 64 bit mode.

> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>
> VMS has 32 and 64 bit pointers. And the granularity is not by program
> but by pointer. You can have a short program with 4 pointers where 2
> are 64 bit and 2 are 32 bit.
>
> Some compilers only generate 32 bit pointers. And even if the compiler
> supports both then unless explicit messing around is done pointers are
> either all 32 bit or all 64 bit. But messing around is certainly
> possible.
>
> All done for compatibility reasons.
>
> And potentially a PITA.

The word "potentially" is doing a whole lot of work, there.

Once y'all use a flat 64-bit address space and APIs, the existing and
hybrid memory management compatibility-focused design starts to smell
vaguely of TKB.

The lack of a clear migration path to flat 64-bit addressing and 64-bit
apps and tools, and 64-bit APIs was and remains among the most
troubling parts.

Apps going from 32-bit to 64-bit is not going to happen quickly, and
not without a migration path.

Conversely, supporting both 32- and 64-bit apps and APIs only adds
complexity on OpenVMS itself, and on end-users.

--
Pure Personal Opinion | HoffmanLabs LLC

On 05/15/22 21:32, Stephen Hoffman wrote:
> On 2022-05-15 13:25:19 +0000, Arne Vajhj said:
>
>> I think it is muddling the matters when people talk about 32 vs 64 bit
>> applications and even worse 32 vs 64 bit mode.
>
>> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>>
>> VMS has 32 and 64 bit pointers. And the granularity is not by program
>> but by pointer. You can have a short program with 4 pointers where 2
>> are 64 bit and 2 are 32 bit.
>>
>> Some compilers only generate 32 bit pointers. And even if the compiler
>> supports both then unless explicit messing around is done pointers are
>> either all 32 bit or all 64 bit. But messing around is certainly
>> possible.
>>
>> All done for compatibility reasons.
>>
>> And potentially a PITA.
>
> The word "potentially" is doing a whole lot of work, there.
>
> Once y'all use a flat 64-bit address space and APIs, the existing and
> hybrid memory management compatibility-focused design starts to smell
> vaguely of TKB.
>
> The lack of a clear migration path to flat 64-bit addressing and 64-bit
> apps and tools, and 64-bit APIs was and remains among the most troubling
> parts.

I think that sort of info is what I was driving at. So used to flat
address spaces these days, it's difficult to imagine anything else, but
it does look like VMS has plenty of space to play with, even if
segmented in some way...

Chris

>
> Apps going from 32-bit to 64-bit is not going to happen quickly, and not
> without a migration path.
>
> Conversely, supporting both 32- and 64-bit apps and APIs only adds
> complexity on OpenVMS itself, and on end-users.
>
>

On 5/15/2022 4:25 PM, Arne Vajhøj wrote:
> On 5/15/2022 4:16 PM, Stephen Hoffman wrote:
>> I don't expect to meet a fully-populated Superdome Flex running
>> OpenVMS anytime soon.
>
> No demand.

But a fun hypothetical question:

Let us assume:
* VSI got VMS running on Superdome Flex
* no VMS customers had any specific hardware requirements
* all VMS customers were happy with a PaaS (time sharing)
solution

(not the case, but let us for fun assume it was)

How many Superdome Flex servers with 32s896c 48 TB would
it take to run all VMS production systems in existence?

Arne

On 5/15/2022 7:15 PM, chris wrote:
> On 05/15/22 21:32, Stephen Hoffman wrote:
>> On 2022-05-15 13:25:19 +0000, Arne Vajhj said:
>>
>>> I think it is muddling the matters when people talk about 32 vs 64 bit
>>> applications and even worse 32 vs 64 bit mode.
>>
>>> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>>>
>>> VMS has 32 and 64 bit pointers. And the granularity is not by program
>>> but by pointer. You can have a short program with 4 pointers where 2
>>> are 64 bit and 2 are 32 bit.
>>>
>>> Some compilers only generate 32 bit pointers. And even if the compiler
>>> supports both then unless explicit messing around is done pointers are
>>> either all 32 bit or all 64 bit. But messing around is certainly
>>> possible.
>>>
>>> All done for compatibility reasons.
>>>
>>> And potentially a PITA.
>>
>> The word "potentially" is doing a whole lot of work, there.
>>
>> Once y'all use a flat 64-bit address space and APIs, the existing and
>> hybrid memory management compatibility-focused design starts to smell
>> vaguely of TKB.
>>
>> The lack of a clear migration path to flat 64-bit addressing and 64-bit
>> apps and tools, and 64-bit APIs was and remains among the most troubling
>> parts.
>
> I think that sort of info is what I was driving at. So used to flat
> address spaces these days, it's difficult to imagine anything else, but
> it does look like VMS has plenty of space to play with, even if
> segmented in some way...

I don't like the term segmented as opposed to flat to
describe the VMS memory either.

If you use a language that supports 64 bit pointers
and you enable it then your program is accessing
a 64 bit flat address space.

But there are a gazillion API's that are expecting
a 32 bit pointer and if you want to call such an API
then your data better be addressable with a 32 bit
pointer or the data will need to be copied first.

Arne

On 2022-05-15 23:15:00 +0000, chris said:

> On 05/15/22 21:32, Stephen Hoffman wrote:
>>
>> Once y'all use a flat 64-bit address space and APIs, the existing and
>> hybrid memory management compatibility-focused design starts to smell
>> vaguely of TKB.
>>
>> The lack of a clear migration path to flat 64-bit addressing and 64-bit
>> apps and tools, and 64-bit APIs was and remains among the most
>> troubling parts.
>
> I think that sort of info is what I was driving at. So used to flat
> address spaces these days, it's difficult to imagine anything else, but
> it does look like VMS has plenty of space to play with, even if
> segmented in some way...

Far too often, OpenVMS has 32-bit virtual addressing "to play with".

As I've mentioned in other threads: go try this stuff.

Write a complete 64-bit app.

Use a mix of some of the available languages.

Try using BASIC as part of your test app, for instance.

Find all the knobs and switches required to get (mostly) there.

This whole area is an accretion of old code, old apps, old APIs, and
old documentation; a compromise of compatibility.

The current hybrid 32-/64-bit memory management is a remarkable design.

Just not a very forward-looking one.

--
Pure Personal Opinion | HoffmanLabs LLC

On 05/16/22 00:23, Arne Vajhøj wrote:
> On 5/15/2022 7:15 PM, chris wrote:
>> On 05/15/22 21:32, Stephen Hoffman wrote:
>>> On 2022-05-15 13:25:19 +0000, Arne Vajhj said:
>>>
>>>> I think it is muddling the matters when people talk about 32 vs 64 bit
>>>> applications and even worse 32 vs 64 bit mode.
>>>
>>>> VMS does not have any of that. Unlike Windows, Linux, macOS etc..
>>>>
>>>> VMS has 32 and 64 bit pointers. And the granularity is not by program
>>>> but by pointer. You can have a short program with 4 pointers where 2
>>>> are 64 bit and 2 are 32 bit.
>>>>
>>>> Some compilers only generate 32 bit pointers. And even if the compiler
>>>> supports both then unless explicit messing around is done pointers are
>>>> either all 32 bit or all 64 bit. But messing around is certainly
>>>> possible.
>>>>
>>>> All done for compatibility reasons.
>>>>
>>>> And potentially a PITA.
>>>
>>> The word "potentially" is doing a whole lot of work, there.
>>>
>>> Once y'all use a flat 64-bit address space and APIs, the existing and
>>> hybrid memory management compatibility-focused design starts to smell
>>> vaguely of TKB.
>>>
>>> The lack of a clear migration path to flat 64-bit addressing and 64-bit
>>> apps and tools, and 64-bit APIs was and remains among the most troubling
>>> parts.
>>
>> I think that sort of info is what I was driving at. So used to flat
>> address spaces these days, it's difficult to imagine anything else, but
>> it does look like VMS has plenty of space to play with, even if
>> segmented in some way...
>
> I don't like the term segmented as opposed to flat to
> describe the VMS memory either.

I can see why there is a need for 32 bit addressing for legacy reasons.
If app code is 32 bit, it implies that VMS has some internal 32
bit space reserved within the 64 bit total for that, probably
via run time libraries which either output 64 bit addresses, or have
some way of informing vms to put the code into a certain 64 bit space
and starting address...

Chris

>
> If you use a language that supports 64 bit pointers
> and you enable it then your program is accessing
> a 64 bit flat address space.
>
> But there are a gazillion API's that are expecting
> a 32 bit pointer and if you want to call such an API
> then your data better be addressable with a 32 bit
> pointer or the data will need to be copied first.
>
> Arne
>
>