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.

[StamK]

We are having the same issue now that we use the same script files for 32bit and 64bit.
Is there a way for slink64 to know that a line with
stack
is only for 32bit?

[PaulLaidler]

StamK

Do you mean "stack"? There is a stack command for SLINK64.

As noted above, there is currently no "heap" command and I would need to check if the defaults given above are still relevant in SLINK64 v3.

[StamK]

Indeed, you are right, there is a "stack" command for slink64, but for some reason in our scripts the following line
stack 30000000
causes the program to show the following error

The system cannot execute the specified program.

[PaulLaidler]

The value used with the "stack" command for SLINK64 is the size in decimal megabytes. It is multiplied by 1000000 to get the stack size.

The alternative is to use the command "stack_size" where the value is used without the multiplication factor.

[DanRRight]

Kill and burn 32 bits and forget like a nightmare dream. There is even no cellphone on 32bits anymore. The 128 GB RAM costs $500 which is 100x larger than maximum size 32bit EXE file allowed restricted by damn 32bits (ok, you can get 2GB with headache causing tricks or with more headache get maximum 3GB).

Silverfrost has to suggest all to switch to 64bits. Supporting two versions is not fun to do. People in this forum will readily help to port 32bit apps to 64bits as well as this could be additional income for developers. Port DOS apps to Windows using Clearwin. Graphics to %PL and OpenGL. Serial application running on one processor to parallel multiprocessor ones.

64bit debugger should identify last bugs it still missed (when i checked and posted here one month or so ago ) and 32bits should be pronounced dead

64bits should have no stacks, heaps, commits etc. and other confusing Neanderthals restrictions additionally confused by units somewhere in hex, in bytes, in megabytes...

We have restrictions by OS and processors manufacturers which are in 100s of Gigabytes range for consumer processors and in Terabytes for PRO versions and that's all we have to know

[DietmarSiepmann]

Dan,

I'm afraid I need to express objections concerning some of your statements, e.g.

[PaulLaidler]

In my opinion there is no merit in degrading support for 32 bit applications and DLLs. It is very stable and so needs very little maintenance. The only possible exception is that 32 bit optimiser failures may not get fixed if they prove to be very time consuming but we will always aim to at least provide a work-around.

32 bits and 64 bits share the same "frontend" so Fortran 200x extensions to FTN95 are automatically shared.

As Dietmar has stated (or implied) you currently don't get extended precision reals with 64 bit FTN95 and this could be problematic.

[wahorger]

Dietmar, I will echo your sentiments. I cannot afford to abandon 32-bit. Even though I want to It's too long a story! Mostly mixed language programming issues. If it were all "vanilla", it'd be no problem, I am sure.

Bill