VMS Software Q1 '23 Update

[Jan-Erik Söderholm]

I missed this "Webinar" on Tuesday last week.
Anyone seen a recording?
Or was anyone joining online?

Jan-Erik.

[Simon Clubley]

On 2023-01-18, Jan-Erik Söderholm <jan-***@telia.com> wrote:
> I missed this "Webinar" on Tuesday last week.
> Anyone seen a recording?
> Or was anyone joining online?
>
> Jan-Erik.

IIRC, on the announcement, they said if you registered, they would
send you a link to the recording if it wasn't convenient for you
to join live, so they are clearly planning to make a recording available.

Simon.

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

[Jan-Erik Söderholm]

Den 2023-01-18 kl. 14:08, skrev Simon Clubley:
> On 2023-01-18, Jan-Erik Söderholm <jan-***@telia.com> wrote:
>> I missed this "Webinar" on Tuesday last week.
>> Anyone seen a recording?
>> Or was anyone joining online?
>>
>> Jan-Erik.
>
> IIRC, on the announcement, they said if you registered, they would
> send you a link to the recording if it wasn't convenient for you
> to join live, so they are clearly planning to make a recording available.
>
> Simon.
>

OK. I had registered but missed it.
The Zoom link in the invite is dead today (as expected).
I have not got any other information.
The event is not linked from the home page webinar page.

We'll see... :-)

Jan-Erik.

[John H Reinhardt]

On 1/18/2023 8:37 AM, Jan-Erik Söderholm wrote:
> Den 2023-01-18 kl. 14:08, skrev Simon Clubley:
>> On 2023-01-18, Jan-Erik Söderholm <jan-***@telia.com> wrote:
>>> I missed this "Webinar" on Tuesday last week.
>>> Anyone seen a recording?
>>> Or was anyone joining online?
>>>
>>> Jan-Erik.
>>
>> IIRC, on the announcement, they said if you registered, they would
>> send you a link to the recording if it wasn't convenient for you
>> to join live, so they are clearly planning to make a recording available.
>>
>> Simon.
>>
>
> OK. I had registered but missed it.
> The Zoom link in the invite is dead today (as expected).
> I have not got any other information.
> The event is not linked from the home page webinar page.
>
> We'll see... :-)
>
> Jan-Erik.

I was wondering the same thing. I checked the YouTube channel but nothing new there since last March's update. Hopefully they will post one soon.

John H. Reinhardt

[Ian Miller]

On Wednesday, January 18, 2023 at 3:19:31 PM UTC, John H Reinhardt wrote:
> On 1/18/2023 8:37 AM, Jan-Erik Söderholm wrote:
> > Den 2023-01-18 kl. 14:08, skrev Simon Clubley:
> >> On 2023-01-18, Jan-Erik Söderholm <jan-***@telia.com> wrote:
> >>> I missed this "Webinar" on Tuesday last week.
> >>> Anyone seen a recording?
> >>> Or was anyone joining online?
> >>>
> >>> Jan-Erik.
> >>
> >> IIRC, on the announcement, they said if you registered, they would
> >> send you a link to the recording if it wasn't convenient for you
> >> to join live, so they are clearly planning to make a recording available.
> >>
> >> Simon.
> >>
> >
> > OK. I had registered but missed it.
> > The Zoom link in the invite is dead today (as expected).
> > I have not got any other information.
> > The event is not linked from the home page webinar page.
> >
> > We'll see... :-)
> >
> > Jan-Erik.
> I was wondering the same thing. I checked the YouTube channel but nothing new there since last March's update. Hopefully they will post one soon.
>
> John H. Reinhardt


webinar is now available https://vmssoftware.com/about/webinars/

[Simon Clubley]

On 2023-01-24, Ian Miller <***@uk2.net> wrote:
>
> webinar is now available https://vmssoftware.com/about/webinars/

Some interesting stuff in the attached PDF at:

https://vmssoftware.com/docs/2022_accomplishments_webinar_20230110.pdf

|Any news on an Ada compiler for OpenVMS x86?
|
|We have no plans to provide an Ada compiler due to insufficient customer
|demand.

Another year to wait for RDB (Q1, 2024).

There are no longer any current plans for bare metal support:

|Need specs for an x86 system to run VMS directly without a hypervisor.
|
|We have currently allocated all R&D resources to the development of OpenVMS
|running on virtualized environments to meet most customer needs and
|requirements. There are no specific plans to support bare metal, but customer
|requests will be carefully considered. Please contact us with your specific needs.

Efforts to expand the VMS userbase have been abandoned:

|Are there any sales efforts for OpenVMS to take back industry market share
|from other operating systems that later "replaced" VMS? Or bid on new
|industrial projects that would run on VMS?
|
|Our primary objective is to provide current OpenVMS users with the
|opportunity to protect their investments in OpenVMS-based applications
|without a technical deadline.

In reality, I suppose this is just confirming what everyone in their
heart really knew (even if some were not willing to admit it. :-))

This one got my attention big time. I thought this was a current project:

|What position does PostgreSQL have on the list of opensource software?
|
|We have no plans to port PostgreSQL to OpenVMS.

Huh ?

Simon.

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

[John Dallman]

In article <tqp7bm$871q$***@dont-email.me>,
***@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> There are no longer any current plans for bare metal support:

That is not surprising. I'm having to provide comprehensive
justifications for running /any/ server OS on bare metal. This applies
even where it's much more efficient (because of natural code segment
sharing when running many copies of a large application for testing).

The current fashion among corporate sysadmins is "VMWare for everything."
It gives them more of a feeling of power, because they expect they can
bluff their way out of hard work requested by users or manager who don't
understand virtualisation.

> Efforts to expand the VMS userbase have been abandoned:

Given VSI's fairly limited resources, getting the existing customers
thoroughly supported seems the best idea for the next couple of years.
Trying to take back long-departed customers when they don't have a
comprehensively modern offering is likely futile.

Applications that have migrated off VMS have been updated a lot since
then. For example, the code I work on was originally developed on VAX/VMS,
using VMS C in pre-ANSI C days. Nowadays it will need C++20 by mid-summer,
and Clang 10 doesn't provide that.

John

[Arne Vajhøj]

On 1/24/2023 2:33 PM, John Dallman wrote:
> In article <tqp7bm$871q$***@dont-email.me>,
> ***@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>> There are no longer any current plans for bare metal support:
>
> That is not surprising. I'm having to provide comprehensive
> justifications for running /any/ server OS on bare metal. This applies
> even where it's much more efficient (because of natural code segment
> sharing when running many copies of a large application for testing).
>
> The current fashion among corporate sysadmins is "VMWare for everything."
> It gives them more of a feeling of power, because they expect they can
> bluff their way out of hard work requested by users or manager who don't
> understand virtualisation.

I think the general landscape is a bit broader:
* VM's on VMWare (or in some cases Hyper-V) in own data center
* k8s containers managed by OpenShift or Tanzu in own data center
* VM's in public cloud
* k8s containers in public cloud

But the traditional model with no VM/container at all is
certainly getting very rare.

VM's/containers are way more flexible. And when servers
comes with like 32c64t per socket then just running a single
server on the hardware makes little sense.

VMS will not support k8s containers the next 10 years - probably
never, so VM's is the obvious choice.

And it avoids the problem of the crazy huge diversity in
x86-64 hardware.

The two biggest groups of VMS users in the coming years will be:
- those that like VM's because it fits nicely into the
corporate infrastructure strategy
- those that can live with VM's because it really doesn't
matter

If there are some users that cannot live with VM's, then they
should tell VSI. Then VSI will hopefully put one or two
physical machines on the supported list.

