On 1/25/2023 3:14 PM, jimc...@gmail.com wrote:
> On Wednesday, January 25, 2023 at 11:53:29 AM UTC-8, Arne Vajhøj
> wrote:
>> Hasn't it been informally known for a decade and formally known for
>> years that VSI focus was to get the existing VMS customers from
>> Alpha and Itanium to x86-64 and that new customers are future after
>> that?
>
> For some time, VSI made bold public statements about VMS being a
> competitive replacement for other platforms, usually based on some
> 1980s-era marketing language around being more secure and stable
>
> It would seem they are now being more realistic, or at least
> postponing that talk until they're finished bringing x86-64 to at
> least early-2000s Alpha parity

I don't think that it is a recent change.

It has been the message for some time.

>> Ask them again in 2028 and they may have a different answer.
>
> The amount of technical debt to be completed in order to expand their
> market share will only grow in the intervening years between now and
> 2028

Some yes.

But VSI do not need to wait until 2028 to start the work.

The following is not from VSI but my speculation:

VSI sales & support people VSI R&D people
phase 1 convince customers to stay on VMS produce VMS x86-64
phase 2 get customers from AXP/I64 to x64 enhance VMS as SW platform
phase 3 start sell VMS to new customers ?

Arne

On 1/25/23 1:41 PM, Arne Vajhøj wrote:
> On 1/25/2023 2:18 PM, Craig A. Berry wrote:
>> On 1/25/23 11:03 AM, Arne Vajhøj wrote:
>>> On 1/24/2023 6:27 PM, Craig A. Berry wrote:
>>>> On 1/24/23 12:17 PM, Simon Clubley wrote:
>>>>> |What position does PostgreSQL have on the list of opensource
>>>>> software?
>>>>> |
>>>>> |We have no plans to port PostgreSQL to OpenVMS.
>>>>
>>>> That is bizarre.  It's already _been_ ported for Integrity and has been
>>>> available since 10 December 2021 as a download from the VSI portal.
>>>> It's hard to imagine what an x86 build would require that's different
>>>> from an IA64 build.
>>>
>>> PostgreSQL Client (libpq) is available for both Alpha and Itanium:
>>>     https://vmssoftware.com/products/libpq/
>>>
>>> There has been a lot of talk about PostgreSQL server for VMS and
>>> the associated changes to IO. But I have not seen a formal
>>> announcement of a finished product being available.
>>
>> The kit name is VSI-I64VMS-POSTGRESQL-V1303--1, so appears not just to
>> be libpq.
>
> That is a different kit from the LIBPQ kit above.
>
>>  The description says, "VSI Shared Stream I/O Modules and VSI
>> POSTGRESQL Version 13.3-1 for VSI OpenVMS I64 Version 8.4-2L3 and
>> higher. SSIO_MODULES.ZIP and Release Notes are included in the ZIP file.
>> * THIS IS A FIELD TEST KIT RELEASE ONLY! *."  And appears to be only
>> available with a support contract.
>
> Field test I know.
>
> :-)
>
>> Maybe the field test revealed more problems than they have time to look
>> into right now.  Or maybe SSIO is even more difficult to get right than
>> they thought it was.
>
> Priorities.
>
> Getting 9.x and the native compilers out is way more important.
>
> And even for the database area then helping the existing
> VMS Oracle client customers moving to SQLRelay is probably more
> important than a new database.

I have no argument with the priorities. There's still a bit of a
disconnect between saying on the one hand "We have ported PostgreSQL to
VMS and here's a field test kit" and on the other hand "We have no plans
to port PostgreSQL to VMS."

On Wednesday, January 25, 2023 at 1:14:40 PM UTC-5, Simon Clubley wrote:
> On 2023-01-25, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >
> > Given a lot of VMS users are using Basic, then I don't think
> > it is being down prioritized for business reasons. That does not
> > make sense.
> >
> John has mentioned that he's hit problems due to some unique requirement
> in DEC Basic. I wonder if the problems were more serious than he
> initially realised ?
>
> Simon.
>
> PS: I wonder what they finally ended up doing about TECO ? :-)
>
> PPS: On a more serious note, I wonder how the Rdb users feel about
> Rdb not been available for x86-64 for at least another year ?
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I wrote that sentence in the PDF file. Vadim is less optimistic. We'll see who is right.
Depends on how often they change the water in my "head in a jar".

As I've said before, the issue is COMMON blocks. When I first did the design of
how to convert GEM CIL and GEM symbol table to LLVM, I didn't appreciate the
difference in how COMMON blocks are described to LLVM and the UNIX environment
in general. It isn't just BASIC, you can see broken COMMON blocks in the Fortran
cross-compiler if you look hard enough. The problem is that the BASIC MAP statement
doesn't work right and almost every BASIC program uses MAPs for something. I have
a BASIC cross-compiler. If you don't use a MAP, it probably works (although the test
system doesn't very far without MAP).

