Technical issues with VMS BASIC port to x86-64 ?

[mjos_examine]

I am curious, at a purely technical level, about the issues that VSI

I'm pretty sure this has already been explained multiple times.  What I
think I remember is that exception handling and dynamic maps pose some
challenges, and there may be RTL dependencies that are somewhat
different from the other compilers.  But I don't think COBOL was easy
either -- it just has a lot more users and was thus a higher priority.

There has been some information posted over the past 11 months.

On 2023-03-01 2:13 p.m., John Reagan wrote in Message ID

Don't blow the BASIC issue out of proportion. It is just that the BASIC frontend
generates GEM symbol table that look "different" than everybody else. I
just haven't had the time (or desire) to change how G2L has to operate. I'd
rather change the BASIC frontend. I have other things to do first. It is not
a multiple person-year task. We have all the real HARD pieces of BASIC already
working.

On 2023-09-07 9:56 p.m., John Reagan wrote in Message Id

We have resolved one of the difficult issues with BASIC MAP statements
and can actually pass a significant number of tests. However, we still have
a few more things to track down before I would say it is useful.
We're actually trying to refresh other compilers this month as well. Too
many things to keep track off including a fresh set of COBOL issues
and working on the debugger & DWARF generation.

On a non-serious note, Simon all but guaranteed that it wouldn't appear
in January, by predicting, several months ago, that it would.
;-)

[Arne Vajhøj]

I am curious, at a purely technical level, about the issues that VSI
have encountered with porting BASIC to x86-64 VMS and what the issues
are, at a technical level, that is making the port of BASIC apparently
much more complex than the other traditional VMS languages.

Most of what has been revealed over the last couple of years relate
to map/common/psect handling and G2L.

But I am no longer convinced that Basic is so much late, because
it is so "much more complex".

I suspect Basic is mostly so much late, because it was the last to
do and that there has been found a large number of bugs found in
the compilers released earlier that has taken most of the available
compiler resource hours. I simply suspect that Basic has been delayed
because John and the rest of the team has been busy fixing bugs in
the C, C++, Fortran and Pascal compilers.

Arne

[Simon Clubley]

Post by Arne Vajhøj
But I am no longer convinced that Basic is so much late, because
it is so "much more complex".
I suspect Basic is mostly so much late, because it was the last to
do and that there has been found a large number of bugs found in
the compilers released earlier that has taken most of the available
compiler resource hours. I simply suspect that Basic has been delayed
because John and the rest of the team has been busy fixing bugs in
the C, C++, Fortran and Pascal compilers.

That could be the case, with BASIC being a lower priority than the other
compilers.

Of course, it could also be them settling into their new offices. :-)
Looks like a nice place.

Simon.

