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 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.
On 2024-02-20 2:24 p.m., Craig A. Berry wrote:
On 2/20/24 12:27 PM, Simon Clubley wrote:
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 <2f1b5bc7-ee3c-4e9b-8be6-601bef09e868n@googlegroups.com>:
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 <311392ca-9f5d-41e0-b15c-b383d5a682b5n@googlegroups.com>:
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.
(I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
in UNIX)
On Tue, 20 Feb 2024 15:33:15 -0500, Arne Vajhøj wrote:
(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?
hey simon is comp.os.vms done for or is their another chat site for vms?
are they ever going to stop the spam?=20
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.
On Tue, 20 Feb 2024 18:44:10 -0500, Arne Vajhøj wrote:
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.
On 2/20/2024 5:28 PM, Lawrence D'Oliveiro wrote:
On Tue, 20 Feb 2024 15:33:15 -0500, Arne Vajhøj wrote:
(technically Id did not write that - I quoted John)
(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
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
On a non-serious note, Simon all but guaranteed that it wouldn't appear
in January, by predicting, several months ago, that it would.
;-)
On 2/20/24 12:27 PM, Simon Clubley wrote:
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.
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.
will novabbs still work after the 23rd? Is this the new way to access comp.os.vms?
I wish some of those many COBOL users needed some programming done by
someone who actually knows COBOL. I'm bored and retirement sucks.
On 2024-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
On Tue, 20 Feb 2024 21:09:51 -0500, Arne Vajhøj wrote:
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
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”.
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.
Yes - it seems to be an extension to the standard. But VMS Fortran hast
lots of extensions to the standard.
On Wed, 21 Feb 2024 18:55:41 -0500, Arne Vajhøj wrote:
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?
On Wed, 21 Feb 2024 09:51:18 -0500, bill wrote:
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?
will novabbs still work after the 23rd?
Is this the new way to access comp.os.vms?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 376 |
Nodes: | 16 (2 / 14) |
Uptime: | 29:06:13 |
Calls: | 8,036 |
Files: | 13,034 |
Messages: | 5,829,689 |