I also didn't appreciate the complexity of how BASIC uses (exploits?) the GEM interfaces.
We already found one place where it relied on the GEM implementation in spite of the
GEM documentation saying "don't do that". We extended the G2L converter to emulate
the GEM behavior about positioning of variables on the stack.

I'm actually code reviewing (well, I haven't started reviewing yet) a solution from one
of my engineers. It fixes the Fortran issues. I hope it will help BASIC but I haven't
looked. We'll keep pounding on it.

On 1/25/2023 5:16 PM, John Reagan wrote:
> I wrote that sentence in the PDF file. Vadim is less optimistic. We'll see who is right.
> Depends on how often they change the water in my "head in a jar".
>
> As I've said before, the issue is COMMON blocks. When I first did the design of
> how to convert GEM CIL and GEM symbol table to LLVM, I didn't appreciate the
> difference in how COMMON blocks are described to LLVM and the UNIX environment
> in general. It isn't just BASIC, you can see broken COMMON blocks in the Fortran
> cross-compiler if you look hard enough. The problem is that the BASIC MAP statement
> doesn't work right and almost every BASIC program uses MAPs for something. I have
> a BASIC cross-compiler. If you don't use a MAP, it probably works (although the test
> system doesn't very far without MAP).
>
> I also didn't appreciate the complexity of how BASIC uses (exploits?) the GEM interfaces.
> We already found one place where it relied on the GEM implementation in spite of the
> GEM documentation saying "don't do that". We extended the G2L converter to emulate
> the GEM behavior about positioning of variables on the stack.
>
> I'm actually code reviewing (well, I haven't started reviewing yet) a solution from one
> of my engineers. It fixes the Fortran issues. I hope it will help BASIC but I haven't
> looked. We'll keep pounding on it.

I am surprised that Fortran COMMON is a problem given
flang, but the details tend to be full of little devils.

:-)

Do you need to fix everything in G2L or can you sometimes
get a change into the LLVM backend?

Arne

On 1/25/2023 4:27 PM, Craig A. Berry wrote:
> I have no argument with the priorities.  There's still a bit of a
> disconnect between saying on the one hand "We have ported PostgreSQL to
> VMS and here's a field test kit" and on the other hand "We have no plans
> to port PostgreSQL to VMS."

Totally agree.

But sometimes companies are reluctant to commit in writing
to anything that is not ready yet.

Arne

On Wednesday, January 25, 2023 at 5:35:22 PM UTC-5, Arne Vajhøj wrote:
> On 1/25/2023 5:16 PM, John Reagan wrote:
> > I wrote that sentence in the PDF file. Vadim is less optimistic. We'll see who is right.
> > Depends on how often they change the water in my "head in a jar".
> >
> > As I've said before, the issue is COMMON blocks. When I first did the design of
> > how to convert GEM CIL and GEM symbol table to LLVM, I didn't appreciate the
> > difference in how COMMON blocks are described to LLVM and the UNIX environment
> > in general. It isn't just BASIC, you can see broken COMMON blocks in the Fortran
> > cross-compiler if you look hard enough. The problem is that the BASIC MAP statement
> > doesn't work right and almost every BASIC program uses MAPs for something. I have
> > a BASIC cross-compiler. If you don't use a MAP, it probably works (although the test
> > system doesn't very far without MAP).
> >
> > I also didn't appreciate the complexity of how BASIC uses (exploits?) the GEM interfaces.
> > We already found one place where it relied on the GEM implementation in spite of the
> > GEM documentation saying "don't do that". We extended the G2L converter to emulate
> > the GEM behavior about positioning of variables on the stack.
> >
> > I'm actually code reviewing (well, I haven't started reviewing yet) a solution from one
> > of my engineers. It fixes the Fortran issues. I hope it will help BASIC but I haven't
> > looked. We'll keep pounding on it.
> I am surprised that Fortran COMMON is a problem given
> flang, but the details tend to be full of little devils.
>
> :-)
>
> Do you need to fix everything in G2L or can you sometimes
> get a change into the LLVM backend?
>
> Arne
G2L recurses down the symbol table and converts the static variables in each block as it finds
them. The difference is that GEM frontends can record the desired offset into the PSECT in
any order. We sort by offset in each block, but we need to hoist all the static variables out in
another pass, sort them, and do them all at the module level. PSECTs are created by the linker.
They exist outside the control of the compiler.

Here's a nasty Fortran program where each subroutine initializes and reinitializes parts of the
same common block in a particular order.

subroutine print_common
common /mypsect/ i1,i2
integer*4 :: i1,i2
write (*,10) i1,i2
10 format (' ',Z8,' ',Z8)
return
end

subroutine update_longwords
common /mypsect/ i1,i2
c start with putting hex AAAAAAAA into both longwords
integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
return
end

subroutine update_words
c and update bottom words with BBBB
common /mypsect/ w1,w2,w3,w4
integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
return
end

