VMS x86-64, C++ and SMG$

Post Reply
User avatar

Topic author
arne_v
Senior Member
Posts: 637
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

VMS x86-64, C++ and SMG$

Post by arne_v » Sat Dec 28, 2024 11:48 am

It seems like SMG$ are very 32 bit pointer oriented.

Which combined with C++ default of 64 bit pointers can give some interesting results.

I did not expect this:

Code: Select all

$ type sixtyfour.cpp
#include <cstdint>
#include <iostream>

using namespace std;

#include <smg$routines.h>

class Test
{
private:
    int32_t kbid;
public:
    Test()
    {
        cout << "ctor called" << endl;
        int32_t stat = smg$create_virtual_keyboard(&kbid);
        cout << "stat=" << stat << endl;
    }
    virtual ~Test()
    {
        cout << "dtor called" << endl;
        int32_t stat = smg$delete_virtual_keyboard(&kbid);
        cout << "stat=" << stat << endl;
    }
};

void test1()
{
    Test o;
}

void test2()
{
    Test *o = new Test();
    delete o;
}

int main()
{
    test1();
    test2();
    return 0;
}

$ cxx sixtyfour
$ link sixtyfour
$ run sixtyfour
ctor called
stat=1
dtor called
stat=1
ctor called
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=FFFF830008AB65CC, PC=0000000000000001, PS=432B2B02
-RSX-W-NOMSG, Message number 00066C20
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
sixtyfour                                    0 000000008000007F 000000008000007F
sixtyfour                                    0 000000008000008D 000000008000008D
sixtyfour                                    0 00000000800000D1 00000000800000D1
PTHREAD$RTL                                  0 000000008003F28C FFFF830008CFF28C
PTHREAD$RTL                                  0 0000000080000331 FFFF830008CC0331
                                             0 FFFF8300071C81C6 FFFF8300071C81C6
DCL                                          0 000000008006632B 000000007ADC432B
%TRACE-I-END, end of TRACE stack dump
$ cxx/pointer=32 sixtyfour
$ link sixtyfour
$ run sixtyfour
ctor called
stat=1
dtor called
stat=1
ctor called
stat=1
dtor called
stat=1
Added in 4 minutes 5 seconds:
Strictly speaking it is P0/P1 vs P2 not pointer size, but the latest C++ new allocate in P0 or P2 depending on pointer size.
Arne
arne@vajhoej.dk
VMS user since 1986


jonesd
Master
Posts: 128
Joined: Mon Aug 09, 2021 7:59 pm
Reputation: 0
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by jonesd » Sat Dec 28, 2024 2:14 pm

SMG was written in Bliss a long time ago.

I use SMG for the SQLite shell program (emulating linenoise()) and carefully isolate the singleton used to interact with SMGRTL. Large chunks of the SMG-related modules are bracketed with pointer_size pragmas.

User avatar

Topic author
arne_v
Senior Member
Posts: 637
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: VMS x86-64, C++ and SMG$

Post by arne_v » Sat Dec 28, 2024 7:06 pm

New code should have data in P2 and use 64 bit pointers.

But there is a lot of old code around. In VMS and in customer code bases.

I wonder what the right strategy for this is.

1) Say that the current mechanism of pointer size determining whether new allocate in P0 or P2 is good enough.

2) Say that just like C has _malloc32 and _malloc64 for explicit region allocation, then C++ should have _new32 and _new64.

3) Say that this should not be solved imperative but declarative. Instead of calling _malloc32/_malloc64/_new32/_new64 then making it an attribute of types or variables.

__MUST_BE_P0__
__MUST_BE_P2__

so that:

__MUST_BE_P0__ class Test
{
};
...
Test o = new Test();

allocated in P0, because that is a attribute of the Test type.

(besides P0 and P2 there is also stack P1 - not sure how to handle that)
Arne
arne@vajhoej.dk
VMS user since 1986


greg@tssolutions.com.au
Active Contributor
Posts: 40
Joined: Wed May 29, 2024 10:29 am
Reputation: 0
Location: Australia
Status: Offline
Contact:

Re: VMS x86-64, C++ and SMG$

Post by greg@tssolutions.com.au » Sun Dec 29, 2024 10:43 pm

I think the malloc 32(P0)/64(P2) is a major block to converting VMS code to use 64 bit as there are a lot of VMS API's that do not yet support 64bit.

A possible work-around is for malloc64() to allocate P0 memory when possible and only allocate P2 when there is not enough P2 available. This would allow new 64 bit code to still access the old 32 API's.

Clearly all the old VMS 32bit APIs need to be updated but that is going to take a long time.
gt (260295)
VMS Ambassador
Downunder


roberbrooks
VSI Expert
Valued Contributor
Posts: 83
Joined: Thu Jun 20, 2019 11:48 am
Reputation: 0
Location: Leverett, MA
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by roberbrooks » Mon Dec 30, 2024 12:55 am

We know that the use of C++ on X86 is going to be "interesting" with some of the existing interfaces.

