forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

64 bit memory allocation/access routines?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Fri Oct 07, 2016 10:24 am    Post subject: 64 bit memory allocation/access routines? Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Oct 07, 2016 5:31 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Fri Oct 07, 2016 6:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Thu Nov 24, 2016 10:12 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Nov 24, 2016 11:02 am    Post subject: Reply with quote

Kenny

Do you mean LOC?.
LOC returns a 64 bit address for 64 bit applications.
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Thu Nov 24, 2016 11:13 am    Post subject: Reply with quote

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

ignore!

K
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Nov 26, 2016 3:22 am    Post subject: Reply with quote

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
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Sat Nov 26, 2016 9:39 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group