But no reason to expect VSI to spend money on this until
actually customers ask for it.

Arne

[Dave Froble]

On 1/24/2023 1:17 PM, Simon Clubley wrote:
> On 2023-01-24, Ian Miller <***@uk2.net> wrote:
>>
>> webinar is now available https://vmssoftware.com/about/webinars/
>
> Some interesting stuff in the attached PDF at:
>
> https://vmssoftware.com/docs/2022_accomplishments_webinar_20230110.pdf
>
> |Any news on an Ada compiler for OpenVMS x86?
> |
> |We have no plans to provide an Ada compiler due to insufficient customer
> |demand.
>
> Another year to wait for RDB (Q1, 2024).
>
> There are no longer any current plans for bare metal support:

Phillip will be howling at the moon ...

> |Need specs for an x86 system to run VMS directly without a hypervisor.
> |
> |We have currently allocated all R&D resources to the development of OpenVMS
> |running on virtualized environments to meet most customer needs and
> |requirements. There are no specific plans to support bare metal, but customer
> |requests will be carefully considered. Please contact us with your specific needs.
>
> Efforts to expand the VMS userbase have been abandoned:

Well, that's not so clear. We've all read about how so many are now using VM
environments.

VM environments is not going to satisfy some requirements. If I'm running a
nuclear power station, I would not choose (or allow) a VM environment for
critical stuff.

> |Are there any sales efforts for OpenVMS to take back industry market share
> |from other operating systems that later "replaced" VMS? Or bid on new
> |industrial projects that would run on VMS?
> |
> |Our primary objective is to provide current OpenVMS users with the
> |opportunity to protect their investments in OpenVMS-based applications
> |without a technical deadline.
>
> In reality, I suppose this is just confirming what everyone in their
> heart really knew (even if some were not willing to admit it. :-))

Well, yeah, to some extent.

> This one got my attention big time. I thought this was a current project:
>
> |What position does PostgreSQL have on the list of opensource software?
> |
> |We have no plans to port PostgreSQL to OpenVMS.

With some retiring, and possibly others leaving, perhaps VSI just isn't making
enough money for all we'd wish they would do. I too thought they had promised this.

Now I wonder when they will announce the unavailability of a Basic compiler?


--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dan Cross]

In article <tqpg77$9pjt$***@dont-email.me>,
Dave Froble <***@tsoft-inc.com> wrote:
>> Efforts to expand the VMS userbase have been abandoned:
>
>Well, that's not so clear. We've all read about how so many are now using VM
>environments.
>
>VM environments is not going to satisfy some requirements. If I'm running a
>nuclear power station, I would not choose (or allow) a VM environment for
>critical stuff.

I think it's worse than that: they're not just talking
about bare metal, but about new VMS users on any platform.
That is, they are saying they will target existing, legacy
customers on hypervisors but aren't even trying to expand
to new customers of any sort at this time.

That's too bad.

- Dan C.

[Craig A. Berry]

On 1/24/23 2:48 PM, Dave Froble wrote:

> Now I wonder when they will announce the unavailability of a Basic
> compiler?

It's disappeared from the roadmap and during the webinar Vadim Ilves
(head of R & D) said maybe this year in a tone of voice that implied
probably not this year. Fortran, COBOL, and Pascal will definitely be
before it.

[Arne Vajhøj]

On 1/24/2023 6:22 PM, Craig A. Berry wrote:
> On 1/24/23 2:48 PM, Dave Froble wrote:
>> Now I wonder when they will announce the unavailability of a Basic
>> compiler?
>
> It's disappeared from the roadmap and during the webinar Vadim Ilves
> (head of R & D) said maybe this year in a tone of voice that implied
> probably not this year.

The PDF says:

<quote>
Is native BASIC compiler expected in 2023? The roadmap web page does not
explicitly mention it.
We expect to provide BASIC during 2023.
</quote>

I did not listen to the webinar, so I do not know the tone it was said.

Arne

[Craig A. Berry]

On 1/25/23 10:40 AM, Arne Vajhøj wrote:
> On 1/24/2023 6:22 PM, Craig A. Berry wrote:
>> On 1/24/23 2:48 PM, Dave Froble wrote:
>>> Now I wonder when they will announce the unavailability of a Basic
>>> compiler?
>>
>> It's disappeared from the roadmap and during the webinar Vadim Ilves
>> (head of R & D) said maybe this year in a tone of voice that implied
>> probably not this year.
>
> The PDF says:
>
> <quote>
> Is native BASIC compiler expected in 2023? The roadmap web page does not
> explicitly mention it.
> We expect to provide BASIC during 2023.
> </quote>
>
> I did not listen to the webinar, so I do not know the tone it was said.


Starting at 19:38 in the webinar:

"Our goal is to have all compilers except for BASIC by the end of this
year. I can't make any promises regarding BASIC...."

[Arne Vajhøj]

On 1/25/2023 11:43 AM, Craig A. Berry wrote:
> On 1/25/23 10:40 AM, Arne Vajhøj wrote:
>> On 1/24/2023 6:22 PM, Craig A. Berry wrote:
>>> On 1/24/23 2:48 PM, Dave Froble wrote:
>>>> Now I wonder when they will announce the unavailability of a Basic
>>>> compiler?
>>>
>>> It's disappeared from the roadmap and during the webinar Vadim Ilves
>>> (head of R & D) said maybe this year in a tone of voice that implied
>>> probably not this year.
>>
>> The PDF says:
>>
>> <quote>
>> Is native BASIC compiler expected in 2023? The roadmap web page does
>> not explicitly mention it.
>> We expect to provide BASIC during 2023.
>> </quote>
>>
>> I did not listen to the webinar, so I do not know the tone it was said.
>
>
> Starting at 19:38 in the webinar:
>
> "Our goal is to have all compilers except for BASIC by the end of this
> year.  I can't make any promises regarding BASIC...."

The PDF seems to have been "polished" then.

Arne

[Arne Vajhøj]

On 1/25/2023 11:40 AM, Arne Vajhøj wrote:
> On 1/24/2023 6:22 PM, Craig A. Berry wrote:
>> On 1/24/23 2:48 PM, Dave Froble wrote:
>>> Now I wonder when they will announce the unavailability of a Basic
>>> compiler?
>>
>> It's disappeared from the roadmap and during the webinar Vadim Ilves
>> (head of R & D) said maybe this year in a tone of voice that implied
>> probably not this year.
>
> The PDF says:
>
> <quote>
> Is native BASIC compiler expected in 2023? The roadmap web page does not
> explicitly mention it.
> We expect to provide BASIC during 2023.
> </quote>
>
> I did not listen to the webinar, so I do not know the tone it was said.

But I strongly suspect that they must have hit some
technical issues.

It is late. And there are indications that it will be the last
language to get native compilers.

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.

So I suspect technical issues. LLVM supports C, C++ and
Fortran out of the box, so no language problem with them.
Supposedly there exist a Delphi/FPC frontend as well, so VMS Pascal
should be doable as well even though it differs quite a bit.
VMS Cobol apparently do not cause problems. But VMS Basic
is a pretty advanced language and it is very different from
other Basic dialects so any previous LLVM work like for FBC
is probably useless.

Arne

[Simon Clubley]

On 2023-01-25, Arne Vajhøj <***@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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Arne Vajhøj]

On 1/25/2023 1:14 PM, Simon Clubley wrote:
> 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 ?

Probably a bit impatient.

But the reality is that there are lots of things not ready yet.

The most problematic thing is probably the missing native
compilers.

