Discussion:
VMS Software Releases Roadmap Updates
(too old to reply)
Ian Miller
2021-09-27 15:26:53 UTC
Permalink
An updated roadmap has been announced https://vmssoftware.com/about/news/2021-09-27-roadmap-update/

Some details on when the native compilers are going to arrive.

I wonder why Availability Manager V3.2-1 is so late.
Arne Vajhøj
2021-09-27 15:35:57 UTC
Permalink
Post by Ian Miller
An updated roadmap has been announced https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.

It seems like native compilers are coming out rather slow:

April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal

And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.

Arne
Arne Vajhøj
2021-09-27 16:05:54 UTC
Permalink
Post by Arne Vajhøj
Post by Ian Miller
An updated roadmap has been announced
https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
Not that I know how to get them done faster.

Stuffing John Reagan in a copy machine and make
5 copies will probably not work ...

:-)
Post by Arne Vajhøj
And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.
A shame because it impacts more than just pure Java:
- other JVM languages: Kotlin, Scala, Groovy etc.
- various products that run in JVM but can be used also
by non-JVM applications like ActiveMQ

Arne
Simon Clubley
2021-09-27 17:47:56 UTC
Permalink
Post by Arne Vajhøj
Stuffing John Reagan in a copy machine and make
5 copies will probably not work ...
:-)
:-)

You could build a cross-dimensional portal and invite copies of
him from different dimensions to come visit this one. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-09-27 16:23:54 UTC
Permalink
Post by Arne Vajhøj
Post by Ian Miller
An updated roadmap has been announced
https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.
Arne
Looks as if x86 will be useless, for me, for more than a year ..

Ah, well, I have that RX2660 to ruin my hearing, what more could one ask
for?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-27 17:04:41 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Ian Miller
An updated roadmap has been announced
https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.

*IF* you are willing to cross compile your Basic code on Itanium.

But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.

Arne
Robert A. Brooks
2021-09-27 17:34:17 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.

John will step in and correct me if I'm wrong . . .
--
-- Rob
Arne Vajhøj
2021-09-27 17:49:44 UTC
Permalink
Post by Robert A. Brooks
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.
John will step in and correct me if I'm wrong . . .
My guess is that very few VMS people are concerned about
compiler optimization.

The typical VMS application ran fine on Alpha 20 years
ago, it could not get CPU usage over 10% on Itanium 10 years
ago and it will run fine on x86-64 /OPT or /NOOPT.

If you have a product owner for compilers setting the
priorities then I think they should be:
1) send the right signal to all PHB's that VMS x86-64 is real
2) option for 100% compatibility with VMS Itanium and Alpha
3) no bugs
4) relevant enhancements including compliance with newer standards
5) performance

Optimization is good long term and may be needed to attract new
VMS customers. But for the next 24 months I do not see it as
critical.

Arne
Dave Froble
2021-09-27 17:57:26 UTC
Permalink
Post by Robert A. Brooks
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.
John will step in and correct me if I'm wrong . . .
He does that well, doesn't he?

Robert, I'm confused. Easily done.

On Alpha, Basic code is compiled with optimization. It is suggested to
turn off optimization when debugging. If one does not, trying to use
the debugger is interesting, to say the least.

Or, perhaps, it will not use optimization on x86?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-09-29 02:58:26 UTC
Permalink
Post by Robert A. Brooks
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.
John will step in and correct me if I'm wrong . . .
--
-- Rob
BASIC runs through the GEM optimizer on Alpha and Itanium just like any other compiler. Of course when you have an RTL every 20 instructions or so, there is only so much code motions that the compiler can perform.
Dave Froble
2021-09-29 03:40:47 UTC
Permalink
Post by John Reagan
Post by Robert A. Brooks
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.
John will step in and correct me if I'm wrong . . .
--
-- Rob
BASIC runs through the GEM optimizer on Alpha and Itanium just like any other compiler. Of course when you have an RTL every 20 instructions or so, there is only so much code motions that the compiler can perform.
So in practice, that makes Robert correct ???

:-)

I've never asked, is there a cross compiler for Basic?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-09-29 04:26:12 UTC
Permalink
Post by Dave Froble
Post by Robert A. Brooks
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
For Basic, which is not optimizable, the quality of the generated code
likely will not change from cross-compiled to natively compiled.
John will step in and correct me if I'm wrong . . .
--
-- Rob
BASIC runs through the GEM optimizer on Alpha and Itanium just like any other compiler. Of course when you have an RTL every 20 instructions or so, there is only so much code motions that the compiler can perform.
So in practice, that makes Robert correct ???
:-)
I've never asked, is there a cross compiler for Basic?
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
The BASIC cross-compiler is close to being released (perhaps within a month). The interface between the BASIC compiler and RTL is complicated. The BASIC frontend relied on GEM behaviors that we didn't know about. It has taken a while to get things ironed out.
Simon Clubley
2021-09-27 17:53:59 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
It was originally due out at the end of this year however.

In addition, I suspect that some people will need to see at least one
point release after that before they will consider running it in
production.
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.

It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-09-27 18:08:42 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
Relevant point.

There are a significant number of VMS customers still on Alpha.

But what does a low end Itanium with VMS license cost
from IslandCo?

5000??

(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)

Way too much for a hobbyist but should not be a problem for
commercial context.

Arne
Bill Gunshannon
2021-09-28 00:26:00 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
Relevant point.
There are a significant number of VMS customers still on Alpha.
But what does a low end Itanium with VMS license cost
from IslandCo?
5000??
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.

bill
Arne Vajhøj
2021-09-28 01:00:55 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
Relevant point.
There are a significant number of VMS customers still on Alpha.
But what does a low end Itanium with VMS license cost
from IslandCo?
5000??
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.
Maybe. But it would be pretty silly.

You have one or more inhouse applications on VMS
or you are an ISV selling a VMS application. You spend
between a few hundreds of thousands per yer up to
a few dozens of millions per year on that/those
applications. And you are not willing to spend
5000 to get 6-15 months head start on porting
to the new VMS platform.

That does not make any sense. There can be other
valid reasons not to do it. Like no need/demand
or wanting to see the production platform before
committing to port. But the money in itself should
not be an issue.

Arne
Dave Froble
2021-09-28 01:42:22 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
Relevant point.
There are a significant number of VMS customers still on Alpha.
But what does a low end Itanium with VMS license cost
from IslandCo?
5000??
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.
Maybe. But it would be pretty silly.
You have one or more inhouse applications on VMS
or you are an ISV selling a VMS application. You spend
between a few hundreds of thousands per yer up to
a few dozens of millions per year on that/those
applications. And you are not willing to spend
5000 to get 6-15 months head start on porting
to the new VMS platform.
That does not make any sense. There can be other
valid reasons not to do it. Like no need/demand
or wanting to see the production platform before
committing to port. But the money in itself should
not be an issue.
Arne
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-09-28 17:36:43 UTC
Permalink
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-09-28 18:11:48 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not. But I knew that much of such development would not be
on the target platform. No or few such tools on the dedicated HW.

General purpose computers are another world, and, I'm old fashioned, and
don't get out much.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-09-28 18:42:07 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not. But I knew that much of such development would not be
on the target platform. No or few such tools on the dedicated HW.
General purpose computers are another world, and, I'm old fashioned, and
don't get out much.
Didn't someone once say that NonStop uses a cross compiler development
model ?

I know that IBM has various tools for doing z/OS development on a PC.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-09-28 18:48:19 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not. But I knew that much of such development would not be
on the target platform. No or few such tools on the dedicated HW.
General purpose computers are another world, and, I'm old fashioned, and
don't get out much.
Didn't someone once say that NonStop uses a cross compiler development
model ?
I know that IBM has various tools for doing z/OS development on a PC.
A lot now, but not really a comparison. The development system is
cheap and common, not expensive, rare and obsolete. The users in
all likelihood already have one. Even in the case of new entries
they already have them.

bill
John Reagan
2021-09-29 02:57:27 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not. But I knew that much of such development would not be
on the target platform. No or few such tools on the dedicated HW.
General purpose computers are another world, and, I'm old fashioned, and
don't get out much.
Didn't someone once say that NonStop uses a cross compiler development
model ?
I know that IBM has various tools for doing z/OS development on a PC.
Simon.
--
Walking destinations on a map are further away than they appear.
NonStop provides both native compilers on Guardian and OSS and cross-compilers hosted on Windows.
Jan-Erik Söderholm
2021-09-28 18:53:57 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
I don't think it was the money.  Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not.
Note that, what Simon calls "embedded" today, it just the same kind
of development that was once done for VAXELN. You wrote, compiled
and linked your application on one system and then deployed on
another system. Your application booted directly without any
underlaying operating system.

