[Info-vax] problems allocating "large" arrays in OpenVMS-Fortran

[Stephen Hoffman]

On 2013-10-29 06:55:45 +0000, Joukj said:

No answer... Beyond "call support" or "work around it"...

> Note that my machine contains 64GB RAM but already gets problems 
> allocating more than 1GB.

...A condition which is usually triggered by the segmented memory 
management addressing model implemented by OpenVMS, or triggered by 
compiler limits, or a combination of these two.  OpenVMS Engineering 
chose to maintain compatibility for existing applications, and 
implemented a segmented 64-bit address space (P2, S2) as a superset of 
the existing 32-bit address space (P0, P1, S0, S1), rather than 
implementing a flat 64-bit address space as has been done on other 
platforms.

Leaving the old VAX-style P1 address space around was more compatible, 
but it also meant that memory segmentation and application code changes 
to use 64-bit P2 space were inevitable; beyond changes to the compilers 
to generate 64-bit virtual addresses, as well as changes to the Linker 
and debugger and the rest of the baggage, you have to recode the 
applications themselves to use P2 space.

As an alternative to the P0, P1, P2 and S0, S1 and S2 segmented scheme, 
some other operating system vendors and providers chose to migrate to 
an entirely flat address space (promoting virtual addresses to 64 bits 
and physical addressing to 48 or 50 or whatever the hardware supports), 
and forced the application programmers to promote everything to 64-bit 
addressing within an application image and its constituent libraries.  
There are systems can run both 32-bit and 64-bit applications, which 
eases the migration.  (This can also be a good break to get the 
application programmers to use newer APIs and related either implicitly 
or explicitly, and to tighten up the APIs and compiler diagnostics and 
related, if you have changes that could make things easier or more 
extensible; improvements worth the disruptions.)

OpenVMS Engineering chose to allow programmers to incrementally add 
64-bit features here and there within applications, and without 
migrating the whole application to move to 64-bit.  Certainly nice in 
some ways, but also arguably also somewhat short-sighted.  (Not that 
this looks to be an issue now, given various HP statements around 
OpenVMS.  But I digress.)

If the ATTRIBUTES ADDRESS64 mechanism isn't working with the Fortran 
compiler for Itanium, then you're left with a support call to HP if 
you're on the latest Fortran, or working around the limitation somehow 
if there's no HP support access available.  (Fortran has its own and 
rather unique take on pointers, just to keep all of this stuff 
interesting, too.)

There's a copy of the relevant part of the Fortran V7.2 release notes 
here <http://www.iri.tudelft.nl/~kromme/fortran-64bit.txt> (that you've 
probably already read) and related discussions 
<https://groups.google.com/d/msg/comp.os.vms/uUlGtQS-iAU/pghLCPyEtJoJ> 
<https://groups.google.com/d/msg/comp.os.vms/mSHpjktPrzk/nXpUTqCgHzkJ>. 
 Here <http://labs.hoffmanlabs.com/node/1771> is how 64-bit addressing 
and 64-bit sections work in C.

FWIW and largely for our grammarian and newsgroup spell-checker, there 
are other reasons to use virtual addressing beyond the flat address 
space, and particularly the memory management protections that are 
inherent in most virtual memory designs and that are fundamental to the 
security of most virtual memory operating systems.  There are the 
inevitable trade-offs involved here, and various devices don't 
necessarily implement virtual memory due to the overhead and the 
performance and parts costs.  The VAX architecture itself saw changes 
in the area of virtual and physical addressing support 
<http://labs.hoffmanlabs.com/node/131>, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC