slink64 does not know heap command

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

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

Program test_link.for

      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

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

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

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.

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.

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

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.

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

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.

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?

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.

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.

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.

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

Dan,

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

Kill and burn 32 bits

Silverfrost has to suggest all to switch to 64bits.

and 32bits should be pronounced dead

I strongly recommend to have both the 32 bit and the 64 bit version of Silverfrost's ftn95 coexisting at least for some time and this for several reasons.

1. We produce 32 bit dlls we deliver to customers. How would we do this if the 32 bit build environment would be dropped?

2. If you do not have the necessity to port 32 bit apps to 64 bit (e.g. for memory reasons) why should you do so? Please have in mind that every port might have the risc of running into unforseen problems.

3. If we observe different behaviour between a 32 bit and a 64 bit application (originated to the same code base) we currently make use of parallel debugging sessions.

4. The 64 bit build environment is not yet as complete as the 32 bit one and it is not only the 64 bit debugger causing problems: e.g. no /mklib option for ftn95 64 bit, C/C++ compiler scc has problems with generating code for /debug /64. This is no criticism to Silverfrost's work which I appreciate very much 😃

5. In a special situation when porting a 32 bit app to 64 bit we resulted in round off errors/problems which seemed to be related to the instruction set used (ftn95 32 bit generates X87 instructions, ftn95 64 bit generates SSE2 instructions; see Post subject: 'Different result in 64-bit application'); in my opinion it would be more difficult to analyse such situations if you had no 32 bit build environment but only a 64 bit one.

Supporting two versions is not fun to do.

I know that, but we managed this by spending efforts into our build environment. For historical reasons we use DOS command scripts for Silverfrost's 32 bit builds; we adapted them for other build environments as appropriate e.g. by using filters. And we use the C-Preprocessor (#IF... #ENDIF etc.) within the code. Thus we support builds for Silverfrost 32 bit, Silverfrost 64 bit and for INTEL 64 bit calling into Silverfrost's clearwin64.dll.

Regards, Dietmar

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.

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

There is no plan to drop or degrade the 32-bit version of FTN95. It is used by many customers.

Guys, 500 million people switched from 32bits to 64bits when Apple have done that for computers and cellphones and all went so quietly that not a single one ever complained or noticed. When i switched to 64bits John Campbell was first to try and told everyone how. And Mecej4 helped with recompiling DLL. Paul helped a lot too and some others after that. Kudos to all. Done.

For the advanced people like you this could not be a problem to recompile and convince others who depend on your software to switch. Your major excuse could that SCC might not be yet 64bit-ready. Or you supply your programs to Neanderthals. But even if they are that low level life or total technophobes, good news is that at least most probably their hardware is already 64bit-ready for a long time.

Not sure many need real10. I needed but this was because i was too lazy to modify the method, while real10 extended simple like 2*2 brute force method's life (in some cases method generated real numbers like 10^{4096 instead of 10}302 like with usual double precision). Other minor things with new FP instructions also exist, they are not important at all. Those old Intel FP instructions are dead anyway, ARM cellphone, desktop and server processors eventually will kill all competitors