That these two happend to have the same basic architecture (VAX)
is of no real importance.

Today, if you build apps for PIC, AVR or similar embedded platforms,
you write, compile and link on one system (usually a Windows laptop)
and deploy ("flash") on the target processors.

The differnce from IA64/x86 is that you compile on IA64 and link
on x86 (if I understand correctly, maybe it is both compile and
link on IA64?).

For what it matters, I could very well live with a cross-compile
environment for OpenVMS based on a Windows platform. That would
probably give much better code editing tools, anyway.
I do not know if that ever was an option for VSI, of course...

And yes, IA64 might look as a not so good choice today, but when
the x86 port begun, it was probably more reasonable.

And, as Arne has mentioned several time, this is just a temporary
solution that will go away during next year.
Post by Dave Froble
But I knew that much of such development would not be on
the target platform.  No or few such tools on the dedicated HW.
General purpose computers are another world, and, I'm old fashioned, and
don't get out much.
Dave Froble
2021-09-28 20:40:02 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not.
Note that, what Simon calls "embedded" today, it just the same kind
of development that was once done for VAXELN. You wrote, compiled
and linked your application on one system and then deployed on
another system. Your application booted directly without any
underlaying operating system.
Well, if one wants to look at it from this perspective, we don't do any
development on customer systems. Yes, we compile and link there, but,
we don't really have to do so. Executables could be moved from out
development environment to customer systems.

Not such an alien concept.

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-09-28 22:44:02 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Simon Clubley
I don't think it was the money.  Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not.
Note that, what Simon calls "embedded" today, it just the same kind
of development that was once done for VAXELN. You wrote, compiled
and linked your application on one system and then deployed on
another system. Your application booted directly without any
underlaying operating system.
Well, if one wants to look at it from this perspective, we don't do any
development on customer systems.  Yes, we compile and link there,...
Why on earth do you force your customers to pay for compilers?
Post by Dave Froble
but, we don't really have to do so.  Executables could be moved from
out development environment to customer systems.
Really?
Dave Froble
2021-09-29 01:03:23 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
No, I have not.
Note that, what Simon calls "embedded" today, it just the same kind
of development that was once done for VAXELN. You wrote, compiled
and linked your application on one system and then deployed on
another system. Your application booted directly without any
underlaying operating system.
Well, if one wants to look at it from this perspective, we don't do
any development on customer systems. Yes, we compile and link there,...
Why on earth do you force your customers to pay for compilers?
Post by Dave Froble
but, we don't really have to do so. Executables could be moved from
out development environment to customer systems.
Really?
Past practices, continuing from inertia. The internet hasn't always
been here. Most of that software existed from the past, so, not so much
paying for anything new.

There is always the chance of needing to do something, while on-site,
and the convience of having the tools available.

The cost is a whole bunch less than what your customer pays for Rdb.

:-)

Also, there is no forcing. If a customer wanted pre-built executables,
we'd be happy to do that.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2021-09-28 18:44:31 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
You've never done any embedded work have you ? :-)
Simon.
I do a lot. Apples and oranges.

bill
Arne Vajhøj
2021-09-28 17:50:36 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.
Maybe. But it would be pretty silly.
You have one or more inhouse applications on VMS
or you are an ISV selling a VMS application. You spend
between a few hundreds of thousands per yer up to
a few dozens of millions per year on that/those
applications. And you are not willing to spend
5000 to get 6-15 months head start on porting
to the new VMS platform.
That does not make any sense. There can be other
valid reasons not to do it. Like no need/demand
or wanting to see the production platform before
committing to port. But the money in itself should
not be an issue.
I don't think it was the money.  Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
OK. Maybe that is the case.

But the CIO should not be fired for not sharing such semi-religious
beliefs.

This is a business decision. What makes most sense for
the business. If it makes sense to get a version of the
application out quickly (and that is frequently a goal
in business) then cross compilers are how to do it.

