forums.silverfrost.com

[DietmarSiepmann]

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

[PaulLaidler]

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.

[JohnCampbell]

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.

[DietmarSiepmann]

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

[JohnCampbell]

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.

[PaulLaidler]

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".

[JohnCampbell]

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.