I believe the migrations will not really take off until they
are available. Cross compilers on Itanium is not enough
(the VMS tradition is to compile on the target, relying
on Itanium a dead platform is risky, some VMS shops are still
on Alpha so do not even have Itanium).

Then those relying on Rdb will also need to
wait for that becoming available..

Things take time.

My crystal ball says that it will at least be late 2025
until VMS x86-64 passes 50% of VMS mark.

Arne

[John Reagan]

On Wednesday, January 25, 2023 at 1:14:40 PM UTC-5, Simon Clubley wrote:
> On 2023-01-25, Arne Vajhøj <***@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, ***@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.

[Arne Vajhøj]

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

[John Reagan]

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

[Arne Vajhøj]

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

[John Reagan]

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.

[Arne Vajhøj]

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

[bill]

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

[Dave Froble]

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: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Simon Clubley]

On 2023-01-25, bill <***@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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Arne Vajhøj]

On 1/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-01-25, bill <***@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

[Dave Froble]

On 1/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-01-25, bill <***@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: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Single Stage to Orbit]

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

[Arne Vajhøj]

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

[Simon Clubley]

On 2023-01-26, Arne Vajhøj <***@vajhoej.dk> wrote:
> 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 ..

You are still directly comparing two approximations and as Arne points
out, it's not the same thing as using a delta value

>
> 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.
>

This is the only method that is truly robust when you are comparing
approximations instead of exact values.

(This assumes Abs() in the above example is really a floating point Abs()
instead of an integer Abs()).

Simon.

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

[Arne Vajhøj]

On 1/27/2023 1:44 PM, Simon Clubley wrote:
> On 2023-01-26, Arne Vajhøj <***@vajhoej.dk> wrote:
>> 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 ..
>
> You are still directly comparing two approximations

.NET spec for Round guarantees the best approximation.

> and as Arne points
> out, it's not the same thing as using a delta value

Yep.

>> 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.
>
> This is the only method that is truly robust when you are comparing
> approximations instead of exact values.

I think the optimal method depends on the context. And even
with the last method there is the big question of what is the right
value for the epsilon - there is no magic right answer.

In some contexts the relative difference may be better than the
absolute difference:

IF Math.Abs(x / y - 1.0) < 0.001 THEN

> (This assumes Abs() in the above example is really a floating point Abs()
> instead of an integer Abs()).

.NET has 8 overloads of Abs:

Abs(double) -> double
Abs(decimal) -> decimal
Abs(double,int) -> double
Abs(decimal,int) -> decimal
Abs(double,roundingmode) -> double
Abs(decimal,roundingmode) -> decimal
Abs(double,int,roundingmode) -> double
Abs(decimal,int,roundingmode) -> decimal

Arne

[Steven Schweda]

> I am not saying that one is better than the other [...]

I am. A reasonable test for approximate equality looks for a "small"
(absolute) difference between two values. Expecting two extremely close
values to round to the same value is not reasonable. (That is, it
doesn't always happen.)

"Equal when rounded" might seem plausible at first glance, but (even)
a little thought would reveal that it's an inferior test (because it
gives goofy results for values close to a round-down/up decision value).


> I think the optimal method depends on the context. And even
> with the last method there is the big question of what is the right
> value for the epsilon - there is no magic right answer.

Choosing a good parameter for a good test is important, but choosing
a good parameter for a good test should not be confused with choosing
between a good test and a foolish test.

[Arne Vajhøj]

On 1/28/2023 12:46 AM, Steven Schweda wrote:
>> I am not saying that one is better than the other [...]
>
> I am. A reasonable test for approximate equality looks for a "small"
> (absolute) difference between two values.

Absolute difference is sensitive to the scale
of the data.

Sometimes relative difference makes more sense.

> Expecting two extremely close
> values to round to the same value is not reasonable. (That is, it
> doesn't always happen.)
>
> "Equal when rounded" might seem plausible at first glance, but (even)
> a little thought would reveal that it's an inferior test (because it
> gives goofy results for values close to a round-down/up decision value).

Consider the case where the numbers represent money.

The difference between 2.494 dollar/euro and 2.496 dollar/euro
are less than 0.01 but ...

Arne

[Simon Clubley]

On 2023-01-28, Arne Vajhøj <***@vajhoej.dk> wrote:
> On 1/28/2023 12:46 AM, Steven Schweda wrote:
>>> I am not saying that one is better than the other [...]
>>
>> I am. A reasonable test for approximate equality looks for a "small"
>> (absolute) difference between two values.
>
> Absolute difference is sensitive to the scale
> of the data.
>
> Sometimes relative difference makes more sense.
>
>> Expecting two extremely close
>> values to round to the same value is not reasonable. (That is, it
>> doesn't always happen.)
> >
>> "Equal when rounded" might seem plausible at first glance, but (even)
>> a little thought would reveal that it's an inferior test (because it
>> gives goofy results for values close to a round-down/up decision value).
>
> Consider the case where the numbers represent money.
>
> The difference between 2.494 dollar/euro and 2.496 dollar/euro
> are less than 0.01 but ...
>

Hmmm. Do you own a red stapler by any chance ? :-)

Simon.

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

[Steven Schweda]

> [...] a "small" (absolute) difference between two values. [...]


> Absolute difference is sensitive to the scale
> of the data.

_My_ "absolute" was in the sense of "absolute value", as in
Math.Abs(). Any dependence on the scale was built into '"small"', not
"absolute". Hence the quotation marks around '"small"'.


> Consider the case where the numbers represent money.

Who cares what the numbers represent? For example, if you round to
the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
but one rounds to 1, and the other to 2, so the lame test says that
they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
both round to 2, so the lame test says that they're "equal". Any test
which treats a difference of 0.00002 as significant, and a difference of
0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
of what the numbers might represent.

[Arne Vajhøj]

On 1/28/2023 3:01 PM, Steven Schweda wrote:
>> Consider the case where the numbers represent money.
>
> Who cares what the numbers represent? For example, if you round to
> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
> but one rounds to 1, and the other to 2, so the lame test says that
> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
> both round to 2, so the lame test says that they're "equal". Any test
> which treats a difference of 0.00002 as significant, and a difference of
> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
> of what the numbers might represent.

There are some specific rules for money usually about
always rounding 2 digits.

1494 dollars divided by 1000 = 1.494 get rounded to 1.49
diff 0.002 not equal
1496 dollars divided by 1000 = 1.496 get rounded to 1.50

1496 dollars divided by 1000 = 1.496 get rounded to 1.50
diff 0.008 equal
1504 dollars divided by 1000 = 1.504 get rounded to 1.50

Arne

PS: One should never use traditional binary based floating
point for storing money instead use some decimal based
type. But sometimes calculations switch to floating point
anyway.

[Johnny Billquist]

On 2023-01-28 23:35, Arne Vajhøj wrote:
> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>> Consider the case where the numbers represent money.
>>
>>     Who cares what the numbers represent?  For example, if you round to
>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>> but one rounds to 1, and the other to 2, so the lame test says that
>> they're "unequal".  And 1.50001 and 2.49999 differ by 0.99998, but they
>> both round to 2, so the lame test says that they're "equal".  Any test
>> which treats a difference of 0.00002 as significant, and a difference of
>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>> of what the numbers might represent.
>
> There are some specific rules for money usually about
> always rounding 2 digits.
>
> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>                               diff 0.002          not equal
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>                               diff 0.008            equal
> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
> Arne
>
> PS: One should never use traditional binary based floating
>     point for storing money instead use some decimal based
>     type. But sometimes calculations switch to floating point
>     anyway.

