Just got a mail with this:

"VMS Software, Inc. announces the E9.2 Field Test

A new field test version of OpenVMS for x86, E9.2, is released. Features
include TCP/IP Services version X6.0-15, OpenSSH version V8.8-1D, new and
updated layered products, and new and updated open source products. E9.2
adds cluster common disk support for VMWare ESXi OpenVMS guests running
on the same host machine.

The new version is already available on the Service Portal for all field
test participants. The field test is open to all VSI customers and partners
with current support contracts; apply here.

E9.2 is the pre-release of the first OpenVMS x86 production release,
version 9.2. VMS Software, Inc. thanks the participants of the 9.1 field
test as well as the development and QA teams that have made this release
possible."

Den 2022-04-07 kl. 22:18, skrev Jan-Erik Söderholm:
> Just got a mail with this:
>
> "VMS Software, Inc. announces the E9.2 Field Test
>
> A new field test version of OpenVMS for x86, E9.2, is released. Features
> include TCP/IP Services version X6.0-15, OpenSSH version V8.8-1D, new and
> updated layered products, and new and updated open source products. E9.2
> adds cluster common disk support for VMWare ESXi OpenVMS guests running
> on the same host machine.
>
> The new version is already available on the Service Portal for all field
> test participants. The field test is open to all VSI customers and partners
> with current support contracts; apply here.
>
> E9.2 is the pre-release of the first OpenVMS x86 production release,
> version 9.2. VMS Software, Inc. thanks the participants of the 9.1 field
> test as well as the development and QA teams that have made this release
> possible."
>

Well, also on their web site: https://vmssoftware.com/about/openvmsv9-1/.

In article <t2nhb0$ub5$2@dont-email.me>, jan-erik.soderholm@telia.com
(Jan-Erik S�derholm) wrote:

> Well, also on their web site:
> https://vmssoftware.com/about/openvmsv9-1/.

No native compilers yet.

John

On 4/7/2022 5:13 PM, John Dallman wrote:
> In article <t2nhb0$ub5$2@dont-email.me>, jan-erik.soderholm@telia.com
> (Jan-Erik Söderholm) wrote:
>
>> Well, also on their web site:
>> https://vmssoftware.com/about/openvmsv9-1/.
>
> No native compilers yet.
>
> John

Or CLP availability. But it's getting closer.

--
John H. Reinhardt

fredag 8 april 2022 kl. 00:14:26 UTC+2 skrev John Dallman:
> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
> (Jan-Erik Söderholm) wrote:
>
> > Well, also on their web site:
> > https://vmssoftware.com/about/openvmsv9-1/.
> No native compilers yet.
>
> John

Yes, very disappointing, waiting for the C++ compiler...

Den 2022-04-08 kl. 11:15, skrev Peter Skoog:
> fredag 8 april 2022 kl. 00:14:26 UTC+2 skrev John Dallman:
>> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>
>>> Well, also on their web site:
>>> https://vmssoftware.com/about/openvmsv9-1/.
>> No native compilers yet.
>>
>> John
>
> Yes, very disappointing, waiting for the C++ compiler...

The still current roadmap says:

April
OpenVMS V9.2 (Limited Production Release)

Additional hypervisors – OpenVMS as a guest for Microsoft Hyper-V
Additional Layered Products and Open Source Applications
New Security Feature – Entropy Engine
Native compilers with LLVM backend code generator:
BLISS, XMACRO, C++ (Phase 1)

I haven't seen any comment from VSI regarding that difference.
Or if they *are* included but just left out from the rel notes.

On 08/04/2022 01:18, John H. Reinhardt wrote:
> On 4/7/2022 5:13 PM, John Dallman wrote:
>> In article <t2nhb0$ub5$2@dont-email.me>, jan-erik.soderholm@telia.com
>> (Jan-Erik Söderholm) wrote:
>>
>>> Well, also on their web site:
>>> https://vmssoftware.com/about/openvmsv9-1/.
>>
>> No native compilers yet.
>>
>> John
>
> Or CLP availability. But it's getting closer.
>

In anticipation I got the system checker, and noticed they reject my
Ryzen CPU.

Will it be Intel only?

--
Chris

On Friday, April 8, 2022 at 7:24:12 AM UTC-4, Chris Townley wrote:
> On 08/04/2022 01:18, John H. Reinhardt wrote:
> > On 4/7/2022 5:13 PM, John Dallman wrote:
> >> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
> >> (Jan-Erik Söderholm) wrote:
> >>
> >>> Well, also on their web site:
> >>> https://vmssoftware.com/about/openvmsv9-1/.
> >>
> >> No native compilers yet.
> >>
> >> John
> >
> > Or CLP availability. But it's getting closer.
> >
> In anticipation I got the system checker, and noticed they reject my
> Ryzen CPU.
>
> Will it be Intel only?
>
> --
> Chris
I would recommend using a hypervisor and a virtual machine. That is what we
all are using. I use Virtual Box but many others use VMware.

