[Info-vax] General Availability of 9.2 for x86-64

[John Reagan]

On Friday, July 15, 2022 at 10:33:46 AM UTC-4, Bill Gunshannon wrote:
> On 7/15/22 09:02, Simon Clubley wrote: 
> > On 2022-07-14, Arne Vajhøj <ar... at vajhoej.dk> wrote: 
> >> On 7/14/2022 12:18 PM, John Dallman wrote: 
> >>> Announced today: 
> >>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc 
> >>> ed/> 
> >>> 
> >>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as 
> >>> soon as more native compilers are available." 
> >> 
> >> https://vmssoftware.com/about/roadmap/ says: 
> >> 
> >> July 
> >> OpenVMS V9.2 (Limited Production Release) 
> >> ... 
> >> Native compilers with LLVM backend code generator: 
> >> BLISS, XMACRO, C++ (Phase 1) 
> >> ... 
> >> July-November 
> >> ... 
> >> Additional native compilers 
> >> C, COBOL, and C++ (Phase 2 ? VMS Extensions) 
> > 
> > Interesting that COBOL is a way higher priority than Fortran.
> Might be that the COBOL compiler is easier to port than the Fortran.

Both have their own set of unique features.  COBOL needs a bunch of
packed decimal conversion routines but they are all there since a
cross-compiled COBOL app needs them.  The compiler itself is pretty
boring.  Fortran (and BASIC) use COMMON blocks.  As I've mentioned
before, the model of common blocks on VMS is different than how
such things are represented with LLVM.  G2L has to look at the GEM
intermediate symbol table from each frontend and decide how to map
those to the LLVM model.  For Fortran, we get most of them right at
the moment.  For BASIC (the MAP statement), well that's another story
as the BASIC frontend pushes the boundaries

John