64 bit memory allocation/access routines?

Hi,

i'm just looking at how deep the cesspool is for converting our existing 32-bit apps to 64-bits...

for the 64-bit compiler:

1 what will GET_STORAGE@ return? A 32-bit or a 64-bit address? 2 will LOC return a 32-bit or 64-bit address? 3 in the STDCALL statement, does 'VAL'/'REF' need changing for 64bit parameters? 4 is there a CORE8 function? 5 what other heffalump traps should i watch out for???

K

1. The first argument of GET_STORAGE@ is a 64 bit address. The requested size is a 32 bit integer.
2. LOC returns a 64 bit integer
3. VAL and REF do not need to be changed. STDCALL can still be used but is the same as C_EXTERNAL.
4. CORE8 is available. Its argument must be a 64 bit integer, for example, core8(0_4).
5. Detailed instructions are provided in the document NotesOn64BitFtn95.txt which is currently located in the FTN95 compiler folder.

tks Paul.

looks like i'm up to my bottom lip in the mire and it's the devil's day for water skiing!

K

RE CORE8, is the reverse function %VAL8 available or does %VAL work with an 8-byte argument?

K

edit: this isn't urgent, it's just for future compatibility with other compilers...

Kenny

Do you mean LOC?. LOC returns a 64 bit address for 64 bit applications.

No, i was getting confused between some old legacy VAX code (which uses %VAL instead of COREn).

ignore!

K

Kenny,

What excludes the use of Fortran conforming ALLOCATE ? I have found that while moving in that direction can be a bit time consuming for coding, having code that is closer to standard conforming helps a lot. About my only remaining vice is the use of REAL8 and avoiding any KIND values or constants, preferring named parameters for any INTEGER8 constants.

John

Hi John,

the fundamental problem is that our code started life under VAX Fortran 4 and a very clever/devious programmer wrote some fundamental tools that depended on LOC/%VAL for all its dialogue handling.

When we ported it to PC DOS using FTN77, the COREn functions were a natural replacement for %VAL.

When we ported to Windows was probably the right time to think about 'future-proofing' but we were so focussed on getting the code to just run on the new platform (which mainly involved turning the program flow 'on its head') that the thought didn't occur to us.

As a result, we now have literally thousands of dialogues in our suite of programs that depend on a toolkit that uses addresses stored in 32-bit variables.

Changing the toolkit is easy.

Changing all the routines that use the toolkit isn't.

K