Re: New VSI post on Youtube

On 2024-08-15 01:26:00 +0000, Craig A. Berry said:

On 8/14/24 7:35 PM, Stephen Hoffman wrote:

On 2024-08-14 19:49:28 +0000, Robert A. Brooks said:
 

On 8/14/2024 2:57 PM, Arne Vajhøj wrote:
 

compile/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