[Info-vax] VSI Basic

[John Reagan]

On Wednesday, March 1, 2023 at 8:57:34 PM UTC-5, Arne Vajhøj wrote:
> On 3/1/2023 8:48 PM, Craig A. Berry wrote: 
> > On 3/1/23 5:44 PM, Arne Vajhøj wrote: 
> >> Based on comp.os.vms questions and forum.vmssoftware.com questions, 
> >> then VMS Basic seems to be pretty widely used on VMS. 
> >> 
> >> I don't think VMS Basic is at risk to be deemed financially 
> >> not worth it. 
> >> 
> >> It just has to be completed. I suspect that the main reason 
> >> why Fortran was done before Basic was the simple fact that 
> >> LLVM has Fortran support (flang) out of the box. Alternative 
> >> explanation is that VMS Basic has some advanced features while 
> >> Fortran is probably more traditional. 
> > 
> > The Fortran compiler just released is based on the existing front end 
> > and the G2L translation layer that produces LLVM intermediate 
> > representations out of GEM intermediate representations.[1]  This has 
> > been stated publicly a number of times, as has been the fact they are 
> > going roughly in order by number of affected customers as they move 
> > through the list of compilers.  flang has nothing to do with it. 
> > 
> > A different project to port flang to VMS and add enough VMSisms to make 
> > it mostly compatible with the existing VMS compiler is theoretically 
> > possible, and somewhat interesting for newer features and standards 
> > compliance.  I believe it's been floated in the newsgroup before.  It 
> > seems unlikely anyone has the will or the resources to do it near-term.
> I was not implying that the released Fortran was flang - I know it 
> is not. 
> 
> My speculation was that because flang frontend exist, then the LLVM 
> backend has everything needed to support Fortran language readily 
> available making it easier to get the VMS Fortran frontend working.
> > The only other possibly relevant note about which of these two compilers 
> > gets done first is that the implementation of COMMON blocks in Fortran 
> > appears not to have been as evil as the implementation of MAP blocks in 
> > BASIC, which affects what has to be done to G2L and/or the front end 
> > itself to get things working.  In the case of BASIC, it sounds like 
> > reimplementing MAP in the front end is going to be less trouble than 
> > hacking G2L to manage what BASIC does.  Again, the fact that Fortran 
> > could be built with less intrusive changes to G2L has nothing at all to 
> > do with flang.
> See above. And compare to Basic where there is no "blang" 
> and if something is missing in the backend then it may be 
> easier to hack the frontend than the backend. 
> 
> But then I don't know LLVM at all. So I am just speculating. 
> 
> Arne
Yes there is a flang (there are actually two of them).  I've only briefly looked at the code.

The LLVM IR is quite capable of describing any language.  The existence of flang did not influence any of our decisions.

The G2L converter simply converts the GEM CIL and symbol table into LLVM.  What we didn't get was the subtle nature of COMMON blocks in the GEM symbol table.  Nothing to do with LLVM.  Nothing to do with flang.  Nothing special about BASIC other than it describe the COMMON blocks "differently" than Fortran.

Why Fortran?  Uh, customers asked?  It was next on the roadmap?  The build system that builds Fortran is the same one that builds GEM so we had some understanding of it?