On 08/04/2022 13:55, John Reagan wrote:
> On Friday, April 8, 2022 at 7:24:12 AM UTC-4, Chris Townley wrote:
>> On 08/04/2022 01:18, John H. Reinhardt wrote:
>>> On 4/7/2022 5:13 PM, John Dallman wrote:
>>>> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
>>>> (Jan-Erik Söderholm) wrote:
>>>>
>>>>> Well, also on their web site:
>>>>> https://vmssoftware.com/about/openvmsv9-1/.
>>>>
>>>> No native compilers yet.
>>>>
>>>> John
>>>
>>> Or CLP availability. But it's getting closer.
>>>
>> In anticipation I got the system checker, and noticed they reject my
>> Ryzen CPU.
>>
>> Will it be Intel only?
>>
>> --
>> Chris
> I would recommend using a hypervisor and a virtual machine. That is what we
> all are using. I use Virtual Box but many others use VMware.

Probably better, but will that run with AND, or is it still Intel only?

--
Chris

On Thursday, April 7, 2022 at 6:14:26 PM UTC-4, John Dallman wrote:
> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
> (Jan-Erik Söderholm) wrote:
>
> > Well, also on their web site:
> > https://vmssoftware.com/about/openvmsv9-1/.
> No native compilers yet.
>
> John
I missed the deadline to get the native Macro into the kit. I've already checked it
in and it will be in the final V9.2 kit. It seems to be functionally identical to the
cross Macro compiler

Here's an update on native compiler work-in-progress:
- BLISS compiler mostly works but has a bug due to being miscompiled by the cross BLISS compiler
(GLOBAL BINDs in BLISS are a PITA to describe to LLVM)
- C compiler sorta works but there is something screwy in the precompiler (either an uninitialized
variable or perhaps another victim of a bad cross compiler - triaging as I type this)
- C++ (clang) will be starting limited testing with one customer soon and then expanding to more
as we get more things cleaned up
- Others (COBOL, Fortran, Pascal) are just waiting for us to find the cycles
- BASIC is still waiting on an enhancement to our G2L converter. BASIC's MAP statement uses
COMMON blocks in a "unique" way that the converter was not prepared for. And the way OpenVMS
implements common blocks is different than the presentation you see on UNIX/Linux systems.
(I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives in UNIX)

On 4/8/2022 9:07 AM, John Reagan wrote:
> On Thursday, April 7, 2022 at 6:14:26 PM UTC-4, John Dallman wrote:
>> In article <t2nhb0$ub5$2...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>
>>> Well, also on their web site:
>>> https://vmssoftware.com/about/openvmsv9-1/.
>> No native compilers yet.

> I missed the deadline to get the native Macro into the kit. I've already checked it
> in and it will be in the final V9.2 kit. It seems to be functionally identical to the
> cross Macro compiler
>
> Here's an update on native compiler work-in-progress:
> - BLISS compiler mostly works but has a bug due to being miscompiled by the cross BLISS compiler
> (GLOBAL BINDs in BLISS are a PITA to describe to LLVM)
> - C compiler sorta works but there is something screwy in the precompiler (either an uninitialized
> variable or perhaps another victim of a bad cross compiler - triaging as I type this)
> - C++ (clang) will be starting limited testing with one customer soon and then expanding to more
> as we get more things cleaned up
> - Others (COBOL, Fortran, Pascal) are just waiting for us to find the cycles
> - BASIC is still waiting on an enhancement to our G2L converter. BASIC's MAP statement uses
> COMMON blocks in a "unique" way that the converter was not prepared for. And the way OpenVMS
> implements common blocks is different than the presentation you see on UNIX/Linux systems.
> (I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives in UNIX)

Thanks for the update.

Do you have an idea about which native compilers will be in final 9.2
release and what compilers will show up in 9.2 later in 2022?

I think it is fair to say that there is a significant interest in
this topic.