So by your own example, two values differing by 0.002 could be
considered not equal, but two values differing by 0.008 could be
considered equal. Don't you see that this leads to a very bad algorithm
for comparing for approximate equal?

More generally, 0.002 of difference might be considered equal or not
equal purely based on what the actual values are. For some, they will be
equal, and for some others not. The delta that is required for two
numbers to be considered unequal varies based on what the actual numbers
are.

At least in my book, that is a clear indication that it's a very bad method.

Johnny

[Arne Vajhøj]

On 1/28/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-01-28 23:35, Arne Vajhøj wrote:
>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>> Consider the case where the numbers represent money.
>>>
>>>     Who cares what the numbers represent?  For example, if you round to
>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>> but one rounds to 1, and the other to 2, so the lame test says that
>>> they're "unequal".  And 1.50001 and 2.49999 differ by 0.99998, but they
>>> both round to 2, so the lame test says that they're "equal".  Any test
>>> which treats a difference of 0.00002 as significant, and a difference of
>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>> of what the numbers might represent.
>>
>> There are some specific rules for money usually about
>> always rounding 2 digits.
>>
>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>>                                diff 0.002          not equal
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>                                diff 0.008            equal
>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50

> So by your own example, two values differing by 0.002 could be
> considered not equal, but two values differing by 0.008 could be
> considered equal. Don't you see that this leads to a very bad algorithm
> for comparing for approximate equal?
>
> More generally, 0.002 of difference might be considered equal or not
> equal purely based on what the actual values are. For some, they will be
> equal, and for some others not. The delta that is required for two
> numbers to be considered unequal varies based on what the actual numbers
> are.
>
> At least in my book, that is a clear indication that it's a very bad
> method.

I am not sure that I get your point.

This is how rounding of money works.

Software that operate on money needs to implement
the rules.

Same reason that good rounding supports different
rounding mode: UP (round .5 up), EVEN (round .5 to
even) etc.. Different places has different rules and
the software need to implement those.

Arne

[Dave Froble]

On 1/28/2023 7:25 PM, Arne Vajhøj wrote:
> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>> Consider the case where the numbers represent money.
>>>>
>>>> Who cares what the numbers represent? For example, if you round to
>>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>>> but one rounds to 1, and the other to 2, so the lame test says that
>>>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>>>> both round to 2, so the lame test says that they're "equal". Any test
>>>> which treats a difference of 0.00002 as significant, and a difference of
>>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>>> of what the numbers might represent.
>>>
>>> There are some specific rules for money usually about
>>> always rounding 2 digits.
>>>
>>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>>> diff 0.002 not equal
>>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>>
>>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>> diff 0.008 equal
>>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
>> So by your own example, two values differing by 0.002 could be considered not
>> equal, but two values differing by 0.008 could be considered equal. Don't you
>> see that this leads to a very bad algorithm for comparing for approximate equal?
>>
>> More generally, 0.002 of difference might be considered equal or not equal
>> purely based on what the actual values are. For some, they will be equal, and
>> for some others not. The delta that is required for two numbers to be
>> considered unequal varies based on what the actual numbers are.
>>
>> At least in my book, that is a clear indication that it's a very bad method.
>
> I am not sure that I get your point.
>
> This is how rounding of money works.
>
> Software that operate on money needs to implement
> the rules.
>
> Same reason that good rounding supports different
> rounding mode: UP (round .5 up), EVEN (round .5 to
> even) etc.. Different places has different rules and
> the software need to implement those.
>
> Arne

Perhaps you mean .005 ???


--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/28/2023 8:19 PM, Dave Froble wrote:
> On 1/28/2023 7:25 PM, Arne Vajhøj wrote:
>> Same reason that good rounding supports different
>> rounding mode: UP (round .5 up), EVEN (round .5 to
>> even) etc.. Different places has different rules and
>> the software need to implement those.
>
> Perhaps you mean .005 ???

With 2 decimals then yes.

Arne

[Dave Froble]

On 1/28/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-01-28 23:35, Arne Vajhøj wrote:
>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>> Consider the case where the numbers represent money.
>>>
>>> Who cares what the numbers represent? For example, if you round to
>>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>>> but one rounds to 1, and the other to 2, so the lame test says that
>>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>>> both round to 2, so the lame test says that they're "equal". Any test
>>> which treats a difference of 0.00002 as significant, and a difference of
>>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>>> of what the numbers might represent.
>>
>> There are some specific rules for money usually about
>> always rounding 2 digits.
>>
>> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
>> diff 0.002 not equal
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>>
>> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>> diff 0.008 equal
>> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>>
>> Arne
>>
>> PS: One should never use traditional binary based floating
>> point for storing money instead use some decimal based
>> type. But sometimes calculations switch to floating point
>> anyway.
>
> So by your own example, two values differing by 0.002 could be considered not
> equal, but two values differing by 0.008 could be considered equal. Don't you
> see that this leads to a very bad algorithm for comparing for approximate equal?
>
> More generally, 0.002 of difference might be considered equal or not equal
> purely based on what the actual values are. For some, they will be equal, and
> for some others not. The delta that is required for two numbers to be considered
> unequal varies based on what the actual numbers are.
>
> At least in my book, that is a clear indication that it's a very bad method.
>
> Johnny

My rule of thumb, when working with US$, is that any difference greater than
.001 is not equal.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dave Froble]

On 1/28/2023 5:35 PM, Arne Vajhøj wrote:
> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>> Consider the case where the numbers represent money.
>>
>> Who cares what the numbers represent? For example, if you round to
>> the nearest integer, then 1.49999 and 1.50001 differ by only 0.00002,
>> but one rounds to 1, and the other to 2, so the lame test says that
>> they're "unequal". And 1.50001 and 2.49999 differ by 0.99998, but they
>> both round to 2, so the lame test says that they're "equal". Any test
>> which treats a difference of 0.00002 as significant, and a difference of
>> 0.99998 as negligible, is, I claim, (obviously) a bad test, regardless
>> of what the numbers might represent.
>
> There are some specific rules for money usually about
> always rounding 2 digits.
>
> 1494 dollars divided by 1000 = 1.494 get rounded to 1.49
> diff 0.002 not equal
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
>
> 1496 dollars divided by 1000 = 1.496 get rounded to 1.50
> diff 0.008 equal
> 1504 dollars divided by 1000 = 1.504 get rounded to 1.50
>
> Arne
>
> PS: One should never use traditional binary based floating
> point for storing money instead use some decimal based
> type. But sometimes calculations switch to floating point
> anyway.

For maybe 45 years I've used FP (D-float) for monetary transactions and storage.
Never any problems. The secret is understanding what one is doing.

It is not always simple. Consider products with cost and prices using thousands
and even ten thousands, ie; .001 or .0001. Think of things such as golf tees,
sold by the bag, or rather large quantities. The final calculations will be
less than $.01 off, but that is acceptable. Now, sales analysis, where perhaps
millions of items are considered, can get off a bit. Usually acceptable. But,
rounding will cause some small discrepancies.

Yes, I can understand situations where D-float just won't do the job.


--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/28/2023 8:16 PM, Dave Froble wrote:
> On 1/28/2023 5:35 PM, Arne Vajhøj wrote:
>> PS: One should never use traditional binary based floating
>>     point for storing money instead use some decimal based
>>     type. But sometimes calculations switch to floating point
>>     anyway.
>
> For maybe 45 years I've used FP (D-float) for monetary transactions and
> storage.  Never any problems.  The secret is understanding what one is
> doing.
>
> It is not always simple.  Consider products with cost and prices using
> thousands and even ten thousands, ie; .001 or .0001.  Think of things
> such as golf tees, sold by the bag, or rather large quantities.  The
> final calculations will be less than $.01 off, but that is acceptable.
> Now, sales analysis, where perhaps millions of items are considered, can
> get off a bit.  Usually acceptable.  But, rounding will cause some small
> discrepancies.