subroutine update_bytes
c and update bottom bytes with CC
common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
return
end

program main
c by now, the two longwords in the common should be
c CCBBAAAA CCBBAAAA
call print_common
end

On 1/25/2023 5:55 PM, John Reagan wrote:
> G2L recurses down the symbol table and converts the static variables in each block as it finds
> them. The difference is that GEM frontends can record the desired offset into the PSECT in
> any order. We sort by offset in each block, but we need to hoist all the static variables out in
> another pass, sort them, and do them all at the module level. PSECTs are created by the linker.
> They exist outside the control of the compiler.
>
> Here's a nasty Fortran program where each subroutine initializes and reinitializes parts of the
> same common block in a particular order.
>
> subroutine print_common
> common /mypsect/ i1,i2
> integer*4 :: i1,i2
> write (*,10) i1,i2
> 10 format (' ',Z8,' ',Z8)
> return
> end
>
> subroutine update_longwords
> common /mypsect/ i1,i2
> c start with putting hex AAAAAAAA into both longwords
> integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
> return
> end
>
> subroutine update_words
> c and update bottom words with BBBB
> common /mypsect/ w1,w2,w3,w4
> integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
> return
> end
>
> subroutine update_bytes
> c and update bottom bytes with CC
> common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
> integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
> return
> end
>
> program main
> c by now, the two longwords in the common should be
> c CCBBAAAA CCBBAAAA
> call print_common
> end

That is horrible code IMHO.

Initializing the same common block in multiple subroutines
is not something I would ever do.

I would expect either an error or undefined result due to
order of processing being undefined.

But then I don't know what the Fortran standard and the
VMS Fortran documentation says on the topic.

Someone is actually using such constructs?

Arne

On Wednesday, January 25, 2023 at 6:50:20 PM UTC-5, Arne Vajhøj wrote:
> On 1/25/2023 5:55 PM, John Reagan wrote:
> > G2L recurses down the symbol table and converts the static variables in each block as it finds
> > them. The difference is that GEM frontends can record the desired offset into the PSECT in
> > any order. We sort by offset in each block, but we need to hoist all the static variables out in
> > another pass, sort them, and do them all at the module level. PSECTs are created by the linker.
> > They exist outside the control of the compiler.
> >
> > Here's a nasty Fortran program where each subroutine initializes and reinitializes parts of the
> > same common block in a particular order.
> >
> > subroutine print_common
> > common /mypsect/ i1,i2
> > integer*4 :: i1,i2
> > write (*,10) i1,i2
> > 10 format (' ',Z8,' ',Z8)
> > return
> > end
> >
> > subroutine update_longwords
> > common /mypsect/ i1,i2
> > c start with putting hex AAAAAAAA into both longwords
> > integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
> > return
> > end
> >
> > subroutine update_words
> > c and update bottom words with BBBB
> > common /mypsect/ w1,w2,w3,w4
> > integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
> > return
> > end
> >
> > subroutine update_bytes
> > c and update bottom bytes with CC
> > common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
> > integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
> > return
> > end
> >
> > program main
> > c by now, the two longwords in the common should be
> > c CCBBAAAA CCBBAAAA
> > call print_common
> > end
> That is horrible code IMHO.
>
> Initializing the same common block in multiple subroutines
> is not something I would ever do.
>
> I would expect either an error or undefined result due to
> order of processing being undefined.
>
> But then I don't know what the Fortran standard and the
> VMS Fortran documentation says on the topic.
>
> Someone is actually using such constructs?
>
> Arne
Well, I expanded it from a customer program. In the broken compiler, each subroutine
with the partial/overlay initialization appended the values to the end. The current
Fortran cross-compiler will create a COMMON block that is several times larger by
mistake. A future compiler will match the Itanium and Alpha output.

Yes, legal Fortran of the day. I don't get to pick and choose which programs to support.

On 1/25/2023 7:48 PM, John Reagan wrote:
> On Wednesday, January 25, 2023 at 6:50:20 PM UTC-5, Arne Vajhøj wrote:
>> That is horrible code IMHO.
>>
>> Initializing the same common block in multiple subroutines
>> is not something I would ever do.
>>
>> I would expect either an error or undefined result due to
>> order of processing being undefined.
>>
>> But then I don't know what the Fortran standard and the
>> VMS Fortran documentation says on the topic.
>>
>> Someone is actually using such constructs?
>
> Well, I expanded it from a customer program. In the broken compiler, each subroutine
> with the partial/overlay initialization appended the values to the end. The current
> Fortran cross-compiler will create a COMMON block that is several times larger by
> mistake. A future compiler will match the Itanium and Alpha output.
>
> Yes, legal Fortran of the day.

Many years ago I did a lot of Fortran, but it has been some years.

As I remember it then good practice was to have the common block itself
in an include to ensure consistency and to only initialize once - either
in a block data which I think was invented for this purpose or some
pre-determined place like the main program.

