[Info-vax] problem with 64-bit pointers in C

[Stephen Hoffman]

On 2018-02-11 23:10:47 +0000, yuhongbao_386 at hotmail.com said:

> On Thursday, February 8, 2018 at 8:36:17 AM UTC-8, Stephen Hoffman wrote:
>> On 2018-02-08 11:23:40 +0000, already5chosen at yahoo.com said:
>> 
>>> So, you say, VMS 5.1 and 6.x on Alpha were pure 32-bit?
>> 
>> OpenVMS prior to V7 was 32-bit sign-extended (internally) to 64-bit.
>> Apps were 32-bit.
>> 
>>> Or in your book VMS 7.0 is also not considered 64-bit?
>> 
>> It's 64-bit in the same way that TKB is fondly remembered by RSX-11 
>> developers.  All but a few apps remain 32-bit.
> 
> One thing worth mentioning is that there is a code size cost to 64-bit 
> pointers in x86-64 because of the REX prefixes.

Worth mentioning... why?   There were code-size increases going from 
VAX to Alpha.  From Alpha to i64, too.  And it wouldn't surprise me to 
see code size changes between Itanium and x86.  But then I had a couple 
of megabytes of memory on most of the VAX boxes and a half-gig config 
was a massive VAX.  A modern smart-watch has more memory and more 
storage than many of the VAX systems and more than various of the Alpha 
systems we've worked with.    Servers with terabyte-class main memory 
is increasingly common; SAP HANA or otherwise.  Over that same 
interval, disk storage went from ~5 MB to ~5 TB, and disk arrays and 
SSD has gotten cheaper and smaller.   And then there's the whole 
discussion of how much time and effort development costs, and how much 
of that effort is going into app development and how much goes into 
"tussling with the platform" development...  Dealing with TKB and the 
32-/64-bit environments are in the latter.  So... yes... images cam and 
are getting bigger.  So are server configurations.   So are the Arm 
embedded configurations for those folks that really need tighter-spec'd 
and higher-volume and more targeted hardware configurations, for that 
matter.   For the rest of us, disks and SSDs are cheap, and SSDs and 
then non-volatile byte-addressable memory are where we're headed with 
our servers...   So — outside of the folks working on embedded, and who 
are increasingly not using and not wanting OpenVMS for that — are we 
optimizing our apps and our environments for what is and what was, or 
for what will be?




-- 
Pure Personal Opinion | HoffmanLabs LLC