I also understand resource limitations and I strongly suspect that
this is a case where adding more people to late project will make
the project even more late in classic mythical man month fashion
(and https://en.wikipedia.org/wiki/Multiplicity_(film) is just a movie).

Arne

On Friday, April 8, 2022 at 9:16:12 AM UTC-4, Arne Vajhøj wrote:

>
> Do you have an idea about which native compilers will be in final 9.2
> release and what compilers will show up in 9.2 later in 2022?
>
While the cross-compilers have shipped in sync with OS releases, you should
consider native compilers to be layered products just like they are on Alpha
and Itanium. So in that sense, other than Macro, V9.2 doesn't contain any
bundled compilers. The roadmap says that in the V9.2 timeframe, there will
be Macro, BLISS, C++. I suspect that only a few of you care about BLISS but
it is a good exerciser of the native G2L converter and newer LLVM backend.
C is in the "next" section of the roadmap, but we're doing that now since that
is the next best choice.

And yes, I quote Fred Brooks (who is still alive at the age of 90) often when
others suggest adding new people into the tail end of a project. In addition,
our traditional compiler test suites aren't well suited the test setup we have.
We've been waiting on a more functional network and clustering just like
everybody else. There is a native version of DTM but not all of my test harnesses
are DTM based.

On 4/8/2022 9:35 AM, John Reagan wrote:
> On Friday, April 8, 2022 at 9:16:12 AM UTC-4, Arne Vajhøj wrote:
>> Do you have an idea about which native compilers will be in final 9.2
>> release and what compilers will show up in 9.2 later in 2022?
>>
> While the cross-compilers have shipped in sync with OS releases, you should
> consider native compilers to be layered products just like they are on Alpha
> and Itanium. So in that sense, other than Macro, V9.2 doesn't contain any
> bundled compilers.

s/in/be available at/w

> The roadmap says that in the V9.2 timeframe, there will
> be Macro, BLISS, C++. I suspect that only a few of you care about BLISS but
> it is a good exerciser of the native G2L converter and newer LLVM backend.
> C is in the "next" section of the roadmap, but we're doing that now since that
> is the next best choice.

Hmmm.

So we will be deep into 2023 before all native compilers are available?

Arne

In article <t2p60q$huu$1@dont-email.me>, news@cct-net.co.uk (Chris
Townley) wrote:

> In anticipation I got the system checker, and noticed they reject
> my Ryzen CPU.
>
> Will it be Intel only?

The release notes for E9.2 say:

> 1.4. Non-Intel Processors Are Not Currently Supported
>
> VSI OpenVMS x86-64 E9.2 runs on Intel processors only.
>
> Support for AMD processors is planned for a future version
> of VSI OpenVMS x86-64.

I don't know if any of the hypervisors will fake an Intel CPU on an AMD,
but I doubt it.

John

In article <67c8d5ac-1296-4c7a-9d73-93436be96a8fn@googlegroups.com>,
xyzzy1959@gmail.com (John Reagan) wrote:

> - C++ (clang) will be starting limited testing with one customer
> soon and then expanding to more as we get more things cleaned up

Good-oh.

> - C compiler sorta works but there is something screwy in the
> precompiler (either an uninitialized variable or perhaps another
> victim of a bad cross compiler - triaging as I type this)

That's the VSI C compiler that supports C90? Presumably compilers for C99
or C11 will need to be Clang-based?

A silly idea: once the whole LLVM system is running properly on x86-64,
it would presumably be possible to make cross-compilers for its languages
that compiled for IA64.

Thanks,

John

On Friday, April 8, 2022 at 9:42:39 AM UTC-4, Arne Vajhøj wrote:

>
> So we will be deep into 2023 before all native compilers are available?
>
> Arne

I hope not. I'd be in big trouble if it takes that long. My SWAG is for this CY.

On Friday, April 8, 2022 at 11:04:58 AM UTC-4, John Dallman wrote:
> In article <67c8d5ac-1296-4c7a...@googlegroups.com>,
> xyzz...@gmail.com (John Reagan) wrote:
>
> > - C++ (clang) will be starting limited testing with one customer
> > soon and then expanding to more as we get more things cleaned up
> Good-oh.
> > - C compiler sorta works but there is something screwy in the
> > precompiler (either an uninitialized variable or perhaps another
> > victim of a bad cross compiler - triaging as I type this)
> That's the VSI C compiler that supports C90? Presumably compilers for C99
> or C11 will need to be Clang-based?
>
The VSI C compiler is exactly the same frontend as on Alpha, Itanium, and the
cross-compiler. It supports C99 (and has for a long time). It is the RTL that lags
with C99 support but that should be available as an ECO today.

> A silly idea: once the whole LLVM system is running properly on x86-64,
> it would presumably be possible to make cross-compilers for its languages
> that compiled for IA64.
You mean make a x86-hosted cross-compiler for another LLVM target, like ARM
or Power? Uh, I guess, but you'd need the language libraries or system libraries on
such a target. Just compiling a BASIC program on x86 for an ARM target doesn't
do you much good by itself. It wouldn't come close to linking.

On Friday, April 8, 2022 at 11:04:58 AM UTC-4, John Dallman wrote:

> That's the VSI C compiler that supports C90? Presumably compilers for C99
> or C11 will need to be Clang-based?
>
Forgot to answer your C11 question. You should be able to invoke the underlying
clang frontend with a .c file instead of an .cxx file and have it be a C compiler. I've
tried that a few times and it seemed to work. However, we have not yet done work
on the headers or RTL to add anything needed by C11. (shudders thinking about threads
and atomic memory ordering). We're certainly not going to support that at the first
ship.

On 2022-04-08, John Dallman <jgd@cix.co.uk> wrote:
> In article <t2p60q$huu$1@dont-email.me>, news@cct-net.co.uk (Chris
> Townley) wrote:
>
>> In anticipation I got the system checker, and noticed they reject
>> my Ryzen CPU.
>>
>> Will it be Intel only?
>
> The release notes for E9.2 say:
>
>> 1.4. Non-Intel Processors Are Not Currently Supported
>>
>> VSI OpenVMS x86-64 E9.2 runs on Intel processors only.
>>
>> Support for AMD processors is planned for a future version
>> of VSI OpenVMS x86-64.
>
> I don't know if any of the hypervisors will fake an Intel CPU on an AMD,
> but I doubt it.
>

One of the reasons is probably the PCID stuff to support the extra
VMS modes, so if it was emulated somehow, you might end up with poor
performance anyway.

I know AMD are planning to introduce PCID support on their processors,
but I don't know what the current status of that is.

BTW, talking about performance, I wonder how far away we are from
being able to run the same test programs on VMS and Linux on the
same hardware and then compare the performance differences.

Simon.

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

On 4/8/2022 2:00 PM, Simon Clubley wrote:
> BTW, talking about performance, I wonder how far away we are from
> being able to run the same test programs on VMS and Linux on the
> same hardware and then compare the performance differences.

It is probably more relevant to compare VMS/x86-64 to VMS/Itanium
than to Linux/x86-64 for now. The next few years are going to more
migration from Alpha and Itanium than competing with Linux.

But to me the logical expectation is that CPU wise C code compiled
with LLVM backend on VMS will run very similar to the same code
compiled with LLVM backend on Linux. The different frontends should
not impact performance much. IO wise we all know that VMS is
not the fastest.

Arne

In article <f1e6d661-9de5-47eb-8405-f22682e72c53n@googlegroups.com>,
xyzzy1959@gmail.com (John Reagan) wrote:

> The VSI C compiler is exactly the same frontend as on Alpha, Itanium,
> and the cross-compiler. It supports C99 (and has for a long time).

Sorry, mistyped C99.

> You mean make a x86-hosted cross-compiler for another LLVM target,
> like ARM or Power?

So, sillier than that, and purely a joke: revive the Itanium LLVM target
and cross-build IA64 VMS programs on x86-64 VMS.

John

In article <91545be0-a2b5-41a6-b91f-9e7aeaf2b63an@googlegroups.com>,
xyzzy1959@gmail.com (John Reagan) wrote:

> Forgot to answer your C11 question. You should be able to invoke the
> underlying clang frontend with a .c file instead of an .cxx file and
> have it be a C compiler. I've tried that a few times and it seemed
> to work. However, we have not yet done work on the headers or RTL
> to add anything needed by C11. (shudders thinking about threads
> and atomic memory ordering). We're certainly not going to support
> that at the first ship.

Thanks, makes sense.

John

On 4/8/22 1:11 PM, Arne Vajhøj wrote:
> On 4/8/2022 2:00 PM, Simon Clubley wrote:
>> BTW, talking about performance, I wonder how far away we are from
>> being able to run the same test programs on VMS and Linux on the
>> same hardware and then compare the performance differences.

Probably still quite a ways off.

> It is probably more relevant to compare VMS/x86-64 to VMS/Itanium
> than to Linux/x86-64 for now. The next few years are going to more
> migration from Alpha and Itanium than competing with Linux.
>
> But to me the logical expectation is that CPU wise C code compiled
> with LLVM backend on VMS will run very similar to the same code
> compiled with LLVM backend on Linux. The different frontends should
> not impact performance much. IO wise we all know that VMS is
> not the fastest.

There have been statements that the cross build environment has
optimizations turned off. Is that still true? If so, both the OS
itself and user-written programs just aren't going to be directly
comparable to code compiled with those optimizations turned on. Even if
it's not true, there may be other considerations. It isn't clear to me
what impact the GEM-to-LLVM converter will have (if any) on the
optimizations that LLVM normally does. And things like link-time
optimization probably won't be available on VMS anytime soon but are in
other LLVM-based toolchains.[1]

Meanwhile, the business-level optimizer has squeezed VCI 2.0 and a
couple of different file system replacements off of the roadmap to make
room for the port to x86. Without those projects, applications on VMS
that do disk I/O or network I/O seem unlikely to be
performance-comparable to similar applications on other systems. The
only good news here is SSIO, which should make one category of file I/O
more performant since it allows avoiding unpleasant workarounds such as
closing and reopening a file on every I/O.

[1] https://www.llvm.org/docs/LinkTimeOptimization.html