I find it hard to see why one would bother with the risks
of using floating point if a decimal type is available.

VMS Basic has a decimal type.

So has Cobol and most of the post-1990 languages.

The C crowd are missing out.

Arne

[Simon Clubley]

On 2023-01-28, Arne Vajhøj <***@vajhoej.dk> wrote:
>
> I find it hard to see why one would bother with the risks
> of using floating point if a decimal type is available.
>
> VMS Basic has a decimal type.
>

Did RSTS/E Basic ever get a decimal data type, and if so, when ?

PDP-11 DIBOL had a decimal data type, but I don't know when DIBOL
was introduced to the PDP-11 (ie: was it _after_ David started
using RSTS/E Basic ?)

Simon.

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

[Dave Froble]

On 1/29/2023 9:57 AM, Simon Clubley wrote:
> On 2023-01-28, Arne Vajhøj <***@vajhoej.dk> wrote:
>>
>> I find it hard to see why one would bother with the risks
>> of using floating point if a decimal type is available.
>>
>> VMS Basic has a decimal type.
>>
>
> Did RSTS/E Basic ever get a decimal data type, and if so, when ?
>
> PDP-11 DIBOL had a decimal data type, but I don't know when DIBOL
> was introduced to the PDP-11 (ie: was it _after_ David started
> using RSTS/E Basic ?)
>
> Simon.
>

I believe DIBOL was on the PDP-8. I don't know when or how it got on the PDP-11.

What I think might be interesting is, the people working on RSTS/E back in the
1970s probably aren't around to tell others just how primitive things were.
Seems some here are having a hard time imagining that.

Once VAX Basic was available, many things were added to the language. I guess
some things that are causing John grief. The thing is, once one starts down a
particular road, it's hard to change, and if things are working, no good reason
to change.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/28/2023 3:01 PM, Steven Schweda wrote:
>> [...] a "small" (absolute) difference between two values. [...]
>> Absolute difference is sensitive to the scale
>> of the data.
>
> _My_ "absolute" was in the sense of "absolute value", as in
> Math.Abs(). Any dependence on the scale was built into '"small"', not
> "absolute". Hence the quotation marks around '"small"'.

Yes.

But it can be difficult to determine upfront what a good value
for small it with absolute if one does not know the magnitude of
the numbers up front.

Relative difference is much more robust for that problem.

But relative difference has a problem with numbers
close to zero.

Arne

[Steven Schweda]

> But it can be difficult to determine upfront what a good value
> for small it with absolute if one does not know the magnitude of
> the numbers up front.

The magnitude of the numbers might not matter as much as the number
of bits in the mantissa.

Everything's complicated, but a bad method (like, say, comparing
rounded values) is still a bad method. (I claim.)

[Dave Froble]

On 1/28/2023 6:36 PM, Steven Schweda wrote:
>> But it can be difficult to determine upfront what a good value
>> for small it with absolute if one does not know the magnitude of
>> the numbers up front.
>
> The magnitude of the numbers might not matter as much as the number
> of bits in the mantissa.
>
> Everything's complicated, but a bad method (like, say, comparing
> rounded values) is still a bad method. (I claim.)
>

And you'd be 100% correct. It is the amount of the difference that matters.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/27/2023 7:45 PM, Arne Vajhøj wrote:
> In some contexts the relative difference may be better than the
> absolute difference:
>
> IF Math.Abs(x / y - 1.0) < 0.001 THEN

25 years ago I liked this one:

const double FP_SMALL = 0.000001;
const double FP_ABS_SMALL_1 = -FP_SMALL;
const double FP_ABS_SMALL_2 = FP_SMALL;
const double FP_REL_SMALL_1 = 1-FP_SMALL;
const double FP_REL_SMALL_2 = 1+FP_SMALL;

BOOL num_eq(double x1,double x2)
{
double d;
if((-1<x2)&&(x2<1)) {
d = x1 - x2;
return ((FP_ABS_SMALL_1<d)&&(d<FP_ABS_SMALL_2));
} else {
d = x1 / x2;
return ((FP_REL_SMALL_1<d)&&(d<FP_REL_SMALL_2));
}
}

Apparently I did not like space around operators back then.

Arne

[Single Stage to Orbit]

On Thu, 2023-01-26 at 13:38 -0500, Arne Vajhøj wrote:
> > 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.

Of course they aren't. But it is good enough for our purposes.
--
Tactical Nuclear Kittens

[Arne Vajhøj]

On 1/27/2023 1:42 PM, Single Stage to Orbit wrote:
> On Thu, 2023-01-26 at 13:38 -0500, Arne Vajhøj wrote:
>>> 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.
>
> Of course they aren't. But it is good enough for our purposes.

I am not saying that one is better than the other
just that for some cases the test results will be
different.

Arne

[Scott Dorsey]

Dave Froble <***@tsoft-inc.com> wrote:
>
>What I think might be interesting is, the people working on RSTS/E back in the
>1970s probably aren't around to tell others just how primitive things were.
>Seems some here are having a hard time imagining that.

I had a hard time imagining it in the seventies, so I completely understand.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

>On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-01-28 23:35, Arne VajhÞj wrote:
>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>> Consider the case where the numbers represent money.
>>>>
>>>> Who cares what the numbers represent? For example, if you round to

One of the absolute FIRST things that I was told about floating point
variables in my first programming class was to NEVER use them to represent
money.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>> Consider the case where the numbers represent money.
>>>>>
>>>>> Who cares what the numbers represent? For example, if you round to
>
> One of the absolute FIRST things that I was told about floating point
> variables in my first programming class was to NEVER use them to represent
> money.

It is known to be problematic.

But there are 3 cases where it happens anyway:
- the developer does not care
- the language used does not have a decimal type and
integers with implied decimal is considered to
cumbersome
- decimal is actually used in general, but certain
calculations temporarily move over in floating
point (like some interest calculations)

Arne

[bill]

On 1/28/2023 8:39 PM, Arne Vajhøj wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>>      Who cares what the numbers represent?  For example, if you
>>>>>> round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>
> It is known to be problematic.
>
> But there are 3 cases where it happens anyway:
> - the developer does not care

Wrong developer

> - the language used does not have a decimal type and
>   integers with implied decimal is considered to
>   cumbersome

Wrong language for the job

> - decimal is actually used in general, but certain
>   calculations temporarily move over in floating
>   point (like some interest calculations)

Wrong language for the job

Obviously, all of these can be fixed properly. Guess the concepts of
right tool for the job and due diligence no longer carry any sway.

bill

[Scott Dorsey]

bill <***@gmail.com> wrote:
>
>> - the language used does not have a decimal type and
>>   integers with implied decimal is considered to
>>   cumbersome
>
>Wrong language for the job

You go to war with the army you have, not the army you want.

I wrote an LL(R) parser in Fortran once, and a fourier transform in COBOL
because that's what there was on the machines I had at the time. Both
were excruciating but I got paid so it was okay.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Dave Froble]

