View previous topic :: View next topic |
Author |
Message |
KennyT
Joined: 02 Aug 2005 Posts: 318
|
Posted: Fri Oct 07, 2016 10:24 am Post subject: 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Fri Oct 07, 2016 5:31 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 318
|
Posted: Fri Oct 07, 2016 6:14 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 318
|
Posted: Thu Nov 24, 2016 10:12 am Post subject: |
|
|
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... |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Thu Nov 24, 2016 11:02 am Post subject: |
|
|
Kenny
Do you mean LOC?.
LOC returns a 64 bit address for 64 bit applications. |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 318
|
Posted: Thu Nov 24, 2016 11:13 am Post subject: |
|
|
No, i was getting confused between some old legacy VAX code (which uses %VAL instead of COREn).
ignore!
K |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Nov 26, 2016 3:22 am Post subject: |
|
|
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 REAL*8 and avoiding any KIND values or constants, preferring named parameters for any INTEGER*8 constants.
John |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 318
|
Posted: Sat Nov 26, 2016 9:39 am Post subject: |
|
|
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 |
|
Back to top |
|
|
|