Everybody want the native compilers for VMS and they will
show up. It just takes some time. More time than what we
prefer, but life is tough.

And look at it like this. VSI need cross compilers to
build VMS and the VMS compilers for x86-64 for obvious
reasons. They have made these compilers available to get
everybody started porting early. And I believe everybody
agrees that is much better than to have everybody outside
VSI wait for native compilers. Including those that may decide
to wait for valid business reasons (demand).

Arne
Dave Froble
2021-09-28 18:16:15 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.
Maybe. But it would be pretty silly.
You have one or more inhouse applications on VMS
or you are an ISV selling a VMS application. You spend
between a few hundreds of thousands per yer up to
a few dozens of millions per year on that/those
applications. And you are not willing to spend
5000 to get 6-15 months head start on porting
to the new VMS platform.
That does not make any sense. There can be other
valid reasons not to do it. Like no need/demand
or wanting to see the production platform before
committing to port. But the money in itself should
not be an issue.
I don't think it was the money. Bill is a bit old fashioned, like me,
and just feels the build tools should be native.
OK. Maybe that is the case.
But the CIO should not be fired for not sharing such semi-religious
beliefs.
This is a business decision. What makes most sense for
the business. If it makes sense to get a version of the
application out quickly (and that is frequently a goal
in business) then cross compilers are how to do it.
Everybody want the native compilers for VMS and they will
show up. It just takes some time. More time than what we
prefer, but life is tough.
And look at it like this. VSI need cross compilers to
build VMS and the VMS compilers for x86-64 for obvious
reasons. They have made these compilers available to get
everybody started porting early. And I believe everybody
agrees that is much better than to have everybody outside
VSI wait for native compilers. Including those that may decide
to wait for valid business reasons (demand).
Arne
Today is not the computer world I grew up in.

You may note that I mentioned that I understand Bill, but didn't say I
agreed with him. Many things (including itanics) can be picked up
rather cheaply these days. If some entity needs something, such as
cross compilers on itanic, the cost of entry just isn't that much anymore,.

Do what you gotta do, if you gotta do it.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-09-29 03:05:15 UTC
Permalink
Post by Arne Vajhøj
Everybody want the native compilers for VMS and they will
show up. It just takes some time. More time than what we
prefer, but life is tough.
The compiler team at VSI is a little smaller than the one back in the Alpha and Itanium era. At one point, the compiler team at Digital had close to 100 people working on compilers, language RTLs, DECset, etc. I don't have 100 people.

Bootstrapping an LLVM to OpenVMS x86 takes time and effort. We also need pieces of GEM for the compilers as well. It is a multi-step operation.

There are several features that have been deferred until we can use the newer LLVM natively. The LLVM 3.4.2 used for the cross-compilers has some limitations (for example, those using 'long double', real*16, etc.)

Besides the compilers themselves, there is testing, documentation, installation kits, etc to do. Can we do it ahead of schedule? We'll see.
Dave Froble
2021-09-28 01:39:55 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
Relevant point.
There are a significant number of VMS customers still on Alpha.
But what does a low end Itanium with VMS license cost
from IslandCo?
5000??
(Dave Turner - maybe start advertising a prepacked Itanium with
cross compilers bundle)
Way too much for a hobbyist but should not be a problem for
commercial context.
If I was a CEO and my CIO came to me with a scheme like that he
would be looking for a new job.
bill
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files? It's all just ones
and zeros, right?

Done being fair, I'd really prefer native compilers, linkers, and such.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Lawrence D’Oliveiro
2021-09-28 02:26:43 UTC
Permalink
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files? It's all just ones
and zeros, right?
I can think of one obvious problem with VMS, and that is how you represent the RMS attributes that are pretty much a mandatory part of the .OBJ format, if not .EXE, on other platforms? There’s no equivalent to such metadata on *nix systems, for example.
hb
2021-09-28 12:03:54 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files? It's all just ones
and zeros, right?
I can think of one obvious problem with VMS, and that is how you represent the RMS attributes that are pretty much a mandatory part of the .OBJ format, if not .EXE, on other platforms? There’s no equivalent to such metadata on *nix systems, for example.
On IA64 and x86 these are ELF.
Arne Vajhøj
2021-09-28 12:46:31 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which
CPU and OS is used to generate the OBJ and EXE files? It's all just
ones and zeros, right?
I can think of one obvious problem with VMS, and that is how you
represent the RMS attributes that are pretty much a mandatory part of
the .OBJ format, if not .EXE, on other platforms? There’s no
equivalent to such metadata on *nix systems, for example.
In this case it will be from VMS Itanium to VMS x86-64, so RMS
attributes should be fine.

