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 

slink64 does not know heap command

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



Joined: 03 Jun 2013
Posts: 244

PostPosted: Thu Oct 29, 2020 2:14 pm    Post subject: slink64 does not know heap command Reply with quote

We use command heep within the link step for a 32 bit application. When doing the same to link the corresponding 64 bit application slink64 fails with error message

Code:
[SLINK64 v2.14, Copyright (c) Silverfrost Ltd. 2015-2020]
***heap - unknown command.


Program test_link.for
Code:

      integer*2 j
      j=2
      end

maybe compiled successfully to produce both a 32 bit and 64 bit object file via ftn95 version 8.66.0. Link file test_link.lnk
Code:

lo test_link
stack 6400000 
heap 200000
file test_link.exe

is used to link the 32 bit and the 64 bit application via commands
Code:

slink test_link.lnk
slink64 test_link.exe
. Command slink successfully generates the 32 bit application test_link.exe whereas slink64 fails with the error message mentioned above.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Oct 29, 2020 3:12 pm    Post subject: Reply with quote

Dietmar

At the moment the heap reserve and commit values are not configurable in SLINK64.

They are preset to:

reserve: 1048576

commit: 4096

Please let me know if these values cause any problems for you.

It is quite possible that the operating system does not use these values.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Fri Oct 30, 2020 12:49 am    Post subject: Reply with quote

I would be interested to the history of this "heap" command. I would expect it does nothing, even in 32-bit.
My understanding is:
The STACK is not extendable and there is a single block in memory available at process start.
The HEAP is very extendable and can take up many available blocks of memory. I am not aware of any necessity to influence this behaviour.
I have done a lot of investigation of STACK and HEAP, including with OpenMP. Typically the heap is used for ALLOCATE, while local, automatic and temporary arrays go on the stack.
In another recent thread, when testing a recursive quicksort that uses PACK, it is interesting that it never failed from stack overflow. This approach, while concise in itís coding, is very memory hungry. This suggests these temporary arrays might not be allocated to the stack.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 244

PostPosted: Sat Oct 31, 2020 11:33 am    Post subject: Reply with quote

We introduced the stack and heap linker commands in order to be able to generate a 32 bit application which could be debugged and which otherwise ran into problems when debugging. This application worked ok if the debug option was not used in the building process.

We currently do not need to use these options for linking 64 bit apps, but we happened to use them because we use the same link files when linking both the 32 bit and the 64 bit version of this special application.

I thought it would be worthwhile to remark this difference between slink and slink64.

Regards,
Dietmar
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Sun Nov 01, 2020 9:59 am    Post subject: Reply with quote

Note : this comment applies to FTN95 /64.

I tried to write a simple program to identify which memory pages were Stack, Heap or Module data. Unfortunately I did not find the rules for when automatic arrays are placed on the heap, rather than the stack. I should not complain, as this change is a good change. I may post the program example when I have these rules better understood.

Can someone advise where this is documented ? I note Version - 8.20 states "* 64 bit FTN95 now stores large static arrays in the same way as automatic arrays" but I can't find the changes for automatic. What is a "large static array" ?

The stack size can be changed in slink64 with
stack_size <hex number> or,
stack <dec mbytes>

I think the "virtual stack" is now 4GB and I assume virtual stack is the stack?

(it would be good if the stack size could be reported, perhaps in program.map)

In recent usage for 64-bit programs, I have been using a very large STACK (512Mbytes). What I am finding is this provides a large reserved address space in the 64-bit virtual memory map, but does not require any physical memory or commited memory until that stack space is used. It neither affects the available physical memory or the virtual paged memory, so runs on my PC with limited installed memory or "small" pagefile.sys capacity.
I also apply this to multi-thread usage where 12 threads can imply 6 GBytes of mapped out memory addresses, with no affect on memory or paging resources. Ifort does a similar thing with a virtual heap when allocation large arrays at very large addresses. This is yet another way of minimising any Stack issues, so defining a 4GB stack might be a good default.
The heap address can also go anywhere (although the user does not control it) It could, for example, start at address 100GB, and Win64 OS would just ignore the unused addresses below this heap. It is all virtual until memory pages are allocated, but only for what is being used. It is a good thing to understand for all of us who struggled with 32-bit address management.

The main thing to remember is that /64 now offers a much better approach to stack and heap sizing than /32.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Nov 01, 2020 11:28 am    Post subject: Reply with quote

John

There is some information in the 64 bit notes and these are now also in the help file under "x64 platform "and "Further information about 64 bit FTN95".
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Sun Nov 01, 2020 12:49 pm    Post subject: Reply with quote

Paul,

Thanks for this advice.

It does indicate that there are 2 Stacks !
the conventional (32-bit style) stack and also
a "pseudo" stack, whose size could be 50% of the installed memory.

I am not sure how this could interact with the Heap, but both blocks are virtual and do not impact on the physical memory.
They might limit the available size of a virtual memory address, which I understand might be limited by the pagefile.sys allocation, although again I am not sure of this.
Anyway, I have never experienced these limits, as my pagefile.sys is configured to at least 2 x installed memory.

It is good that ftn95.chm identifies the differences between Local, Automatic and Dynamic (allocate) arrays. Are temporary arrays easy to describe, as if they went on the conventional Stack, that could cause a problem.

All rather luxurious in comparison to before FTN95 Ver 8.
Back to top
View user's profile Send private message
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