View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Aug 06, 2018 11:56 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Aug 07, 2018 1:59 pm Post subject: |
|
|
Paul,
Thanks for the advice. The updated info does describe what is happening for 64-bit. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Wed Aug 08, 2018 12:09 am Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Aug 08, 2018 2:34 am Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Aug 08, 2018 2:34 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Aug 08, 2018 7:31 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Aug 08, 2018 1:06 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Thu Aug 09, 2018 7:17 am Post subject: |
|
|
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 |
|
|
|