«

On 3 Mar 2008 at 10:45, jacob navia wrote:
> Recently K. Thompson asked me to specify what did I understand
> with "stack frame". I think that it is important for people using the
> language, that this important concept is clear, so I have produced
> this post.
>
> Obviously, there are some people here that live in some
> special world where all those things do not exist. They should stay
> there and ignore this thread. The same goes for all people that
> program in coffee machines and other primitive processors that
> do not have a stack pointer or enough registers to use a stack
> efficiently.

Jacob,

Your attempts to bring this group into touch with the real world are
admirable, but you must realize by now that they're doomed before they
start?

Noone here is prepared to give you a fair hearing, and noone cares about
stacks and registers or anything that might be tainted by association
with a real computer. The clc zealots aren't going to ignore a thread
just because they have nothing positive to contribute to it.

It's started already, but it's obvious that this thread is just going to
degenerate into a flame war, with HeathField and Thomson strutting,
preening and posturing, while their fawning acolytes (Santosh step
forward) try to cement their position in the Clique by sheer
obsequiousness.

This group just isn't the place for serious discussions about C.

Richard Tobin wrote:
> In article <fqgrl4$44a$>, jacob navia <> wrote:
>
>>> I wouldn't have expected the frame pointer to have any significance
>>> outside the current process (except to a debugger), so I don't know
>>> why "all programs running in the same operating system must agree".
>
>> All programs must call the OS to do I/O. They must respect the OS ABI
>> to call those basic OS routines.
>
> Do any OS ABIs require the caller to take any care of the frame
> pointer?
>

Yes, the frame pointer should be preserved at all times.


> I just looked up the x86 call conventions. As far as I can see, the
> calle saves and restores the frame pointer and does not use its old
> value. So on these systems you do can use it for anyh purpose you
> like.
>

Yes, as I said in my message. Please read it again.


> [If you are called back by these libraries you will presumably have to
> preserve the frame pointer, but that just restricts the functions
> that you can pass in to it.]
>
>> The OS libraries are used by ALL code that runs in that system
>> eventually
>
> No, this is certainly not true. I have used several languages that
> just did system call instructions directly. The normal procedure
> calling convention was irrelevant.

Sure, but even using those "direct" calls, the frame
pointer must be preserved.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:

> santosh wrote:
>>
>> IMO, it would be most appropriate in comp.compilers as the stack
>> frame is more a compiler artifact than anything else.
>>
>
> Yes, compilers are an "artifact" of compiled languages. Obviously
> you think that C is not one of them.

Yes, but C itself doesn't specify that a stack frame is needed, nor the
details of it's setup and manipulation.

> or what ???
>
> Basic knowledge about compiler code generation is needed if you want
> to be able to understand what is going on within your program.

At the machine level. A semantic understanding is possible from just
knowing C and it's standard library. Obviously, it's not sufficient for
things like debugging, interfacing with other languages etc.

> Obviously it is not required, as you can drive a car for miles without
> needing to know that it needs gas to run.
>
> "According to my car user's manual, if I press this pedal the car
> should move. It doesn't say ANYWHERE that gas is needed".
>
> You have the same attitude here, like your big friend.
>
> Why santosh?
>
> You seem reasonable at times.
>
>

I was not saying that knowledge of stack operations are not useful. I
was saying that it is not very topical for this group. Maybe you should
post to <news:comp.lang.asm.x86> or <news:comp.programming> or
<news:comp.compilers.lcc> etc.?

jacob navia wrote:

> Richard Tobin wrote:
>> In article <fqgrl4$44a$>, jacob navia <>
>> wrote:
>>
>>>> I wouldn't have expected the frame pointer to have any significance
>>>> outside the current process (except to a debugger), so I don't know
>>>> why "all programs running in the same operating system must agree".
>>
>>> All programs must call the OS to do I/O. They must respect the OS
>>> ABI to call those basic OS routines.
>>
>> Do any OS ABIs require the caller to take any care of the frame
>> pointer?
>>
>
> Yes, the frame pointer should be preserved at all times.
>
>
>> I just looked up the x86 call conventions. As far as I can see, the
>> calle saves and restores the frame pointer and does not use its old
>> value. So on these systems you do can use it for anyh purpose you
>> like.
>>
>
> Yes, as I said in my message. Please read it again.
>
>
>> [If you are called back by these libraries you will presumably have
>> [to
>> preserve the frame pointer, but that just restricts the functions
>> that you can pass in to it.]
>>
>>> The OS libraries are used by ALL code that runs in that system
>>> eventually
>>
>> No, this is certainly not true. I have used several languages that
>> just did system call instructions directly. The normal procedure
>> calling convention was irrelevant.
>
> Sure, but even using those "direct" calls, the frame
> pointer must be preserved.

In point of fact, this isn't necessary under Linux x86.

polas wrote:

> A very quick question (possibly slightly off topic - sorry if so)
> apart from the stack pointers for functions, and the heap for dynamic
> allocation, is there any other memory storage commonly used and
> refered to?

In embedded ("non-hosted") environments, it is not unusual for
I/O space to be mapped onto memory space. Mapped I/O may or may
not exhibit storage characteristics.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

In article <fqgubh$d4q$>, jacob navia <> wrote:

>> Do any OS ABIs require the caller to take any care of the frame
>> pointer?

>Yes, the frame pointer should be preserved at all times.

But why?

>> I just looked up the x86 call conventions. As far as I can see, the
>> calle saves and restores the frame pointer and does not use its old
>> value. So on these systems you do can use it for anyh purpose you
>> like.

>Yes, as I said in my message. Please read it again.

You seem to be contradicting yourself. You say it must be preserved
at all times, and then you agree you can use it for any purpose.
Please explain.

>> No, this is certainly not true. I have used several languages that
>> just did system call instructions directly. The normal procedure
>> calling convention was irrelevant.

>Sure, but even using those "direct" calls, the frame
>pointer must be preserved.

Why? What happens if you don't?

-- Richard
--
:wq

On Mon, 3 Mar 2008 07:53:12 -0600, santosh wrote
(in article <fqgv5o$u6o$>):

> jacob navia wrote:
>> Yes, the frame pointer should be preserved at all times.

[snip]

>>> No, this is certainly not true. I have used several languages that
>>> just did system call instructions directly. The normal procedure
>>> calling convention was irrelevant.
>>
>> Sure, but even using those "direct" calls, the frame
>> pointer must be preserved.
>
> In point of fact, this isn't necessary under Linux x86.

How did this -fomit-frame-pointer option make its way into my compiler?
BTW, it's not running on Linux either.





--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Richard Tobin wrote:
> In article <fqgubh$d4q$>, jacob navia <> wrote:
>
>>> Do any OS ABIs require the caller to take any care of the frame
>>> pointer?
>
>> Yes, the frame pointer should be preserved at all times.
>
> But why?
>
>>> I just looked up the x86 call conventions. As far as I can see, the
>>> calle saves and restores the frame pointer and does not use its old
>>> value. So on these systems you do can use it for anyh purpose you
>>> like.
>
>> Yes, as I said in my message. Please read it again.
>
> You seem to be contradicting yourself. You say it must be preserved
> at all times, and then you agree you can use it for any purpose.
> Please explain.
>

A procedure can use any reserved register but the stack pointer
to any purpose anywhere, it needs only to save its value in
the stack, then restore it later. The value is preserved.

Obviously, if you do not preserve the stack pointer, many programs like
the debugger and others will no longer work, but in principle
your program will run without any problem.

>>> No, this is certainly not true. I have used several languages that
>>> just did system call instructions directly. The normal procedure
>>> calling convention was irrelevant.
>
>> Sure, but even using those "direct" calls, the frame
>> pointer must be preserved.
>
> Why? What happens if you don't?


If you do not preserve the stack pointer, you BREAK the
frame pointer chain, what means that you will destroy the possibility of
returning to the calling functions.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Randy Howard wrote:

> On Mon, 3 Mar 2008 07:53:12 -0600, santosh wrote
> (in article <fqgv5o$u6o$>):
>
>> jacob navia wrote:
>>> Yes, the frame pointer should be preserved at all times.
>
> [snip]
>
>>>> No, this is certainly not true. I have used several languages that
>>>> just did system call instructions directly. The normal procedure
>>>> calling convention was irrelevant.
>>>
>>> Sure, but even using those "direct" calls, the frame
>>> pointer must be preserved.
>>
>> In point of fact, this isn't necessary under Linux x86.
>
> How did this -fomit-frame-pointer option make its way into my
> compiler?

That doesn't matter since you cannot make direct system calls in C
anyway.

> BTW, it's not running on Linux either.

Jacob was saying that the frame pointer (in his case: EBP) must be
preserved even for direct system calls. I was saying that it is not
necessary, at least under Linux/x86. In fact EBP can be used for a
parameter, if needed.

What gcc does within the program is just another point against what
Jacob is saying. He may have confused the frame pointer with the stack
pointer.

>
>
>
>
>

In article <fqh01e$io3$>, jacob navia <> wrote:

>A procedure can use any reserved register but the stack pointer
>to any purpose anywhere, it needs only to save its value in
>the stack, then restore it later. The value is preserved.

A procedure that's called from a procedure that expects the frame pointer
to be preserved has to preserve it. If your entire program consists
of functions that don't expect it to be preserved, you don't have to.

If your functions don't save the stack pointer but call library
functions that do, there is no problem. It's only if you are *called*
by functions that expect it to be preserved that you have to worry.

In short, you don't have to follow any convention about the frame
pointer in order to call library functions.

>>> Sure, but even using those "direct" calls, the frame
>>> pointer must be preserved.

>> Why? What happens if you don't?

>If you do not preserve the stack pointer, you BREAK the
>frame pointer chain, what means that you will destroy the possibility of
>returning to the calling functions.

How does this arise when doing a system call?

-- Richard
--
:wq