• C++ FT kit

    From John Reagan@21:1/5 to All on Tue Mar 19 18:42:21 2024
    There is a new C++ on the support portal. The V10.1-1 GA release will
    stay in place. This new release X86VMS-CXX-A1001-240307-1 contains two important changes plus a handful of bug fixes. This is a FT for a
    future V10.1-2 release.

    And the portal page says that the package prerequisites is both V9.2-1
    and V9.2-2. Can't be both! We require V9.2-1 but suggest V9.2-2 as
    there were some exception handling bug fixes in the OS that might impact
    some C++ code.

    The two changes are:

    1) Initial support for listings. The format of the listing is patterned
    after the listing you see on Itanium. It isn't exactly the same, but
    we're pretty close if you ask me. Along with /LIST, the /SHOW qualifier
    is enabled also. Both are updated in the HELP.

    We are still missing the piece in the DWARF debug to help the debugger
    (and traceback) convert between source line numbers and listing line
    numbers. That is "in progress" but we wanted to get this out there now
    to get feedback. [Yes, the other compilers have that info in the DWARF.]

    And there is still no support for /MACHINE_CODE on any of the compilers.
    You still use ANALYZE/OBJECT/DISASSEMBLE to get that output. It isn't perfect and we're coming up with some approaches to solve it.

    2) new() now returns actual 64-bit pointers. As most of you know, the
    default pointer-size switched to 64-bit by default on OpenVMS x86. All
    the pointers (unless the /POINTER_SIZE switch is used OR the
    pointer-size pragmas) are 64-bits. However, what most people didn't
    notice was that new() allocated from the 32-bit heap. All those 64-bit pointers had 0s in the top 32-bits. That was a happy accident that let
    sloppy code that stored those addresses into 32-bit ints or 32-bit
    fields in descriptors, etc. However, that limited the amount of memory
    you could allocate. Why have all those fancy 64-bit pointers if you
    can't use lots of memory?

    So now new() returns 64-bit addresses from malloc64(). If you use an
    explicit /POINTER_SIZE=32 on the command line, new() will revert to
    32-bit heap. However, if you take the default or ask for
    /POINTER_SIZE=64, you will get 64-bit addresses.

    Like Itanium, the current pointer-size setting with the pragmas does not influence what new() does, only the command line use of /POINTER_SIZE.
    We just copied what the Itanium compiler does but looking at it now, I
    think we should do more and look at the current setting based on the pointer-size pragmas. However, that would be incompatible from what
    happens on Itanium. However, I think the number of Itanium programs
    that asked for /POINTER_SIZE=64 is limited and hopefully they will

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)