> I don't get to pick and choose which programs to support.

I understand.

You have probably seen it before, but:
https://xkcd.com/1172/

Arne

On 1/25/2023 7:54 PM, Arne Vajhøj wrote:
>
>
> Many years ago I did a lot of Fortran, but it has been some years.
>
> As I remember it then good practice was to have the common block itself
> in an include to ensure consistency and to only initialize once - either
> in a block data which I think was invented for this purpose or some
> pre-determined place like the main program.
>

As did I. And, at one point I even got to be the front man for support
for the Fortran Compiler on Primos.

Two interesting things I have run into that are loosely related.

We got a complaint from an "engineer" who claimed the compiler was
broken because when he compared reals they never equaled each other.
Prime fixed that one by adding an error message that politely said
"Don't do that, stupid".

But the better one is still available for viewing today. The PL/M
compiler is written in Fortran. It uses a lot of COMMON. The version
I use is somewhat different from the ones you will find on the web.
Mine has all the variables in the same order in all of the COMMON
declarations! And yet it worked for how many years? Points out
another flaw. Obviously all the stuff in COMMON really doesn't need
to be there.

John, I don't envy your job.

bill

On 1/25/2023 6:50 PM, Arne Vajhøj wrote:
> On 1/25/2023 5:55 PM, John Reagan wrote:
>> G2L recurses down the symbol table and converts the static variables in each
>> block as it finds
>> them. The difference is that GEM frontends can record the desired offset into
>> the PSECT in
>> any order. We sort by offset in each block, but we need to hoist all the
>> static variables out in
>> another pass, sort them, and do them all at the module level. PSECTs are
>> created by the linker.
>> They exist outside the control of the compiler.
>>
>> Here's a nasty Fortran program where each subroutine initializes and
>> reinitializes parts of the
>> same common block in a particular order.
>>
>> subroutine print_common
>> common /mypsect/ i1,i2
>> integer*4 :: i1,i2
>> write (*,10) i1,i2
>> 10 format (' ',Z8,' ',Z8)
>> return
>> end
>>
>> subroutine update_longwords
>> common /mypsect/ i1,i2
>> c start with putting hex AAAAAAAA into both longwords
>> integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
>> return
>> end
>>
>> subroutine update_words
>> c and update bottom words with BBBB
>> common /mypsect/ w1,w2,w3,w4
>> integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
>> return
>> end
>>
>> subroutine update_bytes
>> c and update bottom bytes with CC
>> common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
>> integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
>> return
>> end
>>
>> program main
>> c by now, the two longwords in the common should be
>> c CCBBAAAA CCBBAAAA
>> call print_common
>> end
>
> That is horrible code IMHO.

I find that an interesting comment ...

Perhaps it is doing what someone needed it to do ...

> Initializing the same common block in multiple subroutines
> is not something I would ever do.

You've never redefined the data type of some data?

> I would expect either an error or undefined result due to
> order of processing being undefined.
>
> But then I don't know what the Fortran standard and the
> VMS Fortran documentation says on the topic.
>
> Someone is actually using such constructs?
>
> Arne
>

Consider:

Record TLS
Variant
Case
String Rec$=42
Case
Byte Byte1%
Byte VerMajor%
Byte VerMinor%
Long UnixDate%
String Random$=28
Long SessionID%
Word Cypher%
Byte Method%
End Variant
End Record

In this case the Basic RECORD statement allows multiple variants of the same
memory, basically allowing different types of variables to be used on the same
memory location(s). Useful, and a relatively later addition to the language.
Similar to what is called a structure in C and perhaps other languages.

Perhaps some would not want variants, but I for one have used them many times.

Map (D) Long D1%
Map (D) String D1$=4

Now in a MAP statement, whiich is rather similar to a COMMON block, multiple
definitions of the MAP statement allows for a similar redefinition of the same
memory. In the above, a longword value is stored in 4 bytes of memory. The
redefinition of the MAP statement allows the same memory to be labeled as a
string or a longword.

It's been useful to me in the past.

Back in the day, some programmers learned to work around things a language
didn't provide. I'd guess that different implementations of a compiler might
not be quite happy with such work arounds.

Sorry John ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/25/2023 8:07 PM, bill wrote:
> On 1/25/2023 7:54 PM, Arne Vajhøj wrote:
>>
>>
>> Many years ago I did a lot of Fortran, but it has been some years.
>>
>> As I remember it then good practice was to have the common block itself
>> in an include to ensure consistency and to only initialize once - either
>> in a block data which I think was invented for this purpose or some
>> pre-determined place like the main program.
>>
>
> As did I. And, at one point I even got to be the front man for support
> for the Fortran Compiler on Primos.
>
> Two interesting things I have run into that are loosely related.
>
> We got a complaint from an "engineer" who claimed the compiler was
> broken because when he compared reals they never equaled each other.
> Prime fixed that one by adding an error message that politely said
> "Don't do that, stupid".
>
> But the better one is still available for viewing today. The PL/M
> compiler is written in Fortran. It uses a lot of COMMON. The version
> I use is somewhat different from the ones you will find on the web.
> Mine has all the variables in the same order in all of the COMMON
> declarations! And yet it worked for how many years? Points out
> another flaw. Obviously all the stuff in COMMON really doesn't need
> to be there.
>
> John, I don't envy your job.
>
> bill
>