On 1/29/2023 9:49 AM, bill wrote:
> On 1/28/2023 8:39 PM, Arne Vajhøj wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>>> Consider the case where the numbers represent money.
>>>>>>>
>>>>>>> Who cares what the numbers represent? For example, if you round to
>>>
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>
>> It is known to be problematic.
>>
>> But there are 3 cases where it happens anyway:
>> - the developer does not care
>
> Wrong developer
>
>> - the language used does not have a decimal type and
>> integers with implied decimal is considered to
>> cumbersome
>
> Wrong language for the job
>
>> - decimal is actually used in general, but certain
>> calculations temporarily move over in floating
>> point (like some interest calculations)
>
> Wrong language for the job
>
> Obviously, all of these can be fixed properly. Guess the concepts of
> right tool for the job and due diligence no longer carry any sway.
>
> bill
>
>

Must be nice to always be right. Even nicer when one doesn't know what one is
talking about.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dave Froble]

On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>> Consider the case where the numbers represent money.
>>>>>
>>>>> Who cares what the numbers represent? For example, if you round to
>
> One of the absolute FIRST things that I was told about floating point
> variables in my first programming class was to NEVER use them to represent
> money.
> --scott
>

What if you didn't have a choice?

RSTS/E V04b

Signed word integers
Strings
Single and double D-float

That's all there was ...

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/28/2023 10:39 PM, Dave Froble wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>
> What if you didn't have a choice?
>
> RSTS/E V04b
>
> Signed word integers
> Strings
> Single and double D-float
>
> That's all there was ...

There is always integers and implied decimal.

Not fun though.

And one need an integer with enough bits ...

Could PDP-11 do 32 bit integers?

Arne

[Dave Froble]

On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>
> There is always integers and implied decimal.
>
> Not fun though.
>
> And one need an integer with enough bits ...
>
> Could PDP-11 do 32 bit integers?
>
> Arne

What part of "signed word integers" didn't you understand? As in 16 bits.
-32768 to 32767.


--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/29/2023 1:21 AM, Dave Froble wrote:
> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> One of the absolute FIRST things that I was told about floating point
>>>> variables in my first programming class was to NEVER use them to
>>>> represent
>>>> money.
>>>
>>> What if you didn't have a choice?
>>>
>>> RSTS/E V04b
>>>
>>> Signed word integers
>>> Strings
>>> Single and double D-float
>>>
>>> That's all there was ...
>>
>> There is always integers and implied decimal.
>>
>> Not fun though.
>>
>> And one need an integer with enough bits ...
>>
>> Could PDP-11 do 32 bit integers?
>
> What part of "signed word integers" didn't you understand?  As in 16
> bits. -32768 to 32767.

I sort of had guessed that word was the same as on VAX,
but I don't understand how it can't have a 32 bit integer.

How does one work with file sizes and file position
in bytes on PDP-11?

I know you don't do C, but I believe C was invented on
PDP-11.

Arne

[Scott Dorsey]

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> wrote:
>
>I sort of had guessed that word was the same as on VAX,
>but I don't understand how it can't have a 32 bit integer.
>
>How does one work with file sizes and file position
>in bytes on PDP-11?
>
>I know you don't do C, but I believe C was invented on
>PDP-11.

I think the issue is with the programming language and not with the
architecture. And yes, you can use bignum in C, at least under v7 Unix,
and store really really big numbers.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 1/29/2023 9:32 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> wrote:
>>
>> I sort of had guessed that word was the same as on VAX,
>> but I don't understand how it can't have a 32 bit integer.
>>
>> How does one work with file sizes and file position
>> in bytes on PDP-11?
>>
>> I know you don't do C, but I believe C was invented on
>> PDP-11.
>
> I think the issue is with the programming language and not with the
> architecture. And yes, you can use bignum in C, at least under v7 Unix,
> and store really really big numbers.

So other language & OS combinations did support 32 bit
integers on PDP-11?

Possible including first version of C.

Arne

[Dave Froble]

On 1/29/2023 10:42 AM, Arne Vajhøj wrote:
> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> wrote:
>>>
>>> I sort of had guessed that word was the same as on VAX,
>>> but I don't understand how it can't have a 32 bit integer.
>>>
>>> How does one work with file sizes and file position
>>> in bytes on PDP-11?
>>>
>>> I know you don't do C, but I believe C was invented on
>>> PDP-11.
>>
>> I think the issue is with the programming language and not with the
>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>> and store really really big numbers.
>
> So other language & OS combinations did support 32 bit
> integers on PDP-11?
>
> Possible including first version of C.
>
> Arne
>
>

When was C first available?

The problem was, in 1974, we had RSTS/E and Basic+ on PDP-11. That was what was
available. Sure, in later years, there were more options. As far as that goes,
we developed what we called "double integer", which was two word integers, used
in memory as D-float, and stored as a 4 byte string. 6 variations gave us whole
integers, and 5 variations with 1 to 5 digits after the decimal point. The max
values were still limited to I believe 8 digits.

What was developed worked. Later, when discussing with customers the choice of
using newer capabilities, they asked, "what's the benefit" and actually what
they had was working. They were not interested in paying to replace something
that was working for them. There was also the issue of running the programs on
historical data saved on tape. They were not interested in converting the
historical data.

And so the old capabilities remained in use, and they did the job. They are
still doing the job.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Scott Dorsey]

Dave Froble <***@tsoft-inc.com> wrote:
>
>When was C first available?

On RSTS/E? Probably about 1980 with Whitesmith C. Maybe a couple years
earlier... I know their RT-11 C became available in 1978 and it was a real C.
I have a Comdex flyer for it hanging outside my office.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 1/29/2023 11:52 AM, Dave Froble wrote:
> On 1/29/2023 10:42 AM, Arne Vajhøj wrote:
>> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <***@vajhoej.dk> wrote:
>>>>
>>>> I sort of had guessed that word was the same as on VAX,
>>>> but I don't understand how it can't have a 32 bit integer.
>>>>
>>>> How does one work with file sizes and file position
>>>> in bytes on PDP-11?
>>>>
>>>> I know you don't do C, but I believe C was invented on
>>>> PDP-11.
>>>
>>> I think the issue is with the programming language and not with the
>>> architecture.  And yes, you can use bignum in C, at least under v7 Unix,
>>> and store really really big numbers.
>>
>> So other language & OS combinations did support 32 bit
>> integers on PDP-11?
>>
>> Possible including first version of C.
>
> When was C first available?

1972, Version 2 Unix, PDP-11.

> The problem was, in 1974, we had RSTS/E and Basic+ on PDP-11.  That was
> what was available.  Sure, in later years, there were more options.  As
> far as that goes, we developed what we called "double integer", which
> was two word integers, used in memory as D-float, and stored as a 4 byte
> string.  6 variations gave us whole integers, and 5 variations with 1 to
> 5 digits after the decimal point.  The max values were still limited to
> I believe 8 digits.
>
> What was developed worked.  Later, when discussing with customers the
> choice of using newer capabilities, they asked, "what's the benefit" and
> actually what they had was working.  They were not interested in paying
> to replace something that was working for them.  There was also the
> issue of running the programs on historical data saved on tape.  They
> were not interested in converting the historical data.
>
> And so the old capabilities remained in use, and they did the job.  They
> are still doing the job.

Didn't VAX to Alpha migration cause some issues with D floating?

If I remember correct then Alpha did not fully support D.

Arne

[Scott Dorsey]

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> wrote:
>On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>
>> I think the issue is with the programming language and not with the
>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>> and store really really big numbers.
>
>So other language & OS combinations did support 32 bit
>integers on PDP-11?

That's not an integer, that's a long. And yes, many languages supported
longints on pdp-11s.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 1/29/2023 11:57 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> wrote:
>> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>> I think the issue is with the programming language and not with the
>>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>>> and store really really big numbers.
>>
>> So other language & OS combinations did support 32 bit
>> integers on PDP-11?
>
> That's not an integer, that's a long. And yes, many languages supported
> longints on pdp-11s.