Arne
hb
2021-09-29 09:10:37 UTC
Permalink
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which
CPU and OS is used to generate the OBJ and EXE files? It's all just
ones and zeros, right?
I can think of one obvious problem with VMS, and that is how you
represent the RMS attributes that are pretty much a mandatory part of
the .OBJ format, if not .EXE, on other platforms? There’s no
equivalent to such metadata on *nix systems, for example.
In this case it will be from VMS Itanium to VMS x86-64, so RMS
attributes should be fine.
Arne
On IA64 and x86, there is no record I/O in the linker or the image
activator. If you can get the ELF bits right for VMS, you can created
the files anywhere. On your phone or fridge, if you want.
Arne Vajhøj
2021-09-29 12:38:28 UTC
Permalink
Post by hb
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which
CPU and OS is used to generate the OBJ and EXE files? It's all just
ones and zeros, right?
I can think of one obvious problem with VMS, and that is how you
represent the RMS attributes that are pretty much a mandatory part of
the .OBJ format, if not .EXE, on other platforms? There’s no
equivalent to such metadata on *nix systems, for example.
In this case it will be from VMS Itanium to VMS x86-64, so RMS
attributes should be fine.
On IA64 and x86, there is no record I/O in the linker or the image
activator. If you can get the ELF bits right for VMS, you can created
the files anywhere. On your phone or fridge, if you want.
So any RFM will work.

Never a problem for EXE anyway as FTP in binary created FIX 512 files.

Arne

Dave Froble
2021-09-28 04:14:39 UTC
Permalink
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files? It's all just ones
and zeros, right?
Because build systems of any complexity tend to build things that build
more things that generate things that build other things. With enough
hacks, workarounds, and manual intervention in processes that are
normally automated, such systems can likely be made to work with
cross-compilers, but it's potentially a major effort.
Aren't I so glad that I don't use any of these "complex" modern tools?

Isn't it a bit of a bad idea to give up control of your apps to some
wizz bang modern tool? I think so.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-28 12:44:58 UTC
Permalink
Post by Dave Froble
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files?  It's all just ones
and zeros, right?
Because build systems of any complexity tend to build things that build
more things that generate things that build other things.  With enough
hacks, workarounds, and manual intervention in processes that are
normally automated, such systems can likely be made to work with
cross-compilers, but it's potentially a major effort.
Aren't I so glad that I don't use any of these "complex" modern tools?
Isn't it a bit of a bad idea to give up control of your apps to some
wizz bang modern tool?  I think so.
If you simply use BUILD.COM then replacing "basic" with
"basic/whateverswitchthecrosscompilationrequires" will probbaly
do.

Of course there are work.

But in the overall effort to add support for VMS x86-64, then
I will expect the effort to get cross compilation working
to be relative small.

Arne
Craig A. Berry
2021-09-28 13:56:52 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Dave Froble
Well, trying to be fair, what difference does it make, as to which CPU
and OS is used to generate the OBJ and EXE files?  It's all just ones
and zeros, right?
Because build systems of any complexity tend to build things that build
more things that generate things that build other things.  With enough
hacks, workarounds, and manual intervention in processes that are
normally automated, such systems can likely be made to work with
cross-compilers, but it's potentially a major effort.
Aren't I so glad that I don't use any of these "complex" modern tools?
Isn't it a bit of a bad idea to give up control of your apps to some
wizz bang modern tool?  I think so.
There are no modern tools involved.
Post by Arne Vajhøj
If you simply use BUILD.COM then replacing "basic" with
"basic/whateverswitchthecrosscompilationrequires" will probbaly
do.
Of course there are work.
But in the overall effort to add support for VMS x86-64, then
I will expect the effort to get cross compilation working
to be relative small.
You haven't seen the Perl build system, which generates a top-level
descrip.mms from a template with substitutions to include details for
configuration options chosen and the results of probes to see what
features are actually working on the version/architecture of VMS on
which it's running. Then it compiles and links a minimal version of Perl
which is used to generate hundreds of additional descrip.mms files,
which it then runs to generate many additional .c files and build
additional parts of the whole package and run the test suite.