[Lawrence D'Oliveiro]

(I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
in UNIX)

Is it a namespace issue? Because .comm names live in the same namespace as
global symbol names?

<<https://sourceware.org/binutils/docs-2.42/as/Comm.html>>

[Arne Vajhøj]

(technically Id did not write that - I quoted John)

Post by Lawrence D'Oliveiro

(I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
in UNIX)

Is it a namespace issue? Because .comm names live in the same namespace as
global symbol names?

There are probably multiple differences.

And a lot of code triggering the problems are probably rather bad code.
But the expectation for VMS x86-64 is 99.9999% compatibility not 99%
compatibility.

If I remember correctly then the example given in one of these threads
were a Fortran common block where some part of the data was initialized
in some code and other part of the data was initialized in other code.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
If I remember correctly then the example given in one of these threads
were a Fortran common block where some part of the data was initialized
in some code and other part of the data was initialized in other code.

COMMON blocks don’t allow for initializers.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
If I remember correctly then the example given in one of these threads
were a Fortran common block where some part of the data was initialized
in some code and other part of the data was initialized in other code.

COMMON blocks don’t allow for initializers.

Data can not be initialized in COMMON, but data in COMMON can be
initialized.

I believe the example was somewhat similar to:

program bad
integer*4 a(2)
common /m/a
call s1
call s2
write(*,*) a(1),a(2)
end
c
subroutine s1
integer*4 a(2)
common /m/a
data a(1)/123/
end
c
subroutine s2
integer*4 a(2)
common /m/a
data a(2)/456/
end

Arne

[Arne Vajhøj]

Post by Arne Vajhøj
program bad
integer*4 a(2)
common /m/a
call s1
call s2
write(*,*) a(1),a(2)
end
c
subroutine s1
integer*4 a(2)
common /m/a
data a(1)/123/
end
c
subroutine s2
integer*4 a(2)
common /m/a
data a(2)/456/
end

Looking at the Fortran 2018 spec, section 8.4, it says “A variable, or
part of a variable, shall not be explicitly initialized more
than once in a program”.
Also section 8.6.7 says “A variable whose designator appears as a data-
stmt-object or a data-i-do-object shall not be a dummy argument, accessed
by use or host association, in a named common block unless the DATA
statement is in a block data program unit, in blank common, a function
name, a function result name, an automatic data object, or an allocatable
variable”.

And?

Instead of reading the specs you should have tried compiling
the code on your VMS system.

It compiles and runs fine!

Yes - it seems to be an extension to the standard. But VMS Fortran
hast lots of extensions to the standard.

But let us take a step back and look at a slightly more
reasonable example.

$ type soso.for
program soso
integer*4 a(2)
common /m/a
call s
write(*,*) a(1),a(2)
end
c
subroutine s
integer*4 a(2)
common /m/a
data a/123,456/
end
$ for soso
$ link soso
$ r soso
123 456

Which may not be good code as it is rather unclear
where the data initialization happens, but not nearly
as bad as the code further above.

And I believe that style is widely used on VMS. BLOCK DATA
are not often used on VMS. I mostly see them used for writeable
shareable images - and that is a very special case.

$ type bad.for
program bad
integer*4 a(2)
common /m/a
call s1
call s2
write(*,*) a(1),a(2)
end
c
subroutine s1
integer*4 a(2)
common /m/a
data a(1)/123/
end
c
subroutine s2
integer*4 a(2)
common /m/a
data a(2)/456/
end
$ for bad
$ link bad
$ r bad
123 456

Is really ugly code. But it worked on VMS VAX 40 years ago,
so the expectation is that it works on VMS x86-64 today.

Backwards compatibility can be a real PITA.

It is possible to ask for stronger standard compliance check.

$ for/stand=f95 soso

program soso
^
%F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
at line number 1 in file DKA0:[arne]soso.for;1

integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
at line number 2 in file DKA0:[arne]soso.for;1

integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
at line number 9 in file DKA0:[arne]soso.for;1

data a/123,456/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block. [A]
at line number 11 in file DKA0:[arne]soso.for;1
$ for/stand=f95 bad

program bad
^
%F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
at line number 1 in file DKA0:[arne]bad.for;1

integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
at line number 2 in file DKA0:[arne]bad.for;1

integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
at line number 10 in file DKA0:[arne]bad.for;1

data a(1)/123/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block. [A]
at line number 12 in file DKA0:[arne]bad.for;1

integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
at line number 16 in file DKA0:[arne]bad.for;1

data a(2)/456/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block. [A]
at line number 18 in file DKA0:[arne]bad.for;1

Both the INTEGER*4 declaration and the mix of COMMON and DATA
are not valid per Fortran 95 standard resulting in the warning.

But with old VMS Fortran code that qualifier is pretty rare.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj
But let us take a step back and look at a slightly more
reasonable example.
$ type soso.for
      program soso
      integer*4 a(2)
      common /m/a
      call s
      write(*,*) a(1),a(2)
      end
c
      subroutine s
      integer*4 a(2)
      common /m/a
      data a/123,456/
      end
$ for soso
$ link soso
$ r soso
        123         456
Which may not be good code as it is rather unclear
where the data initialization happens, but not nearly
as bad as the code further above.
And I believe that style is widely used on VMS. BLOCK DATA
are not often used on VMS. I mostly see them used for writeable
shareable images - and that is a very special case.
$ type bad.for
      program bad
      integer*4 a(2)
      common /m/a
      call s1
      call s2
      write(*,*) a(1),a(2)
      end
c
      subroutine s1
      integer*4 a(2)
      common /m/a
      data a(1)/123/
      end
c
      subroutine s2
      integer*4 a(2)
      common /m/a
      data a(2)/456/
      end
$ for bad
$ link bad
$ r bad
        123         456
Is really ugly code. But it worked on VMS VAX 40 years ago,
so the expectation is that it works on VMS x86-64 today.
Backwards compatibility can be a real PITA.
It is possible to ask for stronger standard compliance check.
$ for/stand=f95 soso
      program soso
^
%F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
at line number 1 in file DKA0:[arne]soso.for;1
      integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification.   [4]
at line number 2 in file DKA0:[arne]soso.for;1
      integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification.   [4]
at line number 9 in file DKA0:[arne]soso.for;1
      data a/123,456/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block.   [A]
at line number 11 in file DKA0:[arne]soso.for;1
$ for/stand=f95 bad
      program bad
^
%F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
at line number 1 in file DKA0:[arne]bad.for;1
      integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification.   [4]
at line number 2 in file DKA0:[arne]bad.for;1
      integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification.   [4]
at line number 10 in file DKA0:[arne]bad.for;1
      data a(1)/123/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block.   [A]
at line number 12 in file DKA0:[arne]bad.for;1
      integer*4 a(2)
..............^
%F90-W-WARNING, Fortran 95 does not allow this length specification.   [4]
at line number 16 in file DKA0:[arne]bad.for;1
      data a(2)/456/
...........^
%F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
in either a blank COMMON block or a named COMMON block.   [A]
at line number 18 in file DKA0:[arne]bad.for;1
Both the INTEGER*4 declaration and the mix of COMMON and DATA
are not valid per Fortran 95 standard resulting in the warning.
But with old VMS Fortran code that qualifier is pretty rare.

Note that VMS Fortran is not unique in accepting that code.

I have not been able to find a Fortran compiler not accepting
it by default.

GFortran:

C:\Work\Fortran>gfortran soso.for -o soso.exe

C:\Work\Fortran>soso
123 456

C:\Work\Fortran>gfortran bad.for -o bad.exe

C:\Work\Fortran>bad
123 0

C:\Work\Fortran>gfortran -std=f95 soso.for -o soso.exe
soso.for:2:16:

2 | integer*4 a(2)
| 1
Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
soso.for:5:18:

5 | write(*,*) a(1),a(2)
| 1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'a' at (1)
soso.for:9:16:

9 | integer*4 a(2)
| 1
Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
soso.for:11:13:

11 | data a/123,456/
| 1
Error: GNU Extension: initialization of common block variable 'a' in
DATA statement at (1)

C:\Work\Fortran>gfortran -std=f95 bad.for -o bad.exe
bad.for:2:16:

2 | integer*4 a(2)
| 1
Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
bad.for:6:18:

6 | write(*,*) a(1),a(2)
| 1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'a' at (1)
bad.for:10:16:

10 | integer*4 a(2)
| 1
Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
bad.for:12:13:

12 | data a(1)/123/
| 1
Error: GNU Extension: initialization of common block variable 'a' in
DATA statement at (1)
bad.for:16:16:

16 | integer*4 a(2)
| 1
Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
bad.for:18:13:

18 | data a(2)/456/
| 1
Error: GNU Extension: initialization of common block variable 'a' in
DATA statement at (1)

The soso example works fine default.

It is definitely not nice that the compiler and linker silently
drops the initialization of a(2) in the bad example default.

Old G77:

C:\Work\Fortran>g77 soso.for -o soso.exe

C:\Work\Fortran>soso
123 456

C:\Work\Fortran>g77 bad.for -o bad.exe
bad.for: In subroutine `s2':
bad.for:12:
data a(1)/123/
1
bad.for:18: (continued):
data a(2)/456/
2
Common block `m' initialized at (2) already initialized at (1) -- only
one program unit may specify initial values for a particular common block

The soso example works fine default.

I think this way to handle the bad example is rather appropriate.

And an even older Watcom compiler for DOS:

C:\Work\Fortran>wfl soso.for
Open Watcom F77/16 Compile and Link Utility Version 1.9
Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wfc soso.for
Open Watcom FORTRAN 77/16 Optimizing Compiler Version 1.9
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
soso.for: 11 statements, 53 bytes, 4 extensions, 0 warnings, 0 errors
wlink @__wfl__.lnk
Open Watcom Linker Version 1.9
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a DOS executable

C:\Work\Fortran>wfl bad.for
Open Watcom F77/16 Compile and Link Utility Version 1.9
Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wfc bad.for
Open Watcom FORTRAN 77/16 Optimizing Compiler Version 1.9
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
bad.for: 17 statements, 59 bytes, 6 extensions, 0 warnings, 0 errors
wlink @__wfl__.lnk
Open Watcom Linker Version 1.9
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a DOS executable

(and it produces correct results too for both - I just can't copy paste
from DOSBOX)

Arne

[Lawrence D'Oliveiro]

Yes - it seems to be an extension to the standard. But VMS Fortran hast
lots of extensions to the standard.

And this particular “extension” does not work consistently from one
architecture to another. Big surprise?

[Dave Froble]

Post by Arne Vajhøj
(technically Id did not write that - I quoted John)

Post by Lawrence D'Oliveiro

(I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
in UNIX)

Is it a namespace issue? Because .comm names live in the same namespace as
global symbol names?

There are probably multiple differences.
And a lot of code triggering the problems are probably rather bad code.
But the expectation for VMS x86-64 is 99.9999% compatibility not 99%
compatibility.
If I remember correctly then the example given in one of these threads
were a Fortran common block where some part of the data was initialized
in some code and other part of the data was initialized in other code.
Arne

Back in Basic+ there was/is the FIELD operator. It was/is used to dynamically
assign label(s) to locations in an I/O buffer. For example,

FIELD #1%, 2 as Z1$, 8 as Z2$, 20 as Z3$

The variables then had their descriptors modified to have addresses in the I/O
buffer associated with channel #1. After all, what good is I/O unless one can
access the data?

The VAX Basic people really didn't like the operator and the concept. They
wanted to have RMS in move mode move a record into a MAP that was NOT accessing
the I/O buffer.

Didn't sit too well with those coming from RSTS. Their (VAX BASIC) response was
the dynamic map capabilities. What they did to achieve this, I don't know.
Maybe that is where the weirdness comes from.

We didn't use their dynamic MAP capabilities. We were rather happy with working
in the I/O buffer, and developed software to re-purpose string variables as
labels in an I/O buffer. Seemed reasonable to us. Image rundown got rather
upset if the string descriptors were not returned to their initial state.

:-)

[[e-mail]]

This is NOT a moan about how long it is taking for BASIC to appear,
and I would request people not turn it into one, at least in this
thread.
I am curious, at a purely technical level, about the issues that VSI
have encountered with porting BASIC to x86-64 VMS and what the issues
are, at a technical level, that is making the port of BASIC apparently
much more complex than the other traditional VMS languages.
Thanks,
Simon.
--
Walking destinations on a map are further away than they appear.

hey simon is comp.os.vms done for or is their another chat site for vms?

are they ever going to stop the spam?

[Scott Dorsey]

Post by ***@gmail.com
hey simon is comp.os.vms done for or is their another chat site for vms?

I don't see any reason for anyone to move.

Post by ***@gmail.com
are they ever going to stop the spam?=20

Google will FINALLY get their server disconnected in three more days and
there will be cheering and champagne will be opened and the spam will all
disappear! Thank God we have got rid of Google and good riddance to bad
rubbish. This newsgroup will be MUCH easier to read without all the Google
droppings.
--scott

[bill]

Post by ***@gmail.com

This is NOT a moan about how long it is taking for BASIC to appear,
and I would request people not turn it into one, at least in this
thread.
I am curious, at a purely technical level, about the issues that VSI
have encountered with porting BASIC to x86-64 VMS and what the issues
are, at a technical level, that is making the port of BASIC apparently
much more complex than the other traditional VMS languages.
Thanks,
Simon.
--
Walking destinations on a map are further away than they appear.

hey simon is comp.os.vms done for or is their another chat site for vms?
are they ever going to stop the spam?

Some of us who use decent news servers aren't seeing any of the spam. :-)

bill

[Simon Clubley]

This is NOT a moan about how long it is taking for BASIC to appear,
and I would request people not turn it into one, at least in this
thread.
I am curious, at a purely technical level, about the issues that VSI
have encountered with porting BASIC to x86-64 VMS and what the issues
are, at a technical level, that is making the port of BASIC apparently
much more complex than the other traditional VMS languages.

I'm pretty sure this has already been explained multiple times. What I
think I remember is that exception handling and dynamic maps pose some
challenges, and there may be RTL dependencies that are somewhat
different from the other compilers. But I don't think COBOL was easy
either -- it just has a lot more users and was thus a higher priority.

That's correct Craig. However, those discussions were within the context
of BASIC being released "shortly" at the time those discussions took place.

Given the extended delay since those discussions, I was wondering if more
deeper technical issues had emerged which had not yet been discussed here.

Simon.

[Simon Clubley]

Post by mjos_examine
On a non-serious note, Simon all but guaranteed that it wouldn't appear
in January, by predicting, several months ago, that it would.
;-)

