Click here to Skip to main content
15,867,835 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life but is not for programming questions. Got a programming question?

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.

 
GeneralRe: The youth of today is expected to start early these days. Pin
Chris Aug202213-Jan-23 19:24
Chris Aug202213-Jan-23 19:24 
GeneralRe: The youth of today is expected to start early these days. Pin
Nelek14-Jan-23 8:29
protectorNelek14-Jan-23 8:29 
GeneralRe: The youth of today is expected to start early these days. Pin
Richard MacCutchan13-Jan-23 23:17
mveRichard MacCutchan13-Jan-23 23:17 
GeneralRe: The youth of today is expected to start early these days. Pin
dandy7214-Jan-23 6:39
dandy7214-Jan-23 6:39 
GeneralRe: The youth of today is expected to start early these days. Pin
trønderen14-Jan-23 7:47
trønderen14-Jan-23 7:47 
GeneralRe: The youth of today is expected to start early these days. Pin
trønderen14-Jan-23 3:13
trønderen14-Jan-23 3:13 
GeneralRe: The youth of today is expected to start early these days. Pin
OriginalGriff14-Jan-23 4:16
mveOriginalGriff14-Jan-23 4:16 
GeneralRe: The youth of today is expected to start early these days. Pin
trønderen14-Jan-23 7:42
trønderen14-Jan-23 7:42 
Nowadays, stack is a problem even in Fortran Smile | :)

Recursion didn't enter Fortran until Fortran-90. All memory could be statically allocated. One of the reasons why Fortran has survived so well is that it would never crash on stack overflow (or heap empty), it is 'safe', memorywise. Even though recursion has been allowed from 90 on, seasoned Fortran programmer are not familiar with the term, and won't ever use it Smile | :)

Several other languages of that age did allow recursion, but only with functions explicitly flagged as recursive. Chill and Ada are examples - and for Ada, recursion was only allowed if the maximum recursion depth (hence, stack requirements) could be statically determined, at compile time.

In this case, both the old IV compiler and new 77, "secretly" allowed recursion. The compiler writers used back ends shared with other languages, and they didn't spend resources on making a special stack-less back end for Fortran. The static nature of Fortran made it trivial to determine the maximum stack requirement for a (non-recursive) Fortran program. I suspect that the same was true for a lot of other Fortran compilers as well around the 1970-80s. Actually, memory requirements were reduced, as the static allocation for each function could be reduced, with several functions using the same stack locations if they were not running at the same time. (I have a vague memory of some article claiming that Fortran optimizers could reuse even statically allocated space for different functions that couldn't be active at the same time, but I remember no details.)

Which reminds me of an old thought - warning: sidetrack follows: Smile | :)
(Maybe this should be moved into the 'Architecture' forum)

There is no real reason why stack frames are allocated edge to edge! The stack head has pointer to the frame below, but that pointer could go anywhere. Stack relative addressing never goes outside the current stack frame. Traditionally, even if you have a million objects, each running its own thread, each thread is allotted a stack for its maximum requirements. This can bind up quite a few megabytes that are hardly if ever used, most certainly not all at the same time. Never ever are every single thread preempted at its very deepest nesting of calls at exactly the same time.

Even though you with desktop PCs can just plug in another 64 GiB of RAM to satisfy stack needs, in other systems (such as embedded), this is not always possible.

Stack frames could be allocated from the heap, with space is occupied only as long as a function is active. Thereby, a given amount of RAM would be capable of handling a much larger number of threads. Especially in event driven architectures, a large fraction of threads idle at a low stack level. They receive an event and go into a nest of calls for handling it, after which it return to the low stack level waiting for the next event. The thread might do some sort of 'yield' halfway, but the great majority of threads would be back to 'ground base', or at a moderate call nesting level, most of the time.

The argument against this is of course the cost of heap allocation. There were machines offering micro coded function entry point instructions doing heap allocation from a buddy heap, so stack frame allocation was essentially unlinking the top element from the freelist of the appropriate size. Function return linked the frame to the top of the list. This requires a couple memory cycles for each operation.

Even though another 64 GiB of RAM is cheap nowadays, lots of programmers recoil in horror over buddy allocation: It causes lots internal fragmentation! 25% with binary buddies! Well, but how much can you save in stack requirements? Besides, lots of architectures demand word, doubleword or paragraph stack alignment anyway - that leads to internal fragmentation/waste as well! With a buddy scheme, allocation might be as cheap as two instructions. What is that on the total instruction budget for a modern style method call?

If the allocation cost worries you, lots of optimizations are possible, in particular if frame allocation is the responsibility of the caller. E.g. if a function's stack frame has a lot of unused (internal fragmentation) space calls a function asking for a small frame, it could fit in that internal fragmentation space, not requiring another heap allocation. There are dozens of such optimization.

I never heard of any software allocating stack frames on the heap. I never heard of anyone using the microcoded stack frame heap allocation on the one architecture I know of providing it. Is that because I am ignorant? Smile | :) Is it commonplace? Or has it been considered and rejected? If that is the case, what were the arguments against it?
GeneralRe: The youth of today is expected to start early these days. Pin
OriginalGriff14-Jan-23 7:56
mveOriginalGriff14-Jan-23 7:56 
GeneralRe: The youth of today is expected to start early these days. Pin
trønderen14-Jan-23 8:05
trønderen14-Jan-23 8:05 
GeneralRe: The youth of today is expected to start early these days. Pin
OriginalGriff14-Jan-23 8:28
mveOriginalGriff14-Jan-23 8:28 
GeneralRe: The youth of today is expected to start early these days. Pin
englebart15-Jan-23 5:43
professionalenglebart15-Jan-23 5:43 
GeneralWordle 574 Pin
Sandeep Mewara13-Jan-23 10:37
mveSandeep Mewara13-Jan-23 10:37 
GeneralRe: Wordle 574 Pin
Peter_in_278013-Jan-23 11:18
professionalPeter_in_278013-Jan-23 11:18 
GeneralRe: Wordle 574 Pin
StarNamer@work13-Jan-23 13:04
professionalStarNamer@work13-Jan-23 13:04 
GeneralRe: Wordle 574 Pin
OriginalGriff13-Jan-23 19:41
mveOriginalGriff13-Jan-23 19:41 
GeneralRe: Wordle 574 Pin
pkfox13-Jan-23 21:05
professionalpkfox13-Jan-23 21:05 
GeneralRe: Wordle 574 Pin
Amarnath S13-Jan-23 22:29
professionalAmarnath S13-Jan-23 22:29 
GeneralRe: Wordle 574 Pin
Cp-Coder14-Jan-23 4:41
Cp-Coder14-Jan-23 4:41 
GeneralRe: Wordle 574 Pin
jmaida14-Jan-23 10:40
jmaida14-Jan-23 10:40 
GeneralOld f...s SOTW ;) Pin
0x01AA13-Jan-23 10:28
mve0x01AA13-Jan-23 10:28 
GeneralRe: Old f...s SOTW ;) Pin
Mike Hankey13-Jan-23 10:45
mveMike Hankey13-Jan-23 10:45 
GeneralRe: Old f...s SOTW ;) Pin
jmaida13-Jan-23 17:45
jmaida13-Jan-23 17:45 
GeneralRe: Old f...s SOTW ;) Pin
obermd13-Jan-23 13:45
obermd13-Jan-23 13:45 
GeneralRe: Old f...s SOTW ;) Pin
0x01AA13-Jan-23 13:50
mve0x01AA13-Jan-23 13:50 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.