To get this to work in a cross-compile environment, you'd need to
configure and build the minimal Perl with the native Itanium tools,
manually edit the configuration output to look like it had been run on
OpenVMS x86_64, switch to the cross-compile tools, and try to complete
the build. It *might* work, for some definition of work, but would also
probably take a lot of manual tweaking, which is one reason I haven't
attempted it yet. And then you couldn't run the test suite.

I do not expect any other build environment to look like the Perl build
environment, but I do expect there are many build systems that employ
similar bootstrapping principles and would encounter similar challenges
in a cross-compile environment.
Arne Vajhøj
2021-09-28 14:43:44 UTC
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
If you simply use BUILD.COM then replacing "basic" with
"basic/whateverswitchthecrosscompilationrequires" will probbaly
do.
Of course there are work.
But in the overall effort to add support for VMS x86-64, then
I will expect the effort to get cross compilation working
to be relative small.
You haven't seen the Perl build system, which generates a top-level
descrip.mms from a template with substitutions to include details for
configuration options chosen and the results of probes to see what
features are actually working on the version/architecture of VMS on
which it's running. Then it compiles and links a minimal version of Perl
which is used to generate hundreds of additional descrip.mms files,
which it then runs to generate many additional .c files and build
additional parts of the whole package and run the test suite.
To get this to work in a cross-compile environment, you'd need to
configure and build the minimal Perl with the native Itanium tools,
manually edit the configuration output to look like it had been run on
OpenVMS x86_64, switch to the cross-compile tools, and try to complete
the build. It *might* work, for some definition of work, but would also
probably take a lot of manual tweaking, which is one reason I haven't
attempted it yet.  And then you couldn't run the test suite.
I do not expect any other build environment to look like the Perl build
environment, but I do expect there are many build systems that employ
similar bootstrapping principles and would encounter similar challenges
in a cross-compile environment.
Maybe.

I think that everybody should strive for simple builds
and modular build tools where compiler switches is just
set one place.

But yes sometimes builds end up very complex in the real
world.

Arne
Bill Gunshannon
2021-09-28 00:24:27 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
It was originally due out at the end of this year however.
In addition, I suspect that some people will need to see at least one
point release after that before they will consider running it in
production.
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And what is the likelihood that a potential new customer would buy
an Itanium just to be able to use an x86/64?
Post by Simon Clubley
It's a pity there's no such thing as an Itanium full-system emulator
as one solution could have been to give everyone who buys a x86-64
VMS system a temporary Itanium licence with a two-year expiry period.
bill
Arne Vajhøj
2021-09-28 00:53:00 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Arne Vajhøj
Post by Dave Froble
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
It was originally due out at the end of this year however.
In addition, I suspect that some people will need to see at least one
point release after that before they will consider running it in
production.
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And what is the likelihood that a potential new customer would buy
an Itanium just to be able to use an x86/64?
None.

But this is clearly for existing VMS customers.

Arne
John Dallman
2021-09-28 08:42:00 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
And what is the likelihood that a potential new customer would buy
an Itanium just to be able to use an x86/64?
None.
But this is clearly for existing VMS customers.
It's a bit worse than that. Potential new VMS customers may well be
seriously put off by hearing of the idea that you need an Itanium to do
development, even if this is a short-lived thing. The view of Itanium in
the IT industry is most commonly "What's that?", followed by "Wasn't that
a massive failure 20 years ago?" and "That cost us a fortune, we're not
going back there!"

The VMS community stands out for its extremely positive attitude to VMS,
relative to the rest of the world. I'm including the Alpha hold-outs in
that statement.

