On Sun, 7 Jan 2001, Richard Henderson wrote:
>
> > More to the point, though, is the fact that I have some older Fortran code
> > that I'm attempting to port to alpha Linux which fails when these addresses
> > are very, very, very far apart as they are here.
>
> You can handle an address above 6GB, but not above 32TB?
> Or are you doing something amazingly strange with 32-bit
> displacements against a fake undimensioned array?
You are very perceptive, as that's pretty much exactly what's going on.
You may not be interested, but here's what this old code (which I did not
write!) is doing with these addresses:
In order to have access to dynamically allocated memory blocks, the Fortran
program calls a C malloc() (or the extended Fortran intrinsic equivalent)
to allocate one big chunk. Then the location of this memory relative to
an unitialized blank common block (with one element, an integer*4 array
called ICORE) is computed as an offset in integer*4 words. This offset is
named I0 and is placed in another common block called "ISTART". This allows
the subroutines in the program to have access to the dynamically allocated
memory using code like:
C Here are the common blocks with blank common and the offset to the available chunk
COMMON // ICORE(1)
COMMON /ISTART/ I0
C Here's a simple access example
ICORE(I0) = 9
My problem is that I0 (and all other addresses computed from it) is just a
32-bit integer, not large enough to handle address offsets as large as I'm
seeing under alpha Linux. If the dynamically allocated memory were placed
in the first 2^32 bits of the address space, then I could get away with a
"correct" computation of I0 and then still have access to the core. This is
what is happening under Tru64 Unix, so we're simply getting lucky there.
As it stands, I believe I will have to go through the code and convert all address
references to 64-bit. It's not a pleasant thought, but I'm thinking of hiring a graduate
student part-time to do it for me. :)
> > If there is a way to cleanly force the addresses to be closer
> > together, I need to learn about it.
>
> See mallopt.
I'll see if I can find it. Thanks!
-Daniel
-- T. Daniel Crawford Department of Chemistry crawdad@vt.edu Virginia Tech www.chem.vt.edu/chem-dept/crawford Voice: 540-231-7760 FAX: 540-231-3255_______________________________________________ Axp-list mailing list Axp-list@redhat.com https://listman.redhat.com/mailman/listinfo/axp-list
This archive was generated by hypermail version 2a22 on Sat Mar 3 12:54:54 2001 PST
Send any problems or questions about this archive to webmaster@alphalinux.org.