Frames - conceptual problem.

[Chip]

I have a problem with the concept of frames.  Not the actual commands,
or even the organization of the stack, - but the whole concept.
I keep waiting for the "Oh!...I get it!  Lightbulb to come on, but so far it
eludes me.

In other words:
     Why utilize the concept of a "reserved storage" frame for storing data?
     Is the frame somehow tied into the primary and secondary CPU cache?
     Did it have some use under segmented memory, but not under a "flat" memory model?
     Assembler has many devices for referencing memory, what is the advantage here?
     Is it used in the"C" languages, and included here for compatability?
           (I have never programmed in C.)

I don't doubt that it is a helpful construct.  I just "don't get it! - YET!

Chip

[Boucly]

Are you trying to ask How is the stack useful when it is stored in reverse order?

I read it somewhere that it is something to do with compatibility with data sizes.

Anyway, here is what I think why:

As you know, when someone pushes a DWORD data into the stack, it is in a way reversed:
original data : F0 5D 6F 6A
the data in the stack is 6A 6F 5D F0
When you pop it back out, it is reversed again. It pops every byte (thats every pair) until the size of the data is filled up.

Think out about what would happen if it is not pushed in reverse with all the other before it jumbled up.
orginal data : F0 5D 6F 6A
that data in the stack would be F0 5D 6F 6A
When you pop it out, the processor has to find out what the data size is, uses "SP - data size" to find out where the data starts and personally, I don't think it is efficient enough if it is used as often as it is.