By integer I did not mean int but all the integer types
(short/int/long/whatever).

Arne

[Simon Clubley]

On 2023-01-29, Arne Vajhøj <***@vajhoej.dk> wrote:
> On 1/29/2023 1:21 AM, Dave Froble wrote:
>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>> One of the absolute FIRST things that I was told about floating point
>>>>> variables in my first programming class was to NEVER use them to
>>>>> represent
>>>>> money.
>>>>
>>>> What if you didn't have a choice?
>>>>
>>>> RSTS/E V04b
>>>>
>>>> Signed word integers
>>>> Strings
>>>> Single and double D-float
>>>>
>>>> That's all there was ...
>>>
>>> There is always integers and implied decimal.
>>>
>>> Not fun though.
>>>
>>> And one need an integer with enough bits ...
>>>
>>> Could PDP-11 do 32 bit integers?
>>
>> What part of "signed word integers" didn't you understand?  As in 16
>> bits. -32768 to 32767.
>
> I sort of had guessed that word was the same as on VAX,
> but I don't understand how it can't have a 32 bit integer.
>
> How does one work with file sizes and file position
> in bytes on PDP-11?
>

The same way as it's done with a block-based filesystem (ODS-2) on VMS.

In general, the 16-bit nature of the PDP-11 is reflected in the API.

Ever worked with real-mode MS-DOS at assembly language level ?

It's the same kind of thing.

> I know you don't do C, but I believe C was invented on
> PDP-11.
>

What makes you think that "int" in C is _always_ at least 32 bits ? :-)

There's a reason why both int and long int have always existed in C.

And on architectures that do not support 32-bit ints, then long int is
a library/RTL feature implemented by the language in the same way as
64-bit long long int is implemented by the language RTL on 32-bit
architectures.

Also, most languages on RSTS/E intended for commercial data processing
also supported a decimal datatype, which was implemented by the language's
RTL. It seems early RSTS/E Basic wasn't one of them however, based on
what David is saying.

Simon.

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

[Arne Vajhøj]

On 1/29/2023 9:51 AM, Simon Clubley wrote:
> On 2023-01-29, Arne Vajhøj <***@vajhoej.dk> wrote:
>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>> And one need an integer with enough bits ...
>>>>
>>>> Could PDP-11 do 32 bit integers?
>>>
>>> What part of "signed word integers" didn't you understand?  As in 16
>>> bits. -32768 to 32767.
>>
>> I sort of had guessed that word was the same as on VAX,
>> but I don't understand how it can't have a 32 bit integer.
>>
>> How does one work with file sizes and file position
>> in bytes on PDP-11?
>
> The same way as it's done with a block-based filesystem (ODS-2) on VMS.
>
> In general, the 16-bit nature of the PDP-11 is reflected in the API.
>
> Ever worked with real-mode MS-DOS at assembly language level ?
>
> It's the same kind of thing.

Compilers on 16 bit MS-DOS did support 32 bit integers.

So a compiler on 16 bit PDP-11 some OS could potentially as well.

>> I know you don't do C, but I believe C was invented on
>> PDP-11.
>
> What makes you think that "int" in C is _always_ at least 32 bits ? :-)

I don't.

The point is that there are some C IO routines that operate on
byte offset. No integer type bigger than 16 bit seems like a huge
problem.

> There's a reason why both int and long int have always existed in C.
>
> And on architectures that do not support 32-bit ints, then long int is
> a library/RTL feature implemented by the language in the same way as
> 64-bit long long int is implemented by the language RTL on 32-bit
> architectures.

For add and sub it does not even need a RTL routine if it has
"with carry" instructions.

It is absolutely possible.

But per Dave at least Basic chose not to support it. And I wonder.

Arne

[Scott Dorsey]

Dave Froble <***@tsoft-inc.com> wrote:
>On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne VajhÞj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>> Who cares what the numbers represent? For example, if you round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to represent
>> money.
>
>What if you didn't have a choice?
>
>RSTS/E V04b
>
>Signed word integers
>Strings
>Single and double D-float
>
>That's all there was ...

Signed integers are fine. Read and write with a . added before the last two
digits, so the integer contains cents. That was very common practice.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

Scott Dorsey <***@panix.com> wrote:
>
>Signed integers are fine. Read and write with a . added before the last two
>digits, so the integer contains cents. That was very common practice.

Other workarounds people have used over the years include keeping dollars and
cents as two diferent integers, and strings or integer arrays used to store
BCD or ascii numbers. That latter is very handy when you're asked to deal
with trillions of dollars and don't have BCD types available.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Dave Froble]

On 1/29/2023 8:16 AM, Scott Dorsey wrote:
> Scott Dorsey <***@panix.com> wrote:
>>
>> Signed integers are fine. Read and write with a . added before the last two
>> digits, so the integer contains cents. That was very common practice.
>
> Other workarounds people have used over the years include keeping dollars and
> cents as two diferent integers, and strings or integer arrays used to store
> BCD or ascii numbers. That latter is very handy when you're asked to deal
> with trillions of dollars and don't have BCD types available.
> --scott
>

Yes, there can be library routines to do some things, but, when the in memory
data types are limited, you either build some hard to use capabilities, if even
possible, or, you use floating point in memory.

Trillions of dollars were never an issue. At least for what we were doing.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Scott Dorsey]

Dave Froble <***@tsoft-inc.com> wrote:
>
>Trillions of dollars were never an issue. At least for what we were doing.

It's a serious problem in many countries with out-of-control inflation.
My grandfather told me about how when he was a child in Italy, everyone
was a millionaire. "Even the wino on the street was a millionaire!" It
was a few years before I realized that this was not an indication that
the streets were paved with gold.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[bill]

On 1/28/2023 10:39 PM, Dave Froble wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>>     Who cares what the numbers represent?  For example, if you
>>>>>> round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>> --scott
>>
>
> What if you didn't have a choice?
>
> RSTS/E V04b
>
> Signed word integers
> Strings
> Single and double D-float
>
> That's all there was ...
>

No COBOL? Sad as it sounds if RSTS BASIC was the only language
on the machine (I am pretty sure it was not) then one would have
to write routines, no matter how inefficient and time consuming,
to do the job right. But floating point for money is never the
right answer.

bill

[Simon Clubley]

On 2023-01-29, bill <***@gmail.com> wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>>
>
> No COBOL? Sad as it sounds if RSTS BASIC was the only language
> on the machine (I am pretty sure it was not) then one would have
> to write routines, no matter how inefficient and time consuming,
> to do the job right. But floating point for money is never the
> right answer.
>

Same question as for PDP-11 DIBOL: when did COBOL arrive on RSTS/E
and was it after David started implementing his application on RSTS/E ?

Simon.

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

[Dave Froble]

On 1/29/2023 9:54 AM, bill wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>>> Consider the case where the numbers represent money.
>>>>>>>
>>>>>>> Who cares what the numbers represent? For example, if you round to
>>>
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>> --scott
>>>
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>>
>
> No COBOL? Sad as it sounds if RSTS BASIC was the only language
> on the machine (I am pretty sure it was not) then one would have
> to write routines, no matter how inefficient and time consuming,
> to do the job right. But floating point for money is never the
> right answer.
>
> bill
>

I have to wonder why some people continue to argue with success?

No, the only language available on RSTS/E, at that time, was Basic+. Much more
was added later using the RSX stuff under RSTS/E. But not in 1974.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dave Froble]

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: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[Steven Schweda]

> [...] 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".)

[Simon Clubley]