John
Arne Vajhøj
2021-09-28 12:49:36 UTC
Permalink
Post by John Dallman
Post by Arne Vajhøj
Post by Bill Gunshannon
And what is the likelihood that a potential new customer would buy
an Itanium just to be able to use an x86/64?
None.
But this is clearly for existing VMS customers.
It's a bit worse than that. Potential new VMS customers may well be
seriously put off by hearing of the idea that you need an Itanium to do
development, even if this is a short-lived thing. The view of Itanium in
the IT industry is most commonly "What's that?", followed by "Wasn't that
a massive failure 20 years ago?" and "That cost us a fortune, we're not
going back there!"
Yes.

But I don't think potential new VMS customers are
looking at VMS yet.

9.2 will likely be all existing VMS customers.

We can hope that 9.3 / 9.4 / 10.0 will see some
new customers.

Arne
Dave Froble
2021-09-28 18:23:07 UTC
Permalink
Post by John Dallman
Post by Arne Vajhøj
Post by Bill Gunshannon
And what is the likelihood that a potential new customer would buy
an Itanium just to be able to use an x86/64?
None.
But this is clearly for existing VMS customers.
It's a bit worse than that. Potential new VMS customers may well be
seriously put off by hearing of the idea that you need an Itanium to do
development, even if this is a short-lived thing. The view of Itanium in
the IT industry is most commonly "What's that?", followed by "Wasn't that
a massive failure 20 years ago?" and "That cost us a fortune, we're not
going back there!"
The VMS community stands out for its extremely positive attitude to VMS,
relative to the rest of the world. I'm including the Alpha hold-outs in
that statement.
John
Alpha came into use somewhere around 1990. At the time, DEC claimed
that the architecture would be good for 25 years. Do the math, Alpha
was intended to be dead 5 or so years ago.

The real problem is, DEC isn't around to give us the follow on to
replace Alpha.

And so we got piece of shit itanic, and now piece of shit x86. Ain't
progress wonderful?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2021-09-28 14:09:52 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And for most who do have Itanium systems, the whole point of OpenVMS
x86-64 is to get rid of the aging Itanium hardware with failing parts
and insecure management consoles, and other things that get routinely
flagged by security audits and/or just cause additional hassle because
they have special needs that don't apply to anything else in the data
center. Even investigating a port without a native BASIC compiler is
just a non-starter at my day job.
Arne Vajhøj
2021-09-28 14:33:10 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And for most who do have Itanium systems, the whole point of OpenVMS
x86-64 is to get rid of the aging Itanium hardware with failing parts
and insecure management consoles, and other things that get routinely
flagged by security audits and/or just cause additional hassle because
they have special needs that don't apply to anything else in the data
center.
Yes, but the cross compilation thing is a temporary thing.

Arne
Dave Froble
2021-09-28 18:27:24 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And for most who do have Itanium systems, the whole point of OpenVMS
x86-64 is to get rid of the aging Itanium hardware with failing parts
and insecure management consoles, and other things that get routinely
flagged by security audits and/or just cause additional hassle because
they have special needs that don't apply to anything else in the data
center. Even investigating a port without a native BASIC compiler is
just a non-starter at my day job.
One wonders how possible and difficult it would be to get the cross
compilers running on itanic to work on an Alpha? Both are VMS. Many
things just move between the two with just a re-build.

For those still on Alpha, and, happier with Alpha than what some itanic
users might be.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-09-29 02:56:47 UTC
Permalink
Post by Dave Froble
Post by Craig A. Berry
Post by Simon Clubley
Post by Arne Vajhøj
*IF* you are willing to cross compile your Basic code on Itanium.
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
Not everyone will have an Itanium system. Some people are still
on Alpha.
And for most who do have Itanium systems, the whole point of OpenVMS
x86-64 is to get rid of the aging Itanium hardware with failing parts
and insecure management consoles, and other things that get routinely
flagged by security audits and/or just cause additional hassle because
they have special needs that don't apply to anything else in the data
center. Even investigating a port without a native BASIC compiler is
just a non-starter at my day job.
One wonders how possible and difficult it would be to get the cross
compilers running on itanic to work on an Alpha? Both are VMS. Many
things just move between the two with just a re-build.
For those still on Alpha, and, happier with Alpha than what some itanic
users might be.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
The Alpha C++ compiler cannot compile any LLVM sources.
Dave Froble
2021-09-27 17:52:50 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Ian Miller
An updated roadmap has been announced
https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
At this time, NOT A CHANCE !!

