Post by Craig A. BerryPost by Stephen Hoffmancompile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.
But it is not the right long term solution.
For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.
It was a mistake to use 32 and not 64 on Alpha and Itanium, but that
pain will continue for the foreseeable future.
It is past time to change the default. I suspect a lot of the
difficulties in porting are not just from pointer sizes but also
integer sizes. Specifying "long" because the docs for an API say to
use a longword is a 40-year-old habit that will be hard to break, and
not all of the APIs have 64-bit equivalents. A lot of things probably
assume "long" is the same size as "int" even though that is now no
longer the case. As far as I know there is no compiler switch to say
/DATA_MODEL=ILP32 to override the new default of LP64.
In the approaches available to apps likely to be ported, cranking up
the compiler diagnostics settings can find a whole lot of latent bad.
This even if there isn't an app port in the immediate future.
Expect that anybody providing maintenance or porting estimates will
likely increase those estimates for each instance of /VAXC located, for
instance.
The 32-/64-bit addressing design was the right decision at the time.
That the design worked as well as it's done, and allowed code
coexistence was and is valuable.
But we're most of 30 years past Eagle/Theta/V7.0.
Different times. Different tradeoffs. Different hardware. Different
expectations.
Developers have been adding to the complexity here with new work, too.
Which isn't a good place.
If the existing API morass ever gets resolved, flat 64-bit would be preferred.
Because the whole what-does-it-return and which-call-can-I-use and the
size_t/ptrdiff_t mess we ended up with from Eagle/Theta/V7.0 is, well,
a mess.
Yes, that means dragging some apps forward. And dragging systen APIs forward.
It also means an opportunity to age out and deprecate the most
problematic of the old APIs.
And it means leaving the old stuff building and running in 32-bit and
32-/64-bit legacy-compatibility mode and for the foreseeable future.
But any replacement really needs to be further forward than flat 64-bit
using previous-millennium API designs and coding practices.
Which gets into discussions of compiler and API overhauls and other
topics for new 64-bit code.
As for itemlists and descriptors. Good ideas ~40 years ago. Now, not so much.
To be absolutely clear, the existing 32-/64-bit morass would have to
continue in parallel with the 64-bit environment for a decade or so.
All of which have been discussed before.
VSI have far larger projects. Which means this "pain will continue for
the foreseeable future".
And some perspective: we're a decade farther from Eagle/Theta/V7.0 now
than Eagle/Theta/V7.0 was from VAX/VMS V1.0.
--
Pure Personal Opinion | HoffmanLabs LLC