I'm guessing (I know very little about how compilers actually work) that one
reason might be that instead of re-working the compilers to output something
LLVM can use, they are continuing to output what GEM uses, and then translating
that to what LLVM can use. Might sound like a shortcut at first, but, I've got
to believe there are lots of gators in that swamp.

As for the scale of the job to have the compilers product directly what LLVM can
use, I don't have any clue.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/25/2023 8:36 PM, Dave Froble wrote:
> On 1/25/2023 6:50 PM, Arne Vajhøj wrote:
>> On 1/25/2023 5:55 PM, John Reagan wrote:
>>> Here's a nasty Fortran program where each subroutine initializes and
>>> reinitializes parts of the
>>> same common block in a particular order.
>>>
>>>          subroutine print_common
>>>          common /mypsect/ i1,i2
>>>          integer*4 :: i1,i2
>>>          write (*,10) i1,i2
>>> 10      format (' ',Z8,' ',Z8)
>>>          return
>>>          end
>>>
>>>          subroutine update_longwords
>>>          common /mypsect/ i1,i2
>>> c start with putting hex AAAAAAAA into both longwords
>>>          integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
>>>          return
>>>          end
>>>
>>>          subroutine update_words
>>> c and update bottom words with BBBB
>>>          common /mypsect/ w1,w2,w3,w4
>>>          integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
>>>          return
>>>          end
>>>
>>>          subroutine update_bytes
>>> c and update bottom bytes with CC
>>>          common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
>>>          integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
>>>          return
>>>          end
>>>
>>>          program main
>>> c by now, the two longwords in the common should be
>>> c CCBBAAAA CCBBAAAA
>>>          call print_common
>>>          end
>>
>> That is horrible code IMHO.
>
> I find that an interesting comment ...
>
> Perhaps it is doing what someone needed it to do ...

I don't think they did for fun.

But I believe there are better ways to do that.

>> Initializing the same common block in multiple subroutines
>> is not something I would ever do.
>
> You've never redefined the data type of some data?

> Consider:
>
>        Record TLS
>           Variant
>             Case
>                 String  Rec$=42
>             Case
>                 Byte    Byte1%
>                 Byte    VerMajor%
>                 Byte    VerMinor%
>                 Long    UnixDate%
>                 String  Random$=28
>                 Long    SessionID%
>                 Word    Cypher%
>                 Byte    Method%
>           End Variant
>         End Record
>
>
> In this case the Basic RECORD statement allows multiple variants of the
> same memory, basically allowing different types of variables to be used
> on the same memory location(s).  Useful, and a relatively later addition
> to the language. Similar to what is called a structure in C and perhaps
> other languages.

That is really a different thing than initializing the same psect
multiple times in different places.

Having to overlay different types is a common feature in languages.
Pascal got the variant case record similar to the Basic code above.
C got union. In Fortran it can be achieved using common blocks, but
the right way (IMHO) is to use equivalence.

> Perhaps some would not want variants, but I for one have used them many
> times.
>
>         Map (D) Long D1%
>         Map (D) String D1$=4
>
> Now in a MAP statement, whiich is rather similar to a COMMON block,
> multiple definitions of the MAP statement allows for a similar
> redefinition of the same memory.  In the above, a longword value is
> stored in 4 bytes of memory.  The redefinition of the MAP statement
> allows the same memory to be labeled as a string or a longword.
>
> It's been useful to me in the past.

I am not arguing against this.

But in Fortran this should not be done using common blocks but
via equivalence.

integer*4 iv
character*4 sv
equivalence (iv,sv)

It has local scope and is readable.

And if necessary it can be combined with a common block.

In extremely rare cases there may even be a good reason to
have different definition (different types) in different routines.
It is difficult to read as there are no indication in the
individual routine that it has a different definition elsewhere.
But one never knows what can be required to solve a problem.

But I can not believe there are any cases where I would
consider it good to static initialize parts of a common
block in different routines.

Arne

On 1/25/2023 9:24 PM, Arne Vajhøj wrote:
> On 1/25/2023 8:36 PM, Dave Froble wrote:
>> Perhaps some would not want variants, but I for one have used them
>> many times.
>>
>>          Map (D) Long D1%
>>          Map (D) String D1$=4
>>
>> Now in a MAP statement, whiich is rather similar to a COMMON block,
>> multiple definitions of the MAP statement allows for a similar
>> redefinition of the same memory.  In the above, a longword value is
>> stored in 4 bytes of memory.  The redefinition of the MAP statement
>> allows the same memory to be labeled as a string or a longword.
>>
>> It's been useful to me in the past.
>
> I am not arguing against this.
>
> But in Fortran this should not be done using common blocks but
> via equivalence.
>
>       integer*4 iv
>       character*4 sv
>       equivalence (iv,sv)
>
> It has local scope and is readable.
>
> And if necessary it can be combined with a common block.

