[Info-vax] VSI Basic

[Craig A. Berry]

On 3/1/23 5:44 PM, Arne Vajhøj wrote:
> On 3/1/2023 1:14 PM, Simon Clubley wrote:
>> On 2023-03-01, Rich Jordan <jordan at ccs4vms.com> wrote:
>>> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>>>>  From a recent email:
>>>>
>>>> "VMS Software Inc. is pleased to announce availability of a test 
>>>> release of a Fortran compiler for OpenVMS x86. The code is based on 
>>>> VSI Fortran on OpenVMS I64 for source compatibility."
>>>>
>>>> The message contained a link to the Release Notes, but the URL does 
>>>> not paste well.
>>>>
>>>> - Bob Gezelter, http://www.rlgsc.com
>>>
>>> Good news indeed!  But our last Fortran customer departed some years 
>>> ago.
>>>
>>> Basic is what we're waiting for.
>>>
>>
>> Given that it's already March 2023, my guess is that Basic will come out
>> in time for the 10th anniversary of the VMS porting effort. :-)
>>
>> On a more serious note, I wonder how much income VSI get from Basic ?
>>
>> If John finds a core problem that can't be easily fixed, is there a
>> point at which VSI could say that the expenditure on VMS Basic is
>> going to be greater than the income from it and hence drop it ?
>>
>> Of the mainstream languages available for x86-64 VMS, Basic would appear
>> to be the one with the smallest market share, and don't forget that VSI
>> have already decided not to proceed with Ada for x86-64 VMS.
> 
> 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.

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.

[1] 
https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf