If a function calls another function, does the stack frame of the first function ends at the point on the stack where the next instruction address of the previous function is stored?
I've created a video to help answer this - I'll get that posted soon in case it helps. If you are asking if the stack frame ends before another function is called, then I would say yes. The frame will consist of optional arguments, the return address and space for local variables. Once a function returns and, depending on convention, cleans up from any arguments, then the stack space for that frame is no longer needed. The next function call is encountered and using space for it's frame appropriately. Functions often call other functions, a frame for a function that calls other functions remains until the parent function is no longer in scope (i.e. it itself has returned). Does this make sense?
Thank you for your answer and yes it does makes sense. I understand things better now and didn't formulate my question properly also, what i meant was if the next instruction address of the "caller" function saved onto the stack refered as "return" can be considered the end of the frame of that same caller function, and yes it can.
Hey Dr. Stroschein, I am a CS student taking assembly language and your videos have helped me so much. One thing I think would help even more is if you made a video of you making a .asm file after explaining the things you do. I know it would make your videos much longer, but I think it would be very beneficial to see application of your lecture in some program to kind of connect the dots.
I'm curious how local stack variables from a fn a or code block a can be accessed by a nested call or block c- temporary "local" variables but not immediately local but still in scope. I imagine this is just more pointer arithmetic and it's the programmer's (compilers) responsibility to know the offset, and there's no law that says esp can't jump anywhere on the stack, even to other frames. Is this right or wrong?
So, if I have this right, local variables need the stack to be changed by their functions, while objects such as structs and classes (as called in C++) are global data, as are their instance variables (as they are known).
Not exactly - local variables are simply variables who uses memory on the stack, this can include basic types (i.e. ints, chars, etc) and structures such as arrays, C++ classes or structures. Typically they are scope limited to the function they are defined in, although they can be passed to other functions which that function calls. Global variables are typically defined in a global scope and reside in a different program segment, such as .data or .rdata. These can essentially be modified by anything that has access to this global scope and their memory is more consistently defined. That is, the memory they used is allocated when the segment they reside in is loaded by the OS. Memory for local variables typically is released back to the OS when the function goes out of scope and those variables are “destroyed”, the stack space they used is released for other functions. Does this help?
@@jstrosch Another thing I'm curious about is how a program places data in its heap. Though I believe that structures can more quickly be added to the stack as pointers.
I'm a computer engineering student, this helped me so much. It is a great explanation and a video, thank you for everything.
Great to hear!
By far the best explanation of this process . Thank you.
Thank you for the feedback!
If a function calls another function, does the stack frame of the first function ends at the point on the stack where the next instruction address of the previous function is stored?
I've created a video to help answer this - I'll get that posted soon in case it helps. If you are asking if the stack frame ends before another function is called, then I would say yes. The frame will consist of optional arguments, the return address and space for local variables. Once a function returns and, depending on convention, cleans up from any arguments, then the stack space for that frame is no longer needed. The next function call is encountered and using space for it's frame appropriately. Functions often call other functions, a frame for a function that calls other functions remains until the parent function is no longer in scope (i.e. it itself has returned). Does this make sense?
Thank you for your answer and yes it does makes sense. I understand things better now and didn't formulate my question properly also, what i meant was if the next instruction address of the "caller" function saved onto the stack refered as "return" can be considered the end of the frame of that same caller function, and yes it can.
Hey Dr. Stroschein, I am a CS student taking assembly language and your videos have helped me so much. One thing I think would help even more is if you made a video of you making a .asm file after explaining the things you do. I know it would make your videos much longer, but I think it would be very beneficial to see application of your lecture in some program to kind of connect the dots.
I'm curious how local stack variables from a fn a or code block a can be accessed by a nested call or block c- temporary "local" variables but not immediately local but still in scope. I imagine this is just more pointer arithmetic and it's the programmer's (compilers) responsibility to know the offset, and there's no law that says esp can't jump anywhere on the stack, even to other frames. Is this right or wrong?
So, if I have this right, local variables need the stack to be changed by their functions, while objects such as structs and classes (as called in C++) are global data, as are their instance variables (as they are known).
Not exactly - local variables are simply variables who uses memory on the stack, this can include basic types (i.e. ints, chars, etc) and structures such as arrays, C++ classes or structures. Typically they are scope limited to the function they are defined in, although they can be passed to other functions which that function calls. Global variables are typically defined in a global scope and reside in a different program segment, such as .data or .rdata. These can essentially be modified by anything that has access to this global scope and their memory is more consistently defined. That is, the memory they used is allocated when the segment they reside in is loaded by the OS. Memory for local variables typically is released back to the OS when the function goes out of scope and those variables are “destroyed”, the stack space they used is released for other functions. Does this help?
@@jstrosch Another thing I'm curious about is how a program places data in its heap. Though I believe that structures can more quickly be added to the stack as pointers.