$ set response/mode=good_natured

I hope you are not suggesting VSI delayed it so that my public prediction
would be incorrect. :-) :-)

However, in that good natured spirit, my next prediction is that VSI will
not release BASIC until at least July 2024. :-)

Simon.

[bill]

  But I don't think COBOL was easy
either -- it just has a lot more users and was thus a higher priority.

I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.

bill

[abrsvc]

Post by bill

But I don't think COBOL was easy
either -- it just has a lot more users and was thus a higher priority.

I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.
bill

[abrsvc]

Post by bill

But I don't think COBOL was easy
either -- it just has a lot more users and was thus a higher priority.

I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.
bill

Bill,

Please contact me offline. I may have an opportunity for you.

Dan

(Email: ***@yahoo.com)

[Lawrence D'Oliveiro]

Post by bill
I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.

I thought COBOL programmers had come out of retirement and were making
money hand over fist.

So is the “COBOL renaissance” actually over? Is COBOL code finally going
out of use?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by bill
I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.

I thought COBOL programmers had come out of retirement and were making
money hand over fist.
So is the “COBOL renaissance” actually over? Is COBOL code finally going
out of use?

There are still a lot of Cobol out there. But not so much Cobol
work, because most of that Cobol code is getting minimum changes.
If it was getting huge changes then it would be reimplemented in
something else.

There has been talk for like 20 years about the problem with
Cobol programmers retiring and noone left to maintain Cobol code.

For many years that was a colorful magazine problem not found
in the real world. Few Cobol jobs and relative modest pay for
Cobol skills.

But my feeling is that it has changed in recent years. Increase
in number of Cobol jobs advertised and salaries moving from low
to mid level.

Not related to Covid. There were some temporarily panic when
old government systems needed to implement new Covid related
regulation at short notice, but that is long over.

I suspect that it is really due to math.

cobol skill demand = constant * (1 - cobol system attrition rate)**time
cobol skill supply = constant - size of year of cobol trained * time

with those formulas then at some point in time demand will exceed
supply. I suspect that it did happen a few years ago.

Arne