For example, using C++ on X86 with DECwindows did not work out of the box. We needed to add conditionalisation to header files, and I think that largely solved the problem (I wasn't involved in the solution; I did read about it internally).

My guess is that besides SMG, there are other APIs that will not work cleanly with C++ on X86, and we'll deal with them as the issues roll in.

I think the change that was made to make C++ use 64-bit pointers by default on X86 is our acknowledgement that we need to modernize a bit.
Last edited by roberbrooks on Mon Dec 30, 2024 12:55 am, edited 1 time in total.
--
-- Rob

User avatar

Topic author
arne_v
Senior Member
Posts: 637
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: VMS x86-64, C++ and SMG$

Post by arne_v » Mon Dec 30, 2024 9:13 am

greg@tssolutions.com.au wrote:
Sun Dec 29, 2024 10:43 pm
A possible work-around is for malloc64() to allocate P0 memory when possible and only allocate P2 when there is not enough P2 available. This would allow new 64 bit code to still access the old 32 API's.
Not really. If it can return a pointer to P2 memory, then it is not safe to use by a P0 & P1 only API.

Added in 3 minutes 10 seconds:
roberbrooks wrote:
Mon Dec 30, 2024 12:55 am
I think the change that was made to make C++ use 64-bit pointers by default on X86 is our acknowledgement that we need to modernize a bit.
Yes. In the 10-20 year perspective everything has to move to 64 bit pointers.

Question: what about stack space? 1000 threads of 2 MB thread stack is 2 GB, which can obviously not be in P1.

Added in 52 seconds:
greg@tssolutions.com.au wrote:
Sun Dec 29, 2024 10:43 pm
Clearly all the old VMS 32bit APIs need to be updated but that is going to take a long time.
True.
Arne
arne@vajhoej.dk
VMS user since 1986


jonesd
Master
Posts: 128
Joined: Mon Aug 09, 2021 7:59 pm
Reputation: 0
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by jonesd » Mon Dec 30, 2024 9:49 am

roberbrooks wrote:
Mon Dec 30, 2024 12:55 am
My guess is that besides SMG, there are other APIs that will not work cleanly with C++ on X86, and we'll deal with them as the issues roll in.
The first thing that comes to mind are the LBR$ routines for accessing libraries (.OLB, .TLB, etc).


joukj
Master
Posts: 267
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by joukj » Thu Jan 02, 2025 3:12 am

roberbrooks wrote:
Mon Dec 30, 2024 12:55 am
For example, using C++ on X86 with DECwindows did not work out of the box. We needed to add conditionalisation to header files, and I think that largely solved the problem (I wasn't involved in the solution; I did read about it internally).
Still a lot of problems when you try to compile with 64-bit pointers (the default of CXX/clang). I had to change the code calling DecWindows at many places with "pragma" to change the pointersize or the use of _malloc32. It is a tedious work. Up to now I only get some packages "ported to" clang now. (My goal is to get wxWidgets working on X86)
What I have working now:
  • mesa3d/mesa3dglu/mesa3dglut/glew/mesa-demos :
    • the gears demo runs
    • the 2 glew-demo programs work
  • gtk1/glib : some tests work some crash (much work to do)
  • libxml : the two demo programs give the right results
An option would be to compile everything with 32-bit pointers, but I think 64-bits is the future; so I'll try the 64-bit versions.

Work will be in progress.

Jouk


jreagan
VSI Expert
Master
Posts: 233
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by jreagan » Mon Feb 03, 2025 12:10 pm

I thought we got the latest DECwindows header correct to put pointer_size 32 around various pointer decls and typedefs.

if the code needs explicit pointer declarations to get 32-bit pointers to pass to some DECwindows interface that wants a 32-bit pointer, is there no DECwindows-provided typedef to use?

I can't tell if you are tell me we still have problems or that moving to a 64-bit pointer default environment is just shaking loose latent bugs in the code? I'm sure that the DECwindows code is still compiled with 32-bit pointers for compatibility.


joukj
Master
Posts: 267
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

Re: VMS x86-64, C++ and SMG$

Post by joukj » Tue Feb 04, 2025 1:43 am

jreagan wrote:
Mon Feb 03, 2025 12:10 pm
I thought we got the latest DECwindows header correct to put pointer_size 32 around various pointer decls and typedefs.
They still need some imnprovement:
i.e.
-the prologs should include <stdint.h> if compiled using clang
-Also when compiled with CC/point=64 the pointers should be set to 32bit in the prolog
jreagan wrote:
Mon Feb 03, 2025 12:10 pm
if the code needs explicit pointer declarations to get 32-bit pointers to pass to some DECwindows interface that wants a 32-bit pointer, is there no DECwindows-provided typedef to use?
Since most of the code I tried is Opensource software I do not want to change too much in the actual code. I still had to set certain areas expliciely to 32bit and had to change the malloc to __malloc32 in some places.

jreagan wrote:
Mon Feb 03, 2025 12:10 pm
I can't tell if you are tell me we still have problems or that moving to a 64-bit pointer default environment is just shaking loose latent bugs in the code? I'm sure that the DECwindows code is still compiled with 32-bit pointers for compatibility.
Ofcourse, there is no code without bugs, but I do not think that the change malloc-->__malloc32 is one of them.

Post Reply