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 

Stack: I'm back!

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Fri Mar 17, 2017 4:45 pm    Post subject: Stack: I'm back! Reply with quote



Smile Smile Smile Smile Smile Smile Smile Smile Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 17, 2017 6:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Sat Mar 18, 2017 4:48 am    Post subject: Reply with quote

"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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Mar 18, 2017 8:28 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1644
Location: Yateley, Hants, UK

PostPosted: Sat Mar 18, 2017 12:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 521

PostPosted: Sun Mar 19, 2017 8:47 am    Post subject: Reply with quote

as that man Manfred once said, you're just blinded by the bytes.... Wink
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Mar 19, 2017 9:32 pm    Post subject: Re: Reply with quote

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



Joined: 16 Feb 2006
Posts: 1756
Location: Sydney

PostPosted: Mon Mar 20, 2017 1:30 am    Post subject: Reply with quote

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


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

PostPosted: Mon Mar 20, 2017 8:29 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Mon Mar 20, 2017 11:58 am    Post subject: Reply with quote

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

 
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