View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Jul 26, 2019 4:44 pm Post subject: Configuring SLINK64 |
|
|
The default stack size provided by SLINK64 is currently 32MB. This default can be changed by using the commands stack_size=val or stack=val but some users may prefer the simplicity of having a larger default value.
This stack size is the value that SLINK64 inserts into the PE header (as MasterHeader->OptionalHeader.SizeOfStackReserve) when building your executable or DLL.
A new version of SLINK64 can be downloaded via the link below and this comes with a file called Slink64.ini that is to be placed alongside Slink64.exe in your Silverfrost FTN95 folder. The ini file initially contains a value of 1024 that represents a default stack size of 1GB. Likewise a value of 32 replicates the current default which is the minimum that SLINK64 currently permits. This value can be changed at will. My tests so far seem to show no degradation when an unnecessarily large reserve stack size is used.
If users find this feature to be useful then we could later add a "config" option to SLINK64 (similar to that in FTN95) that avoids the direct editing of the ini file.
Note that the ini file usually resides in a protected folder so direct editing of the file is normally not possible. Simply edit the file before copying it to your protected folder.
Here is the link...
https://www.dropbox.com/s/umxj1h3usdd534y/Slink64.zip?dl=0 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2820 Location: South Pole, Antarctica
|
Posted: Sun Aug 04, 2019 12:24 pm Post subject: Re: Configuring SLINK64 |
|
|
PaulLaidler wrote: | My tests so far seem to show no degradation when an unnecessarily large reserve stack size is used. |
I am still confused how it works as i always was since 32bit. For example i can compile and run program allocating in stack local array 1.5GB in size with just default stack which was told is only minuscule 32 MB. And what means unnecessary large? Can you provide an example of stack larger than say 3GB? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Sun Aug 04, 2019 11:25 pm Post subject: |
|
|
I will look into this again and aim to give a more complete explanation but it could be a little while before I get back to you on this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Aug 20, 2019 3:15 pm Post subject: |
|
|
Here is an update regarding the maximum size of the FTN95 stack.
In the announcements for the release of v8.50 of FTN95 it was stated that
Quote: | The size of the FTN95 stack is effectively no longer limited. |
This turns out to be incorrect. The code for this change (within SLINK64) was in place but was not activated at a certain critical point.
We apologise for this oversight and will aim to have this implemented in the next full release. This will allow for a much larger stack size (above the 4GB limit) but the maximum size will still not be unlimited.
A large stack size is (perhaps only) required when using very large local arrays within subroutines.
For those are interested in the details, SLINK64 uses the stack size to set a value within the PE header of the resulting executable and this value is currently implemented correctly. However, SLINK64 also uses this value within some introductory code that it inserts as a prefix before the users code in the executable. It is this part that for the moment remains disabled. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Aug 24, 2019 7:53 am Post subject: |
|
|
PE header ? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2820 Location: South Pole, Antarctica
|
Posted: Sun Aug 25, 2019 11:50 pm Post subject: |
|
|
1) Cool, will see how it works.
2) Interesting to note how smart was done crash handling in OpenGL. When you give it too much work to handle and its stacks are overflowed (large arrays), it may not plot on screen anything, but it DOES NOT crash, i saw only 1-2 cases in 20 years when crash happened. In rare cases when there is no memory left in the system (usual consumer processors have limits, some 32 GB, some 64 and some 128) the screen becomes scary black, freezes for few seconds, and then all recovers in its glory and color. I speculate that this was because many games are written in OpenGL and kids of game developers were bitten at school and also misbehaved with their fathers when their games crashed ))) Everyone remembers the times when OS and games were crashing. Everyone hated that. Clearwin should follow this path and do not crash till the last possibility was exhausted.
3) Do FTN95 make portable executables if this what was meant by PE? It always needed additional libraries to run
Last edited by DanRRight on Mon Aug 26, 2019 5:40 am; edited 1 time in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Aug 26, 2019 12:45 am Post subject: |
|
|
thank you mecej4 _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|