On 2023-01-26, Steven Schweda <***@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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Dave Froble]

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: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[John Reagan]

On Thursday, January 26, 2023 at 5:27:41 PM UTC-5, Arne Vajhøj wrote:
> 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
Correct. My example was a condensed version of the problem report.
The original was multiple modules. My example is the worst case scenario
(both in terms of what the compiler has to handle and in terms of my sense
of decency). The static initializations is what I didn't consider in the past.

For BASIC, the example of

map (d) long lw1, long lw2

probably would accidentally create 4 longwords due to how BASIC describes
it to GEM. I didn't take a full survey of all the frontends back at the initial G2L
design. Mostly focused on C & BLISS (to boot the OS) followed by Fortran
and COBOL (we knew that packed decimal and complex needed special
attention).

And yes, I think Dave asked earlier. All of the frontends (C++ is different)
continue to generate GEM CIL and GEM symbol table. Having each frontend
generate its own LLVM IR would be much more work and you run the risk
of introducing subtle differences. Having the single conversion in G2L
is much better. The LLVM interface (which is in C++ and would be hard to
code to from BLISS-based frontends without an extensive set of jacket
routines [yes, LLVM has a C-based interface but it not well supported])
isn't upward compatible. We had to make changes to the G2L code from
the version that interfaces to the LLVM used for the cross compilers and
the newer LLVM used for the native compilers. Only a single place to change
by having G2L.

[Ian Miller]

On Tuesday, January 24, 2023 at 8:48:42 PM UTC, Dave Froble wrote:
> On 1/24/2023 1:17 PM, Simon Clubley wrote:
> > On 2023-01-24, Ian Miller <***@uk2.net> wrote:
> >>
> >> webinar is now available https://vmssoftware.com/about/webinars/
> >
> > Some interesting stuff in the attached PDF at:
> >
> > https://vmssoftware.com/docs/2022_accomplishments_webinar_20230110.pdf
> >
> > |Any news on an Ada compiler for OpenVMS x86?
> > |
> > |We have no plans to provide an Ada compiler due to insufficient customer
> > |demand.
> >
> > Another year to wait for RDB (Q1, 2024).
> >
> > There are no longer any current plans for bare metal support:
> Phillip will be howling at the moon ...
> > |Need specs for an x86 system to run VMS directly without a hypervisor.
> > |
> > |We have currently allocated all R&D resources to the development of OpenVMS
> > |running on virtualized environments to meet most customer needs and
> > |requirements. There are no specific plans to support bare metal, but customer
> > |requests will be carefully considered. Please contact us with your specific needs.
> >
> > Efforts to expand the VMS userbase have been abandoned:
> Well, that's not so clear. We've all read about how so many are now using VM
> environments.
>
> VM environments is not going to satisfy some requirements. If I'm running a
> nuclear power station, I would not choose (or allow) a VM environment for
> critical stuff.
> > |Are there any sales efforts for OpenVMS to take back industry market share
> > |from other operating systems that later "replaced" VMS? Or bid on new
> > |industrial projects that would run on VMS?
> > |
> > |Our primary objective is to provide current OpenVMS users with the
> > |opportunity to protect their investments in OpenVMS-based applications
> > |without a technical deadline.
> >
> > In reality, I suppose this is just confirming what everyone in their
> > heart really knew (even if some were not willing to admit it. :-))
> Well, yeah, to some extent.
> > This one got my attention big time. I thought this was a current project:
> >
> > |What position does PostgreSQL have on the list of opensource software?
> > |
> > |We have no plans to port PostgreSQL to OpenVMS.
> With some retiring, and possibly others leaving, perhaps VSI just isn't making
> enough money for all we'd wish they would do. I too thought they had promised this.
>
> Now I wonder when they will announce the unavailability of a Basic compiler?
>
>
> --
> David Froble Tel: [phone]
> Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

"Is native BASIC compiler expected in 2023? The roadmap web page does not
explicitly mention it.
We expect to provide BASIC during 2023."

[Craig A. Berry]

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. I wonder if Oracle told them no Rdb unless they
quash the port of PostgreSQL to OpenVMS x86.

[Simon Clubley]

On 2023-01-24, Craig A. Berry <***@nospam.mac.com> 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. I wonder if Oracle told them no Rdb unless they
> quash the port of PostgreSQL to OpenVMS x86.
>

It does seem strange in light of previous comments and work in this area.
I wonder if there is some misunderstanding going on.

_If_ you are correct however, I wonder if there's anything else VSI have
had to agree not to port to x86-64 in order to get Rdb on x86-64 VMS ?

BTW, did VSI provide the source code changes to get PostgreSQL running
on Itanium ?

If so, I wonder if a build attempt on x86-64 would work anyway.

Simon.

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

[Arne Vajhøj]

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.

>   I wonder if Oracle told them no Rdb unless they
> quash the port of PostgreSQL to OpenVMS x86.

I don't see much point for Oracle to do so.

PostgreSQL is not "Rdb compatible" in any way.

The two groups:
- existing Rdb users that will migrate to PostgreSQL on VMS
if it exist but stay on Rdb if it does not exist
- new users that will pick PostgreSQL on VMS if it exist
and Rdb if it does not exist
must be extremely small.

Arne

[Craig A. Berry]

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. 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.

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.

[Arne Vajhøj]

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.

Arne

[Craig A. Berry]

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."

[Arne Vajhøj]

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

[Arne Vajhøj]

On 1/25/2023 12:03 PM, Arne Vajhøj wrote:
> On 1/24/2023 6:27 PM, Craig A. Berry wrote:
>>                       I wonder if Oracle told them no Rdb unless they
>> quash the port of PostgreSQL to OpenVMS x86.
>
> I don't see much point for Oracle to do so.
>
> PostgreSQL is not "Rdb compatible" in any way.

To be more a little more specific:

C module, C SQL services API, C OCI API, Pascal embedded SQL,
Pascal module, Cobol module, Basic embedded SQL and Basic module
will be a complete API change - rewrite to LIBPQ.

C embedded SQL and Cobol embedded SQL should be relative easy
to port (fix connection, maybe something with error handling
and maybe some SQL changes). Cobol assumes that the ESQL
open source thing get ported, but VSI could do that.

Java JDBC, Java JPA, Python DB API and PHP PDO should be
easy to port (mostly changing config).

So some things will be compatible.

But the first category is way bigger than the last
category on VMS.

Arne

[Arne Vajhøj]

On 1/24/2023 1:17 PM, Simon Clubley wrote:
> On 2023-01-24, Ian Miller <***@uk2.net> wrote:
> Efforts to expand the VMS userbase have been abandoned:
>
> |Are there any sales efforts for OpenVMS to take back industry market share
> |from other operating systems that later "replaced" VMS? Or bid on new
> |industrial projects that would run on VMS?
> |
> |Our primary objective is to provide current OpenVMS users with the
> |opportunity to protect their investments in OpenVMS-based applications
> |without a technical deadline.
>
> In reality, I suppose this is just confirming what everyone in their
> heart really knew (even if some were not willing to admit it. :-))

????

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?

So I don't see anything being abandoned.

9.2 is out, but they are still missing some relevant products
like native compilers, Rdb etc.. Hopefully all these will show
up this year and early next year.

When these are available then the existing customers will
need to migrate. It will take many years.

And there are some things VSI will need to get done (incl. a lot
in compiler, library, tooling and server products) before
chasing new customers make sense.

Ask them again in 2028 and they may have a different answer.

Arne

[[e-mail]]

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

> 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

[Arne Vajhøj]

On 1/25/2023 3:14 PM, ***@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