But, never say "never".
Post by Arne Vajhøj
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
At least for VSI and VMS, the cross compilers are a temporary tool to
allow them to work on x86 VMS. as such, I'd doubt that they are as
rigorously tested and maintained as "production level" software. But,
what do I know?

Doesn't matter, as far as I know, not my area, all customers are already
on VSI support. And will continue to be so.

VSI support - VSI support for customers

or

VSI support - customers supporting VSI

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-27 18:12:27 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Ian Miller
An updated roadmap has been announced
https://vmssoftware.com/about/news/2021-09-27-roadmap-update/
Some details on when the native compilers are going to arrive.
Always good with an update.
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
And Java runtime (well compiler and runtime, but compiler does
not matter) also first available November-December 2022.
Looks as if x86 will be useless, for me, for more than a year ..
9.2 are expected out in April and are considered production ready.
So only a half year.
*IF* you are willing to cross compile your Basic code on Itanium.
At this time, NOT A CHANCE !!
But, never say "never".
:-)
Post by Dave Froble
Post by Arne Vajhøj
But I fear that at least some people will question the "production
ready" status when native compilers are not available. That is
not a real issue (it is common for some types of system to
use cross compile), but it could very well be a perceived like
that.
At least for VSI and VMS, the cross compilers are a temporary tool to
allow them to work on x86 VMS.  as such, I'd doubt that they are as
rigorously tested and maintained as "production level" software.  But,
what do I know?
They are definitely new.

But VSI use them for their development as well (maybe not Basic but many
of the other) and I assume they got test suites to run for all
languages (including Basic).

And they use well tested frontends and well tested backend where the
only new is the combination including required glue.

I would be pretty optimistic about the quality.

Arne
Phillip Helbig (undress to reply)
2021-09-27 20:28:44 UTC
Permalink
Post by Arne Vajhøj
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
Any information on which version of the standards will be supported?
Arne Vajhøj
2021-09-27 22:55:23 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
Any information on which version of the standards will be supported?
It does not say.

But there are no new standard to follow for Basic and Pascal.

I doubt Cobol and Fortran will support newer standards. Very few
are interested in newer Cobol standards. And I believe the Fortran
roadmap is to look at flang later.

That leaves C and C++ as candidates for upgrades. And I believe
the plan is to support two flavors traditional VMS and clang. I am
pretty sure that they will support traditional VMS on above timeline.
Whether they will support clang and what version I don't know.

John Reagan will know.

Arne
Phillip Helbig (undress to reply)
2021-09-28 04:23:18 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
Any information on which version of the standards will be supported?
It does not say.
But there are no new standard to follow for Basic and Pascal.
I doubt Cobol and Fortran will support newer standards.
The latest Fortran for VMS is Fortran95. There have been several
standards since then.
Post by Arne Vajhøj
Very few
are interested in newer Cobol standards. And I believe the Fortran
roadmap is to look at flang later.
OK; maybe that will improve the situation.
Arne Vajhøj
2021-09-28 12:53:49 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
April 2022 - Bliss, Macro, standard C++
May-November 2022 - Cobol, C, VMS C++
November-December 2022 - Fortran, Basic, Pascal
Any information on which version of the standards will be supported?
It does not say.
But there are no new standard to follow for Basic and Pascal.
I doubt Cobol and Fortran will support newer standards.
The latest Fortran for VMS is Fortran95. There have been several
standards since then.
Yes. 2003, 2008 and 2018. But no existing VMS code use those for
obvious reasons.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Very few
are interested in newer Cobol standards. And I believe the Fortran
roadmap is to look at flang later.
OK; maybe that will improve the situation.
Flang supposedly is 2018.

Arne
Phillip Helbig (undress to reply)
2021-09-29 07:57:10 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
The latest Fortran for VMS is Fortran95. There have been several
standards since then.
Yes. 2003, 2008 and 2018. But no existing VMS code use those for
obvious reasons.
Right, but it shouldn't be enough to support an old standard.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Very few
are interested in newer Cobol standards. And I believe the Fortran
roadmap is to look at flang later.
OK; maybe that will improve the situation.
Flang supposedly is 2018.
That sounds better.
Loading...