Hi, this may sound stupid, but why are local variables actually stored onto the stack? Let me explain in few planes:
Before reading, I am not actually asking about stack as a kind of structure, but I thing of real existing hardware stack structure implemented by stack stack pointer ESP. Just why to use hardware stack instead of creating stack like structure in RAM using direct RAM adreses.
1, Speed: I know a bit of x86 asm, and the local on-stack variables are accessed using indirect adresing. instructions like mov [esp]+4,#0xFFFF . Isn´t indirect adressing actually slower than using direct memory adress? I believe that OS sets the page tables in CPU Memory management unit, so every process actually runs as it had its own adress space, so there would be no rewriting of other process variables. So local variables could be stored just like global ones right into direct RAM adreses.
2, Destruction of old variables: Yes, using stack you can very simply destroy or overwrite old variables, but ou could do the same thing using global ones. Just rewrite the right blocks of RAM and I a sure compiler could handle it just right.
3, Recursive function calls - even this could be solved. When calling functions, you would instead of saving variables onto the stack saved them in order directly into RAM ? Using no stack?
dont get me wrong, I do believe there is a reason why it is implemented as it is, but I just dont know it. Thanks.
9 replies to this topic
#1
Posted 10 August 2010 - 03:31 PM
|
|
|
#2
Posted 10 August 2010 - 06:04 PM
The esp register does point to somewhere in RAM just like all other registers. As far as the computer is concerned there is no difference between the stack and any other memory in the computer (well, almost anyway). In assembly language is it possible to move the stack esp to some other data location. In the old MS-DOS 6.X and earlier days that was exactly what happened during lengthly interrupt routines.
Recirsive functions: It was probably implemented using stacks because that was the simplest, quickest, and safest way to save and restore the function's local data.
Recirsive functions: It was probably implemented using stacks because that was the simplest, quickest, and safest way to save and restore the function's local data.
Visit Grandpa's Forums, a social networking forum, with family-oriented arcade games, blogs, discussion forums, and photo albums.
#3
Posted 10 August 2010 - 10:05 PM
yes you do know a very very small bit , not nearly enought to go and open a thread like this, because if you know enought you wouldnt open a threak like this
and there isnt such a thing as a hardware stack in a computer
and the way you talk about the stack its clearly that you dont have a first idea of how computer functions on the low level, "asembly" level
read up a bit on the theme and them we will talk
and there isnt such a thing as a hardware stack in a computer
and the way you talk about the stack its clearly that you dont have a first idea of how computer functions on the low level, "asembly" level
read up a bit on the theme and them we will talk
#4
Posted 11 August 2010 - 06:57 AM
Well, first, I dont want to argue, I just want to ask, and I asked politely, so we just discuss, thats why opened a thread like this.
Just for you information, THERE IS HARDWARE STACK. Perhaps, before you start teaching me there is not, please take a lok at x86 architecture and its development over the years. But don´t worry I will explain it to you briefly.
There are 2 diferent stack meanings.
First, what you thing it is, and you are of course right, is a type of structure. Stack is structure where data are stored in LIFO structure. You can simply write your owm stack and define you own operations on it, typically called push and pop for entering data and from receiving data.
Second, in x86 architecture (and many others, like 8051, AVR and so...) IS hardware stack. you have stack pointer, which is register especially designed for this purpose. In stack pointer, there is stored adress of memory cell where is the actual top of the stack. There are 2 HW instructions, push and pop with the same meaning as in software stack. But all this is HW implemented right into CPU core functions.
I hope thats enought for you. Next time, you will be sure you know something better, please read something on the subject first. Or ask somebody. Thats what I do. I am just asking here, but I am pretty sure I got "stack" right....
Just for you information, THERE IS HARDWARE STACK. Perhaps, before you start teaching me there is not, please take a lok at x86 architecture and its development over the years. But don´t worry I will explain it to you briefly.
There are 2 diferent stack meanings.
First, what you thing it is, and you are of course right, is a type of structure. Stack is structure where data are stored in LIFO structure. You can simply write your owm stack and define you own operations on it, typically called push and pop for entering data and from receiving data.
Second, in x86 architecture (and many others, like 8051, AVR and so...) IS hardware stack. you have stack pointer, which is register especially designed for this purpose. In stack pointer, there is stored adress of memory cell where is the actual top of the stack. There are 2 HW instructions, push and pop with the same meaning as in software stack. But all this is HW implemented right into CPU core functions.
I hope thats enought for you. Next time, you will be sure you know something better, please read something on the subject first. Or ask somebody. Thats what I do. I am just asking here, but I am pretty sure I got "stack" right....
#5
Posted 11 August 2010 - 08:48 AM
Your confusing two stacks. Although both will be in a memory portion.
The cpu has a stack to save the state of it's registers on - primarly to implement subroutines and to call OS interupt routines, and there is a function stack which stores the parameters for a function, the returns address, a stack pointer etc.
This are different things, code that you execute in a function might push registers onto a stack, and pop them but doesn't pollute it's own stack.
The CPU does contain operands to deal with pushing and poping, but it's still into memory somewhere. (Although I'm not sure what you've imagined a hardware stack is compared to say a stack structure in RAM)
The cpu has a stack to save the state of it's registers on - primarly to implement subroutines and to call OS interupt routines, and there is a function stack which stores the parameters for a function, the returns address, a stack pointer etc.
This are different things, code that you execute in a function might push registers onto a stack, and pop them but doesn't pollute it's own stack.
The CPU does contain operands to deal with pushing and poping, but it's still into memory somewhere. (Although I'm not sure what you've imagined a hardware stack is compared to say a stack structure in RAM)
#6
Posted 11 August 2010 - 09:43 AM
Yes I know, I ment it that way. Of course they are in memory, but C uses especially ESP register for stack operations, thats what I mean by HW stack.
#7
Posted 11 August 2010 - 10:41 AM
esp is not a hardware stack -- its just another register like all the others. And esp can be changed to anywhere you want it (almost).
Visit Grandpa's Forums, a social networking forum, with family-oriented arcade games, blogs, discussion forums, and photo albums.
#8
Posted 12 August 2010 - 12:29 AM
To provide counter-points to some of your questsions
Where as directly accessing memory may be faster than using indirect accessing (this may be subject to hardware speed up, which could negate the impact.) Have you consided why this isn't a good idea? Take a function which has a number of local variables; exactly where do you store these? So say we put them into RAM, when then need to store each address to the variable somewhere...Well we can't hardcode there addresses into the function since the memory address might change, and imagine if we could and we recusivly called the function? But since we, at compile time, know how many variables there are and we know the size of each (since it's a static size) we know where each one is located based on a reference 'ptr' (the stack pointer.) If we had to store directly into memory we would be stuck with a riged program with only global varaibles, where you could only call a at one depth only and who's memory useage would be higher (even if a function is never called space would be needed for it's varaibles.)
Yes you could override the memory, but could you? If I have function a(), which has two local varaibles, placed into locations 1 & 2, and function b() with two local variables, can I share location 1&2 between both a&b? I guess only if a never calls b and b never calls a (and the two varables are the same size.)
So you have a recursive function, function a has two variables, going into location 1 and 2. Those locations are hard-coded in the function, how do then change it to put the memory into location 3,4 on it's next call?
Or do you supose that instead you move the memory? so as you call the function you move what's contained in 1&2 into 3/4, (and whats in 3&4 into 5&6 etc..)? seems pretty expensive an operation, compared to using a pointer and offset.
pokevitek said:
1, Speed: I know a bit of x86 asm, and the local on-stack variables are accessed using indirect adresing. instructions like mov [esp]+4,#0xFFFF . Isn´t indirect adressing actually slower than using direct memory adress? I believe that OS sets the page tables in CPU Memory management unit, so every process actually runs as it had its own adress space, so there would be no rewriting of other process variables. So local variables could be stored just like global ones right into direct RAM adreses.
pokevitek said:
2, Destruction of old variables: Yes, using stack you can very simply destroy or overwrite old variables, but ou could do the same thing using global ones. Just rewrite the right blocks of RAM and I a sure compiler could handle it just right.
Quote
3, Recursive function calls - even this could be solved. When calling functions, you would instead of saving variables onto the stack saved them in order directly into RAM ? Using no stack?
Or do you supose that instead you move the memory? so as you call the function you move what's contained in 1&2 into 3/4, (and whats in 3&4 into 5&6 etc..)? seems pretty expensive an operation, compared to using a pointer and offset.
#9
Posted 12 August 2010 - 11:26 AM
Ancient Dragon, ESP is CPU stack pointer, thus used by push and pop operations.
abzero:
Thank you, you have a point. I see that recursive function call would be nighmare in way I described.
To the first, direct adressing, I would store these right into program. You know, to the end of code space, just include the values. And since you know how big is your program, you know the adress of that variables. If I am coorrect, windows executes multitasking by using CPU paging feature, thus program adress space starts by adress 0.
abzero:
Thank you, you have a point. I see that recursive function call would be nighmare in way I described.
To the first, direct adressing, I would store these right into program. You know, to the end of code space, just include the values. And since you know how big is your program, you know the adress of that variables. If I am coorrect, windows executes multitasking by using CPU paging feature, thus program adress space starts by adress 0.
#10
Posted 12 August 2010 - 12:14 PM
Pokevitek,
yes it is possible to direct address each variable; assuming you have a setup which gives you logical addressing in the process space. Some scripting languages work like this, you can declare a variable in anyscope, actually I believe some early languages lacked variable scope as well.
I think the best way to look at this, is a point I made in my other post.
We have our Program P, in this we have functions {A,B,C} each have two variables. If P consists of n function calls (where n=1=3) then posible programs could be(using => to be call in function, and ',' to be called after):
(1) P = A
(2) P = A,B
(3) P = A,B,C
(4) P = A=>B
(5) P = A=>B=>C
The size of the first 3 programs is 2 memory spaces, the size of the 4th is 4, and the size of the 5 is 6. Given that we want a small footprint we should try and share memory spaces where possible, so if A doesn't call B, then they can share. But if A calls C and C calls B, then they can't etc... Now with a small program this isn't to hard to work out; but image a large program how much extra compile time would it add?
But if you use a stack, you get a compact memory footprint for free; then ofcause it's easier to implement recursive functions. Plus you need a stack for function return addresses.
yes it is possible to direct address each variable; assuming you have a setup which gives you logical addressing in the process space. Some scripting languages work like this, you can declare a variable in anyscope, actually I believe some early languages lacked variable scope as well.
I think the best way to look at this, is a point I made in my other post.
We have our Program P, in this we have functions {A,B,C} each have two variables. If P consists of n function calls (where n=1=3) then posible programs could be(using => to be call in function, and ',' to be called after):
(1) P = A
(2) P = A,B
(3) P = A,B,C
(4) P = A=>B
(5) P = A=>B=>C
The size of the first 3 programs is 2 memory spaces, the size of the 4th is 4, and the size of the 5 is 6. Given that we want a small footprint we should try and share memory spaces where possible, so if A doesn't call B, then they can share. But if A calls C and C calls B, then they can't etc... Now with a small program this isn't to hard to work out; but image a large program how much extra compile time would it add?
But if you use a stack, you get a compact memory footprint for free; then ofcause it's easier to implement recursive functions. Plus you need a stack for function return addresses.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users


Sign In
Create Account


Back to top









