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

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.....

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.....

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.

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.

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.