I am in the lucky situation to have an example.

https://www.vajhoej.dk/arne/articles/vmsipc.html#wrtshrimg_link

Fortran code:

byte mem(memsiz)
common /msgpsect/mem
character*100 msg(maxmsgs)
equivalence (mem,msg)

Basic code:

map (msgpsect) byte mem(memsiz1)
map (msgpsect) string msg(maxmsgs1) = maxmsgsiz

Arne

> [...] but the right way (IMHO) is to use equivalence.

Exactly what I thought when I read it. (Except that I was young when
I used FORTRAN seriously, so I actually thought "EQUIVALENCE".)

On 1/25/2023 9:24 PM, Arne Vajhøj wrote:
> On 1/25/2023 8:36 PM, Dave Froble wrote:
>> On 1/25/2023 6:50 PM, Arne Vajhøj wrote:
>>> On 1/25/2023 5:55 PM, John Reagan wrote:
>>>> Here's a nasty Fortran program where each subroutine initializes and
>>>> reinitializes parts of the
>>>> same common block in a particular order.
>>>>
>>>> subroutine print_common
>>>> common /mypsect/ i1,i2
>>>> integer*4 :: i1,i2
>>>> write (*,10) i1,i2
>>>> 10 format (' ',Z8,' ',Z8)
>>>> return
>>>> end
>>>>
>>>> subroutine update_longwords
>>>> common /mypsect/ i1,i2
>>>> c start with putting hex AAAAAAAA into both longwords
>>>> integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
>>>> return
>>>> end
>>>>
>>>> subroutine update_words
>>>> c and update bottom words with BBBB
>>>> common /mypsect/ w1,w2,w3,w4
>>>> integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
>>>> return
>>>> end
>>>>
>>>> subroutine update_bytes
>>>> c and update bottom bytes with CC
>>>> common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
>>>> integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
>>>> return
>>>> end
>>>>
>>>> program main
>>>> c by now, the two longwords in the common should be
>>>> c CCBBAAAA CCBBAAAA
>>>> call print_common
>>>> end
>>>
>>> That is horrible code IMHO.
>>
>> I find that an interesting comment ...
>>
>> Perhaps it is doing what someone needed it to do ...
>
> I don't think they did for fun.
>
> But I believe there are better ways to do that.
>
>>> Initializing the same common block in multiple subroutines
>>> is not something I would ever do.
>>
>> You've never redefined the data type of some data?
>
>> Consider:
>>
>> Record TLS
>> Variant
>> Case
>> String Rec$=42
>> Case
>> Byte Byte1%
>> Byte VerMajor%
>> Byte VerMinor%
>> Long UnixDate%
>> String Random$=28
>> Long SessionID%
>> Word Cypher%
>> Byte Method%
>> End Variant
>> End Record
>>
>>
>> In this case the Basic RECORD statement allows multiple variants of the same
>> memory, basically allowing different types of variables to be used on the same
>> memory location(s). Useful, and a relatively later addition to the language.
>> Similar to what is called a structure in C and perhaps other languages.
>
> That is really a different thing than initializing the same psect
> multiple times in different places.
>
> Having to overlay different types is a common feature in languages.
> Pascal got the variant case record similar to the Basic code above.
> C got union. In Fortran it can be achieved using common blocks, but
> the right way (IMHO) is to use equivalence.
>
>> Perhaps some would not want variants, but I for one have used them many times.
>>
>> Map (D) Long D1%
>> Map (D) String D1$=4
>>
>> Now in a MAP statement, whiich is rather similar to a COMMON block, multiple
>> definitions of the MAP statement allows for a similar redefinition of the same
>> memory. In the above, a longword value is stored in 4 bytes of memory. The
>> redefinition of the MAP statement allows the same memory to be labeled as a
>> string or a longword.
>>
>> It's been useful to me in the past.
>
> I am not arguing against this.
>
> But in Fortran this should not be done using common blocks but
> via equivalence.
>
> integer*4 iv
> character*4 sv
> equivalence (iv,sv)
>
> It has local scope and is readable.
>
> And if necessary it can be combined with a common block.
>
> In extremely rare cases there may even be a good reason to
> have different definition (different types) in different routines.
> It is difficult to read as there are no indication in the
> individual routine that it has a different definition elsewhere.
> But one never knows what can be required to solve a problem.
>
> But I can not believe there are any cases where I would
> consider it good to static initialize parts of a common
> block in different routines.
>
> Arne
>

