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 

GET_GSTORAGE@ doesn't always work?
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Fri Jan 06, 2023 11:45 am    Post subject: Reply with quote

hi, i've tried that and it seems to work in a "noddy" but not in my main application (but i'm still testing).

a question, does the number of bytes in the call to get memory have to be a multiple of 4/8/16?

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 Jan 06, 2023 12:04 pm    Post subject: Reply with quote

No. The call is to GlobalAlloc and the memory allocation is guaranteed to be aligned on an 8-byte boundary.
Back to top
View user's profile Send private message AIM Address
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Fri Jan 06, 2023 2:00 pm    Post subject: Reply with quote

It is worth remembering that VirtualAlloc allocates (or uses memory) at page size granularity. So an alloc of a few bytes takes a full 4K page
Back to top
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Fri Jan 06, 2023 4:40 pm    Post subject: Reply with quote

Seems to work well!

the memory "jumps" are much smaller than before.

the proof of the pudding is in the hands of our most rigorous user.

all being well, he shd be quite happy...

tks.

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



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jan 09, 2023 11:08 am    Post subject: Reply with quote

hi,

just following up...

you mentioned that this was only a 32-bit solution. what is the recommended equivalent 64-bit version?

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: Mon Jan 09, 2023 11:32 am    Post subject: Reply with quote

Kenny

There are undocumented routines that you could use for 64 bits but you would have to provide your own interfaces.

Given time we could provide new routines that work constistently for both 32 and 64 bits.
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jan 09, 2023 11:37 am    Post subject: Reply with quote

ok, if they're going to available by, say, end of Jan, that's OK.

if not, what are the C_External calls i would need to point to?

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: Mon Jan 09, 2023 1:24 pm    Post subject: Reply with quote

Kenny

Here is a sample but you will need a new clearwin64.dll because __open_heap and __close_heap are not currently exported.

Code:
 c_external open_heap    '__open_heap'  ():INTEGER*8
 c_external close_heap   '__close_heap' (VAL4)
 c_external heap_malloc  '__heap_malloc'(VAL4,VAL4):INTEGER*8
 c_external heap_free    '__heap_free'  (VAL4,VAL4)
 integer*8 han,addr(10)
 han = open_heap()
 do i =1, 10
   addr(i)  = heap_malloc(han, 1000000)
   write(*, "(Z8)") addr(i)
 end do
 do i =1,10
   call heap_free(han,addr(i))
 end do
 call close_heap(han)
 end


I will see if new DLLs can be made generally available.
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jan 09, 2023 6:26 pm    Post subject: Reply with quote

hmm, i spoke too soon!

i'm getting an "out of heap space" error under quite specific circumstances.

as far as i can tell there's plenty of memory available (committed figure is ~800Mb) and the failing request is only for 208 bytes.

if i send you the application installer and the datafiles that cause the issue, will you be able to take a look?

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



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jan 09, 2023 7:29 pm    Post subject: Reply with quote

following up...

the actual crash happens on a "write" statement, which, IIRC, means it's actually happened somewhere else and the write statement is the first time windows gets an opportunity to report the error...

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: Mon Jan 09, 2023 7:34 pm    Post subject: Reply with quote

Kenny

Please see my personal message to you.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Jan 10, 2023 12:30 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
Kenny

Here is a sample but you will need a new clearwin64.dll because __open_heap and __close_heap are not currently exported.


I am interested in aligning ALLOCATE on a page boundary, so I am wondering what the modified code might show.
Code:
 c_external open_heap    '__open_heap'  ():INTEGER*8
 c_external close_heap   '__close_heap' (VAL4)
 c_external heap_malloc  '__heap_malloc'(VAL4,VAL4):INTEGER*8
 c_external heap_free    '__heap_free'  (VAL4,VAL4)
 integer*8 han,addr(10), page, offset
 integer   i
 
 han = open_heap()
 
 do i =1, 10
   addr(i)  = heap_malloc(han, 1000000)
   page = addr(i)/4096
   offset = addr(i) - page*4096
   write(*, "(Z8,2i8)") addr(i), page, offset
 end do
 
 do i =10,1,-1
   call heap_free(han,addr(i))
 end do
 
 call close_heap(han)
 
 end
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jan 10, 2023 12:54 pm    Post subject: Reply with quote

John

heap_malloc calls HeapAlloc and from the Microsoft documentation "The alignment of memory returned by HeapAlloc is MEMORY_ALLOCATION_ALIGNMENT".

This is 16 for 64 bit systems.

heap_malloc returns an address for allocated memory of user-given size which is unlike ALLOCATE which provides runtime memory for an object whose size is known to the compiler.

GET_GSTORAGE@ calls VirtualAlloc. Google "VirtualAlloc MSDN".
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Thu Jan 12, 2023 5:20 pm    Post subject: Reply with quote

I have encountered a problem which means that I will not be able to provide access to the new routines described above.

At the moment the general advice is to move to 64 bits as soon as possible and if an address for memory (off the heap) is required then call ALLOCATE for a CHARACTER array and then get its LOC.

p.s. Just to clarify. There are existing functions in the library (mentioned above) that currently require a user interface. These will continue to be available. Plans to provide direct access to these functions (without the need for a user interface) have been put on hold.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Fri Jan 13, 2023 9:57 am    Post subject: Reply with quote

Here is some code that illustrates how to get the address of a block of memory from the global heap using a call to ALLOCATE and FTN95.

Code:
subroutine alloc(addr, size)
 integer(7)::addr,size
 character,pointer::arr(:)
 ALLOCATE(arr(size))
 if(ALLOCATED(arr))then
   addr = loc(arr)
 else 
   addr = 0
   print*, "Allocate failed"
 end if   
end subroutine

subroutine dealloc(addr)
 integer(7)::addr
 character,pointer::arr(:)
 ALLOCATE(arr(1), ABSOLUTE_ADDRESS=addr)
 DEALLOCATE(arr) !Note: DEALLOCATE raises an exception on failure.
 addr = 0
end subroutine

program main
 integer(7) addr
 call alloc(addr, 100000_7)
 write(*,"(Z8)") addr
 call dealloc(addr)
end program
 


p.s. It is better to use ASSOCIATED rather than ALLOCATED.


Last edited by PaulLaidler on Fri Jan 13, 2023 2:29 pm; edited 1 time in total
Back to top
View user's profile Send private message AIM Address
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, 3, 4  Next
Page 2 of 4

 
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