[Info-vax] Process memory settings

[John Reagan]

"Arne Vajhøj" <arne at vajhoej.dk> wrote in message 
news:4a837af8$0$305$14726298 at news.sunsite.dk...
> John Reagan wrote:
>> All the compilers are 32-bit applications.  If they run out of P0/P1, 
>> you're done.  You can bump pagefile quota all you want, but it won't 
>> magically make the compilers start using 64-bit pointers and 64-bit 
>> address space.
>>
>> [Yes, we did look at making the change, the trying to track down the 
>> number of pointers to expand; fields to change; etc. was way too risky.]
>
> Make the changes in a branch with a switch to control 32 vs 64 bit mode.
>
> Release that branch as a special beta version for 2-3 years and let
> the beta users find the bugs one by one.
>
> Arne

Doesn't make it easier.  Still have to expand all the pointer fields in the 
backend, most of the pointers in the frontends, etc.  Don't forget, it isn't 
all in C, but some in BLISS-32, some in BLISS-64 /ASSUME=SIGNED_LONG (which 
gives you 64-bit expressions but REF and %BPADDR are still 32-bits).

Having a switch to turn it on/off is a red herring.  If we could find all 
the places, we'd make it 64-bits all the time.  Why waste the space in the 
structures?  It isn't like we don't trust LIB$GET_VM_64.  That works.  It is 
just the amount of code changes, pointer expressions, etc. ripples through 
the entire code base.  We did look to see if there was a single (or few) 
data structures that could be moved into 64-bit space.  However, you then 
have to find everybody who points to those and expand embedded pointers, 
etc.

I've only seen 1 or 2 cases were we've run out of 32-bit address space (and 
we haven't even confirmed if THIS is one of them).  The amount of time (and 
risk) to change the compilers is not worth it.  Plus, it would increase the 
memory usage for EVERYBODY since all the embedded pointers are now 64-bits 
wide eventhough you wouldn't need to use more than a GB of memory.

John