My own comment: Okay, that probably confused you more, since, well, firstly, I am not a native English speaker; secondly, I tend to make the trouble worse whenever I tried to help someone (it's like a curse); and thirdly, I think of these kind of things like a rule (like, 1 + 1 is 2 and why not used the character 3 to represent 2 [actually, there is a reason, but I don't want to go into that]), I just follow them and the reason will seem clearer as you go further into it. (Yep, I am so good at Maths that I know why 2 is 2 and 3 is 3... just joking... I am only at A-level... okay bad joke :()

If you really don't get it, post again, I am sure someone will read this again eventually with a post, I think...

Hope it helped and good luck,
Boucly

[jorgon]

Hi Chip, welcome to the forum.
One main reason you need frames (ie. stack frames) in Windows programming is that the system calls your program with recursive messages.  In fact it calls your window procedure (this is called a "callback" procedure).  The recursion occurs because many messages result in the system calling your window procedure again with other messages.  When this happens, your window procedure is called again before the first call returns.  Hence the need to keep message data sent by the system on the stack.  By keeping the data on the stack you ensure that it is not overwritten by the data from the next message.  Instead the data from the next message is kept further up the stack.  This is achieved using the stack frame.

[Chip]

Jorgon,

If I may restate your explanation in my own words:

The stack or frame is a windows construct, and not something inherit
in the CPU instruction set.  It's purpose is to be a first in/last out "buffer"
for holding messages or parameters passed between windows procedures. 

This "stack" of messages may grow faster than either the called or calling
procedure can actually process them.  Hence, the the stack provides very
specific procedures for placing messages onto the stack and removing them
in a sequential manner. 

(I think of old office methods, where invoices and other "messages" were
litterly pushed onto a metal spike so that they would maintain thier
"date recieved" order for later processing)

And, I gather that other methods, such as the unrelated use of the stack to
temporarily store variables, have grown simply because of the availability
of this resource.  While it is a construct required by windows, it can also
be used by any programmer if proper procedures are followed.

Finally, I presume that it is fast because any section of memory that is
frequently used will have already been mapped into the CPU's primary
or secondary memory cache.

Chip




PS; Boucly - Thanks for the "tree" explanation.
      However, I was still trying to figure out what a "forest" is
      (English expression - "Can not see the forest through the trees"

[Boucly]

Hello again, Chip, I know my last reply was in no way helpful from what I read. I hope this will help though.

The stack or frame is a windows construct, and not something inherit
in the CPU instruction set. It's purpose is to be a first in/last out "buffer"
for holding messages or parameters passed between windows procedures.

I think a frame is a data storage of messages passing between windows that take advantage of what already exist in the processor itself, not a window construct, because the push and pop instructions are in all processors, I think.

This "stack" of messages may grow faster than either the called or calling
procedure can actually process them.  Hence, the the stack provides very
specific procedures for placing messages onto the stack and removing them
in a sequential manner.

(I think of old office methods, where invoices and other "messages" were
litterly pushed onto a metal spike so that they would maintain thier
"date recieved" order for later processing)

In my opinion, that's only true for a very processor-intensive program or a badly-coded program because they either required so many message passing that they quickly consumes the stack or the program was so messed up that they message passed are not handled, are left and ignored.

And, I gather that other methods, such as the unrelated use of the stack to
temporarily store variables, have grown simply because of the availability
of this resource.  While it is a construct required by windows, it can also
be used by any programmer if proper procedures are followed.

Oh, right. Correct me if I understand you wrongly: the stack is something that used by windows, and variable storing from programs are things that takes advantage of its speed. Okay, I think it should be the other way round. The processor has instructions to organise a stack. The stack or frame is a temporary storage for quick access without allocating space beforehand.  Windows uses this to pass message between procedures since it could be in a way limitless. I really don't think that the stack is a windows thing because it can still be accessed in DOS or other OS's.

Finally, I presume that it is fast because any section of memory that is
frequently used will have already been mapped into the CPU's primary
or secondary memory cache.

I understand why registers are quicker and faster (I think) but stack though, I don't know.

regards,
Boucly

[donkey]

Jorgon,

If I may restate your explanation in my own words:

The stack or frame is a windows construct, and not something inherit
in the CPU instruction set.  It's purpose is to be a first in/last out "buffer"
for holding messages or parameters passed between windows procedures.

I disagree with that, stack frames are inherently supported by the CPU, see the ENTER/LEAVE instructions also the CPU has dedicated stack pointers, the fact that Windows makes use of them is inconsequential to the fact that they are inherently supported both in the instruction set and by the x86 architecture. The stack frame, the stack and it's associated instructions are part of the processor and not a Windows construct.

[Chip]

Donkey,

That is an interesting point that you make.  But, it then
almost brings me full circle back to my original question
on the concept of stack frames.

For instance, if you were designing the CPU and it's associated
instruction set, why would you inplement stack frames. 

At first it made sense as a windows construct for passing
parameters, as Jorgon indicated.  But, as a pure CPU feature,
what would be the reason - and advantage - for including it.
(I know that you are not a cpu designer, but you do seem to
possess a lot of knowledge in this area.)

The precisness of the answer is not so important as the general
nature of the answer.  I have a pretty good mental model of the
CPU, memory and archetecture of the system in my head, but
the "arrow" that points to stack frames ends in a vague cloud
of ....  well, I don't know!  (Smile)

(My original experience is with Assembler on an IBM Mainframe.
At that time, the concept of a stackframe did not exist.)

Chip

[Boucly]

For instance, if you were designing the CPU and it's associated
instruction set, why would you inplement stack frames.

At first it made sense as a windows construct for passing
parameters, as Jorgon indicated. But, as a pure CPU feature,
what would be the reason - and advantage - for including it.
(I know that you are not a cpu designer, but you do seem to
possess a lot of knowledge in this area.)

I know you are refering to Donkey and personally I have extremely limited knowledge about processors; so, I did some research. As it happens one of the first pages that comes up when I google it is Wikipedia.

Wikipedia The Free Encylopedia - Call Stack / Stack Frame

A quote from Wikipedia:

As noted above, the primary purpose of a call stack is:

Storing the return address – When a subroutine is called, the location of the instruction to return to needs to be saved somewhere. Using a stack to save the return address has important advantages over alternatives. One is that each task has its own stack, and thus the subroutine can be reentrant, that is, can be active simultaneously for different tasks doing different things. Another benefit is that recursion is automatically supported. When a function calls itself recursively, a return address needs to be stored for each activation of the function so that it can later be used to return from the function activation. This capability is automatic with a stack.

So, the original point of the SP is for jumping back after jumping out of the original sequence.

One problem with that though is that I am not quite sure whether I should trust Wikipedia since it is a web source, so you can only believe that to an extent unless you have other proofs.

Boucly

[jorgon]

Chip

The messages are recursive by design and it has nothing to do with speed. The reason is that the point of code execution can only be in one place at one time (where there is a single processor).
An example of the recursive nature of the messages is WM_PAINT.  This would be sent by the system to your window procedure when the window needs to be painted (eg. when a window in front of it has been moved away by the user).  Your window procedure would call the API BeginPaint upon this message.  But BeginPaint does not return until it has sent another message to your window procedure.  This is WM_ERASEBKGND. This message causes the erasure of the background of the appropriate part of the window ready for painting (if so desired).  So now your window procedure is dealing with WM_ERASEBKGND.  After that message has returned to the system, BeginPaint will return.  You can see from this that code execution is only in one place at any one time, but it might return to the same place more than once at different times.
You can see all this going on with a good debugger.

See these tutorials which you may find interesting:-

Understanding the stack - Part 1

Understanding the stack - Part 2

Various stack tests

Recursion in window procedures

Messages around the system

Some of the above articles are from the GoAsm help files which come with GoAsm.   Some are with Testbug which is a free program available from here and which enables you easily to view these happenings with a debugger.

See also a list of all "Go" tutorials.