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 problem
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Mon Aug 06, 2018 11:56 am    Post subject: Reply with quote

John

In answer to your specific questions:

1. Local arrays can only go on the stack. Its default size is 32MB and in theory this can be increased to 4GB via the SLINK64 option "stack_size".

2. Automatic arrays use a different "stack" as described in the above download.

3. The SLINK64 /map does not appear to give the stack size but this, in any case, would just be the default value or the value you supply for "stack_size".
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2006
Location: Sydney

PostPosted: Tue Aug 07, 2018 1:59 pm    Post subject: Reply with quote

Paul,

Thanks for the advice. The updated info does describe what is happening for 64-bit.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Aug 08, 2018 12:09 am    Post subject: Reply with quote

Why on earth anyone needs to know and continue to worry about existence of stack in 64bits? It is a total rudiment and needs to be pesticided from Fortran. Why stack existed even in 32bits? Who the hell introduced it in first place and for what purpose? Anyone gained anything from existence of this annoyance?

I'd excused stack existence if it would guarantee that some specific part of the code would be always kept in processor cache level3, or level2 or even level1 but this is clearly not the case, the dumb blind stack has no such options. So make it RIP, Silverfrost
Back to top
View user's profile Send private message
wahorger



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

PostPosted: Wed Aug 08, 2018 2:34 am    Post subject: Reply with quote

Without a stack, recursion would be near impossible. I remember writing a "re-entrant" routine years ago as part of my CS degree. This predated stack oriented processors, so we had to handle the stack in the assembly code. PITA. While one can write re-entrant or recursive routines without a hardware stack, the problem of where to return control when complete can get really sticky. Or, one writes a recursive routine as simple code, handling the entry/exit within the program module as if it were being called. It can be done but doing so will obfuscate the code.

All the GUI interfaces that you and I use AND OpenGL REQUIRE a stack architecture because they are mostly written in "C" AND the processor architecture is stack-oriented so they take advantage of it. Like temporaries on the stack. Blazingly fast allocation because there really isn't any (one just adjusts the stack pointer and uses it as the addressing), and recursion/re-entrancy are built-in.

If you wish to RIP the stack, you also RIP using any SF software. Don't think that's what you are after.....
Back to top
View user's profile Send private message Visit poster's website
wahorger



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

PostPosted: Wed Aug 08, 2018 2:34 am    Post subject: Reply with quote

Without a stack, recursion would be near impossible. I remember writing a "re-entrant" routine years ago as part of my CS degree. This predated stack oriented processors, so we had to handle the stack in the assembly code. PITA. While one can write re-entrant or recursive routines without a hardware stack, the problem of where to return control when complete can get really sticky. Or, one writes a recursive routine as simple code, handling the entry/exit within the program module as if it were being called. It can be done but doing so will obfuscate the code.

All the GUI interfaces that you and I use AND OpenGL REQUIRE a stack architecture because they are mostly written in "C" AND the processor architecture is stack-oriented so they take advantage of it. Like temporaries on the stack. Blazingly fast allocation because there really isn't any (one just adjusts the stack pointer and uses it as the addressing), and recursion/re-entrancy are built-in.

If you wish to RIP the stack, you also RIP using any SF software. Don't think that's what you are after.....
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Wed Aug 08, 2018 7:31 am    Post subject: Reply with quote

In theory it might be possible for FTN95 to give users the option of putting local and automatic arrays on the heap rather than the stack. If it is then it would not be a short/simple task so we are back to the question of priorities and general interest.

In the meantime very large local and automatic arrays must be converted in your code to take the form of dynamic arrays (using ALLOCATE).

It is a mistake to assume that you can simply take old code, convert it to 64 bits and then increase the array sizes without constraint. There will be limitations from your hardware, from the operating system, and to some extent from the compiler.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1031

PostPosted: Wed Aug 08, 2018 1:06 pm    Post subject: Reply with quote

I think that the only part of the stack that Dan wants to R.I.P. is related to local arrays. I don't think that he cares about the stack consumption that is caused by keeping return addresses and passing subprogram arguments. If heavy recursion is not used, and subprogram calls are not deeply nested, this type of stack consumption is nothing to worry about.

Some compilers provide a switch for allocating local arrays on the heap if the required size is above a certain minimum, say 1 kB.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Aug 09, 2018 7:17 am    Post subject: Reply with quote

Mecej4 correctly summarized what my worries are. If processors and software are build with stacks in minds, then OK, let it stay, but the limit for stack in 64bit has to be literally the sky (OS and processor limits and the RAM size) and totally transparent for the programmer i.e. being automatically adjustable by the compiler. It's OK for the pro programmer who want's to mess with the stack get manual adjustments for stack but i have not seen anyone who got any worth his time advantages doing that. Guarantee that everyone who was forced to adjust the stack using this compiler had really bad experience with it.
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
Goto page Previous  1, 2
Page 2 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