replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - use of LOC function and /UNDEF
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 

use of LOC function and /UNDEF
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2615
Location: Sydney

PostPosted: Fri May 01, 2015 12:37 am    Post subject: Reply with quote

Kenny,

If you know the byte length of the CMAP type structure (which could vary between compilers) and the start address of where you want it stored, can't you just use a loop to transfer n bytes to the address, using ICOREx, in a purpose built function ?
I would expect that the layout of a type structure could vary significantly between compilers, depending on the alignment approach and allowance for small or large arrays within the type structure. ( Look at the way FTN95 stores modules, splitting out large arrays )

The use of LOC was not standard at Fortran 95, which is where FTN95 is at and I am not sure how standard "cray pointers" have become.
I have not seen "LOC (RSCALAR) = " used in this way before, so am not surprised you would need a work around with FTN95, using the xCOREx approach.

John
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1257
Location: Morrison, CO, USA

PostPosted: Fri May 01, 2015 7:20 pm    Post subject: Reply with quote

For my application I took a different approach.

The address of the data (of differing types) is stored generically in INTEGER (KIND=3) array and has a type array associated with it as well. At run time, after data are entered, the program goes through the array and moves the data into the appropriate destination (based on a "type" associated with each location). I did this to make the code more "portable", but it also solved the /undef issue that would arise. Here are a few examples. I'm fortunate that the character data used is always < 1024 bytes in length.

Code:

   SUBROUTINE CHAR_MOVE(CDATA)
        CHARACTER*(*),target:: CDATA
        INTEGER*4 LEN_CHAR
        CHARACTER*1024,POINTER::LOC_POINTER
        COMMON/LOCSERVICES/LOC_POINTER,LEN_CHAR
        LOC_POINTER(1:LEN_CHAR) = CDATA
        RETURN
        END
        SUBROUTINE I2_MOVE(DATA_VAL)
        INTEGER*2,target:: DATA_VAL
        INTEGER*2,POINTER::LOC_POINTER
        INTEGER*4 LEN_CHAR
        COMMON/LOCSERVICES/LOC_POINTER,LEN_CHAR
        LOC_POINTER = DATA_VAL
        RETURN
        END
.
.
.


There are similar routines for all the basic data types allowed and KIND=xxx variations of those types. This works in DEBUG and RELEASE equally well.

In the calling routine, the following convention is used:
Code:


        INTEGER*4 TARGET_LOCATION,TARGET_LENGTH
        COMMON/LOCSERVICES/TARGET_LOCATION,TARGET_LENGTH
.
.
.
        TARGET_LOCATION = LOCDAT(I) ! LOCDAT has the LOC() values
        CALL I2_MOVE(I2_DATA)



This technique can also extend to any arbitrary data type.
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 -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
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