I will admit that my normal practice is to have any such declarations in one
place, and include the same definition is each subroutine that uses it. Of
course, if it is modified, one must re-compile all routines that include it.

:-)

I can be a little dense, but I fail to see the problem in John's example. If I
understand it correctly, each routine defines the same PSECT (I believe each
common block has it's own PSECT, a Basic MAP statement I'm rather sure does so)
with a different definition. So what? And yes, it might be confusing to some.

Then again, it's been over 40 years since I did any Fortran.

And that brings this question. What does:

integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X

do?

Does both w1 and w2 get set to BBBB? That is not what the comments indicate?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-01-25, bill <bill.gunshannon@gmail.com> wrote:
>
> We got a complaint from an "engineer" who claimed the compiler was
> broken because when he compared reals they never equaled each other.
> Prime fixed that one by adding an error message that politely said
> "Don't do that, stupid".
>

Oh, for goodness sake. :-( Not that again. :-(

I am of the opinion that direct testing for equality of floating point
numbers should be disallowed by every language and that people should
be forced to use an alternative where _they_ have to specify the delta
value that 2 numbers should be within before they are considered to be
equal.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-01-26, Steven Schweda <sms.antinode@gmail.com> wrote:
>> [...] but the right way (IMHO) is to use equivalence.
>
> Exactly what I thought when I read it. (Except that I was young when
> I used FORTRAN seriously, so I actually thought "EQUIVALENCE".)

Of course, these days, we are no longer forced to use ASR-33 keyboards. :-)

Simon.

PS: $ set response/mode=good_natured :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/26/2023 2:06 AM, Dave Froble wrote:
> On 1/25/2023 9:24 PM, Arne Vajhøj wrote:
>> On 1/25/2023 8:36 PM, Dave Froble wrote:
>>> Now in a MAP statement, whiich is rather similar to a COMMON block,
>>> multiple
>>> definitions of the MAP statement allows for a similar redefinition of
>>> the same
>>> memory.  In the above, a longword value is stored in 4 bytes of
>>> memory.  The
>>> redefinition of the MAP statement allows the same memory to be
>>> labeled as a
>>> string or a longword.
>>>
>>> It's been useful to me in the past.
>>
>> I am not arguing against this.
>>
>> But in Fortran this should not be done using common blocks but
>> via equivalence.
>>
>>       integer*4 iv
>>       character*4 sv
>>       equivalence (iv,sv)
>>
>> It has local scope and is readable.
>>
>> And if necessary it can be combined with a common block.
>>
>> In extremely rare cases there may even be a good reason to
>> have different definition (different types) in different routines.
>> It is difficult to read as there are no indication in the
>> individual routine that it has a different definition elsewhere.
>> But one never knows what can be required to solve a problem.
>>
>> But I can not believe there are any cases where I would
>> consider it good to static initialize parts of a common
>> block in different routines.
>
> I will admit that my normal practice is to have any such declarations in
> one place, and include the same definition is each subroutine that uses
> it.  Of course, if it is modified, one must re-compile all routines that
> include it.
>
> :-)

Yep.

> I can be a little dense, but I fail to see the problem in John's
> example.  If I understand it correctly, each routine defines the same
> PSECT (I believe each common block has it's own PSECT, a Basic MAP
> statement I'm rather sure does so) with a different definition.  So
> what?  And yes, it might be confusing to some.

I think there are 3 problems:
A) different definition of the common block in different routines
B) initialization of the the data in multiple routines
C) A and B combined in such a way that the initialization partly overlaps

which I consider bad, very bad and disaster.

> And that brings this question.  What does:
>
> integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
>
> do?
>
> Does both w1 and w2 get set to BBBB?  That is not what the comments
> indicate?

I think it only initialize w2 (and w4).

I am so old that I use data statement for initialization.

:-)

Arne

On 1/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-01-25, bill <bill.gunshannon@gmail.com> wrote:
>> We got a complaint from an "engineer" who claimed the compiler was
>> broken because when he compared reals they never equaled each other.
>> Prime fixed that one by adding an error message that politely said
>> "Don't do that, stupid".
>
> Oh, for goodness sake. :-( Not that again. :-(
>
> I am of the opinion that direct testing for equality of floating point
> numbers should be disallowed by every language and that people should
> be forced to use an alternative where _they_ have to specify the delta
> value that 2 numbers should be within before they are considered to be
> equal.

That sounds pretty tempting.

Note that most unit frameworks today require a delta
parameter for floating point "areequals" tests.

Arne

On 1/26/2023 8:58 AM, Arne Vajhøj wrote:
> On 1/26/2023 2:06 AM, Dave Froble wrote:
>> I can be a little dense, but I fail to see the problem in John's
>> example.  If I understand it correctly, each routine defines the same
>> PSECT (I believe each common block has it's own PSECT, a Basic MAP
>> statement I'm rather sure does so) with a different definition.  So
>> what?  And yes, it might be confusing to some.
>
> I think there are 3 problems:
> A) different definition of the common block in different routines
> B) initialization of the the data in multiple routines
> C) A and B combined in such a way that the initialization partly overlaps
>
> which I consider bad, very bad and disaster.
>
>> And that brings this question.  What does:
>>
>> integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
>>
>> do?
>>
>> Does both w1 and w2 get set to BBBB?  That is not what the comments
>> indicate?
>
> I think it only initialize w2 (and w4).
>
> I am so old that I use data statement for initialization.
>
> :-)

I do not think the exact same problem can be recreated in
Basic (as far as I can read the documentation then Basic
does not allow static initialization in map's).

But to show something in Basic it is easy to do with
assignment:

program p

map (d) long lw1, long lw2

external sub s1, s2

lw1 = 1
lw2 = 2

call s1
call s2

print lw1, lw2

end program
! sub s1

map (d) word w1, word w2, word w3, word w4

w2 = 1
w4 = 2

end sub
! sub s2

map (d) byte b1, byte b2, byte b3, byte b4, byte b5, byte b6, byte b7,
byte b8

b4 = 1
b8 = 2

end sub

$ bas p
$ lin p
$ r p
16842753 33685506

Arne

On 1/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-01-25, bill <bill.gunshannon@gmail.com> wrote:
>>
>> We got a complaint from an "engineer" who claimed the compiler was
>> broken because when he compared reals they never equaled each other.
>> Prime fixed that one by adding an error message that politely said
>> "Don't do that, stupid".
>>
>
> Oh, for goodness sake. :-( Not that again. :-(
>
> I am of the opinion that direct testing for equality of floating point
> numbers should be disallowed by every language and that people should
> be forced to use an alternative where _they_ have to specify the delta
> value that 2 numbers should be within before they are considered to be
> equal.
>
> Simon.
>

Well, "have to" or not, that is the only method that works ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Thu, 2023-01-26 at 11:50 -0500, Dave Froble wrote:
>

> > I am of the opinion that direct testing for equality of floating
> > point numbers should be disallowed by every language and that
> > people should be forced to use an alternative where _they_ have to
> > specify the delta value that 2 numbers should be within before they
> > are considered to be equal.
> >
> > Simon.
> >
>
> Well, "have to" or not, that is the only method that works ...

Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..

--
Tactical Nuclear Kittens

On 1/26/2023 12:05 PM, Single Stage to Orbit wrote:
> On Thu, 2023-01-26 at 11:50 -0500, Dave Froble wrote:
>>> I am of the opinion that direct testing for equality of floating
>>> point numbers should be disallowed by every language and that
>>> people should be forced to use an alternative where _they_ have to
>>> specify the delta value that 2 numbers should be within before they
>>> are considered to be equal.
>>
>> Well, "have to" or not, that is the only method that works ...
>
> Or use rounding: IF Math.Round(x,2) = Math.Round(x,2) THEN ..

VB.NET?

IF Math.Round(x,2) = Math.Round(y,2) THEN

and:

IF Math.Abs(x - y) < 0.01 THEN

are not fully equivalent.

Arne

On 1/26/2023 9:32 AM, Arne Vajhøj wrote:
> I do not think the exact same problem can be recreated in
> Basic (as far as I can read the documentation then Basic
> does not allow static initialization in map's).
>
> But to show something in Basic it is easy to do with
> assignment:
>
> program p
>
> map (d) long lw1, long lw2
>
> external sub s1, s2
>
> lw1 = 1
> lw2 = 2
>
> call s1
> call s2
>
> print lw1, lw2
>
> end program
> !
> sub s1
>
> map (d) word w1, word w2, word w3, word w4
>
> w2 = 1
> w4 = 2
>
> end sub
> !
> sub s2
>
> map (d) byte b1, byte b2, byte b3, byte b4, byte b5, byte b6, byte b7,
> byte b8
>
> b4 = 1
> b8 = 2
>
> end sub
>
> $ bas p
> $ lin p
> $ r p
>  16842753      33685506

The Fortran version with static initialization (using data statements!)
and no calls:

$ type p2x.for
program p2
integer*4 lw1,lw2
common /d/lw1,lw2
data lw1/1/,lw2/2/
write(*,*) lw1,lw2
end
$ for p2x
$ type s1.for
subroutine s1
integer*2 w1,w2,w3,w4
common /d/w1,w2,w3,w4
data w2/1/,w4/2/
end
$ for s1
$ type s2.for
subroutine s2
integer*1 b1,b2,b3,b4,b5,b6,b7,b8
common /d/b1,b2,b3,b4,b5,b6,b7,b8
data b4/1/,b8/2/
end
$ for s2
$ link p2x + s1 + s2
$ run p2x
16842753 33685506
$ link p2x + s2 + s1
$ run p2x
65537 131074

(tested on VMS Alpha)

The order of the OBJ files in the link command change the output.

Yuck.

Arne