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
Goto page 1, 2  Next
 
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: 279

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: 7912
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: 2551
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: 279

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: 2551
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: 7912
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: 2551
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
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu May 13, 2021 2:06 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu May 13, 2021 3:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu May 13, 2021 3:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu May 13, 2021 4:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu May 13, 2021 4:47 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri May 14, 2021 4:09 pm    Post subject: Reply with quote

Dan,

I'm afraid I need to express objections concerning some of your statements, e.g.
Quote:
Kill and burn 32 bits

Quote:
Silverfrost has to suggest all to switch to 64bits.

Quote:
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 Smile

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.

Quote:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri May 14, 2021 4:35 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1214
Location: Morrison, CO, USA

PostPosted: Fri May 14, 2021 11:12 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
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