View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Fri Mar 17, 2017 4:45 pm Post subject: Stack: I'm back! |
|
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Fri Mar 17, 2017 6:16 pm Post subject: |
|
|
If you are using /link or /lgo on the command line then the simple way to increase the stack size is to add /stack n where n is the new stack size in megabytes. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Mar 18, 2017 4:48 am Post subject: |
|
|
"The reports of my death have been greatly exaggerated" (c), Mr.Stack.
I have not seen or heard from anyone who was thankful to discover painfully the existence of stack, the devilry feature from ancient ages hell, at least no one needed it for the last 40 years. Why developers still persistently keeping it ? With 64bit we got memory limits formally increased by 4 billion times and I ran my 64bit code and got hit again by the same damn thing I suffered a lot with 32 bits, may be with just a bit larger bar. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sat Mar 18, 2017 8:28 am Post subject: |
|
|
You may find that the problems are less severe in the next release since I understand that changes have been made that may help.
I will make enquires about this issue. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Sat Mar 18, 2017 12:20 pm Post subject: |
|
|
Dan,
No stack, then no subroutines, no functions, no parameters. OK, call it something else, but it's still there. Stack limits? Now there's a different problem and perhaps you can solve it for yourself. Just don't use it up for no good reason: passing local arrays.
Provided you don't overflow, you can use it all. In the words of the Eagles:
Take it to the limit, take it to the limit
Take it to the limit one more time
Sometimes just a few extra bytes is all you need.
Incidentally, once you got into Clearwin+ you used to be in the Hotel California, because you could check out but you could never leave. Dang, now where's my guitar? |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Mar 19, 2017 8:47 am Post subject: |
|
|
as that man Manfred once said, you're just blinded by the bytes.... |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Mar 19, 2017 9:32 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: | Hotel California...because you could check out but you could never leave. | Eddie, what is there not served in that Hotel California since 1969? In my Hotel California all is being served, the whole stack of it, you can check some day being around. I'd gladly exchange with Silverfrost our stacks. Don't want to checkout or leave by the way |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Mon Mar 20, 2017 1:30 am Post subject: |
|
|
Dan,
My understanding is stack overflow can be caused by a variety of reasons.
1) is local variables overflow the stack size limitation, while
2) there are many other errors that can corrupt the stack and it's expected size.
Ignoring the vast possibilities associated with 2), the solution for 1) is to avoid local arrays.
With /64, local arrays can get much bigger, so my solution is to make all local (especially automatic) arrays ALLOCATE arrays, possibly placing them in a module to better manage them. (local allocate arrays are automatically de-allocated on return, except for pointer arrays, which can be a major source of memory leakage)
You should not be lazy with local arrays as they are a major source of problems. This is especially so in multi-threading, where large private arrays can quickly cause a stack overflow, as well as performance problems with repeated memory allocation.
Making the stack larger is a temporary patch to mask the problem, while managing these arrays with ALLOCATE is a much better solution.
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Mar 20, 2017 8:29 am Post subject: |
|
|
The next release of FTN95 will treat local arrays as though they were automatic arrays. This means that any arrays other than very small ones will be allocated from a "virtual" stack that automatically grows when needed and has a very large upper limit.
Hopefully the problem of stack overflow, particularly when processing large amounts of legacy code, will go away (at least for 64 bit FTN95). For new code John's advice makes good sense. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Mon Mar 20, 2017 11:58 am Post subject: |
|
|
Wowwowowowwww....that's even more then i'd realistically hoped for. This company shows that it has no lack of visionaries and does not afraid to innovate. |
|
Back to top |
|
|
|