subroutine stack and C machine model

In Dread Ink, the Grave Hand of Seebs Did Inscribe:

> On 2009-10-12, Kenny McCormack <> wrote:
>> Further, the hyper-literal minded, autistics/Asbergers patient types
>> here, don't do well with allegories.
>
> I am assured by people who apparently give a flying **** that people
> treating patients with autism prefer the phrase "people with autism" to
> "autistics". The name of the syndrome, BTW, is "Asperger's".
>
> However, it is not necessarily the case that people with various
> autism-spectrum traits don't do well with allegories; if anything, many
> of them do exceptionally well with allegories, because they are conscious
> that the allegory is a tool for thinking about something, not the reality
> of the thing described.
>
>>They are, as I'm sure Kiki will
>> tell you by and by, best avoided.
>
> Doubtless. Certainly, if I were jealous of people who were much better
> at something than I, it would make sense for me to tell other people to
> avoid them.
>
> -s

I'm approximately as worried about kiki as I am texas right now. We have
differences.
--
Frank

Most of us here in the media are what I call infotainers...Rush Limbaugh is
what I call a disinfotainer. He entertains by spreading disinformation.
~~ Al Franken

Frank

Frank <> writes:
[...]
> ...and now that Han is back, I'll be interested in his opinion and
> disappointed to read him giving himself as Keith.
[...]

What?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

Frank <> writes:
[...]
> I'm approximately as worried about kiki as I am texas right now. We have
> differences.

"Kiki" appears to be KM's deliberately offensive nickname for me.
I'll thank you not to use it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:

> In
> <8ab64971-735c-48af-8642->,
> Frank wrote:
>
>> I'm looking and talking about a lot of C that is new to me this
>> weekend. Does the abstract machine that is described in the
>> standard have a subroutine stack?
>
> The Standard does not say so. Conceptually, it can help to think of
> nested calls in stack terms: if main calls foo, and foo calls bar,
> and bar calls baz, then it can be useful to think of a stack with
> main at the bottom and bar at the top (with "bottom" and "top" being
> logical terms, not necessarily addressical(tm) terms).
>
>> I've heard before that one can imagine things as a stack, and that
>> wouldn't be wrong, but then again it wouldn't be right.
>
> That's about it, yes. It's a picture that the Standard doesn't quite
> paint, but it can be a useful picture, as long as you don't mistake
> it for a photograph. That is, in terms of portable C programming it
> is not a good idea to assume that your picture is a 100% faithful
> representation of reality. For example, if you decide that you will
> use the stacklike nature of your function call history to work out
> where in memory the return address is stored and then overwrite that
> address with the address of some other routine, that may well work -
> but you would place your program firmly in the land of Undefined
> Behaviour.
>
>> The comment
>> I'm looking for is not what the standard prohibits in terms of
>> allegories.
>
> I don't think the C Standard either allows or prohibits any
> allegories. It is strangely silent on the matter.
>
>> Instead I'm trying to think of what might be useful, given that
>> there is an execution register, and that it amounts to a stack.
>
> What might be useful depends on what you need to do. If you need to
> write portable C code, don't assume a stack. If you need to write
> non-portable C code (that is, if your need for a non-portable feature
> outweighs your need for portability), check your implementation's
> documentation.
>
>> Does C have a function that changes what happens in the execution
>> register?
>
> It's not quite clear what you mean by "execution register". It may be
> that your question is one to which "setjmp/longjmp" might be a
> sensible (or at least not totally nonsensical) answer. Having said
> that, those are not two of my favourite functions.

Ok. Why are they unfavo(u)red?

Will you and PJ obligate yourselves one day to get an editor?

The criticism of writing is a tender place for some. Nichtsdestoweniger,
es bedarf dem(S) Autur(S) der Kleinenleser. Gruß,
--
Frank

It's easier to put on slippers than to carpet the whole world.
~~ Al Franken

Frank

In Dread Ink, the Grave Hand of Ben Pfaff Did Inscribe:

> "I don't have C&V for that handy, but I've got Dan Pop."
> --E. Gibbons

i'LL READ THIS TOMORROW WITH FRESH EYES. MY GUESS IS THAT YOU TOOK FEWER
WOODEN OBJECTS IN YOUR EYES THAN I DID TODAY. CHEERS,
--
Frank

There's no liberal echo chamber in this country. There's a right-wing echo
chamber. I want to create a countervailing echo chamber.
~~ Al Franken, Chicago Tribune interview, on

Frank

On 13 Oct, 08:02, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <ooh15vgl4q35.ueitgdn9lkri$....@40tude.net>, Frank wrote:
> > In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:

> >> It may
> >> be that your question is one to which "setjmp/longjmp" might be a
> >> sensible (or at least not totally nonsensical) answer. Having said
> >> that, those are not two of my favourite functions.
>
> > Ok. Why are they unfavo(u)red?

do you know what they do?

> Personally, I don't like them because they screw up my mental model of
> the code calling hierarchy.

How could this be! They're just an implentation of a continuation!

I'm always a bit nervous about what gets left-behind. As unlike C++
there is no automatic cleanup code invoked. So I'm nervous about malloc
()'d
memory and file handles and such like.


> But just because I don't like them, that
> doesn't mean other people don't like them - it seems that whenever I
> get involved in a C project other than at the beginning, someone has
> already managed to find a way to slip setjmp/longjmp into the mix, so
> like them or not, I still have to know about them, alas.

unlucky you. I havn't yet worked on a project that had them!


> > Will you and PJ obligate yourselves one day to get an editor?

have you been drinking from the same bottle as Tech07?


<snip>

--
> Callbacks are a form of continuation.
Yes, in the same sense that a shoe is a form of aircraft carrier.

Nick Keighley

Keith Thompson wrote:

> Chris Dollin <> writes:
>> Keith Thompson wrote:
>>> To be clear, there must be some stack-like (last-in first-out)
>>> data structure to implement the set of information necessary to keep
>>> track of the currently active set of function calls.
>>
>> Nitpick: only if there's some recursion. Otherwise each function can
>> have its own static area for storing locals & return addresses.
>>
>> If there's no recursion and no function-pointer variables, the compiler
>> could "just" inline everything!
>
> Meta-nitpick: In the abstract machine, the set of currently active
> function calls does behave in a last-in first-out manner, even if
> the implementation pre-allocates activation records and/or doesn't
> take any action to deallocate them when they're no longer active.

Yes.

> An implementation in which a non-recursive program has a statically
> allocated activation record for each function is just another example
> where a "stack" (in the abstract sense) is implemented by a method
> other than a classic contiguous hardware stack.

So much unlike a contiguous hardware stack that it's a nice counter-
example for "C programs need a stack", which is why I was pushing the
nitpick.

For further amusement, take the static areas for the function variables,
and then sort them by variable name or hash of same, so the "stack frames"
themselves are discontiguous.

--
"If time remained, the reasons would have rhymed." - IQ, /Frequency/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Chris Dollin

Chris Dollin a écrit :
>
> So much unlike a contiguous hardware stack that it's a nice counter-
> example for "C programs need a stack", which is why I was pushing the
> nitpick.
>
> For further amusement, take the static areas for the function variables,
> and then sort them by variable name or hash of same, so the "stack frames"
> themselves are discontiguous.
>

Sure sure. You can imagine what you want. It is worth noting that until
now a *single* implementation has been documented that implements
a software stack, for a very marginal processor that lacks a hardware one.

jacob navia

On 13 Oct, 06:42, Frank <fr...@example.invalid> wrote:

> [...] I'm fishing for an execution model that uses the [setjump/longjmp]
> functions. *

poor mans exception handler

Nick Keighley

jacob navia wrote:

> Chris Dollin a écrit :
>>
>> So much unlike a contiguous hardware stack that it's a nice counter-
>> example for "C programs need a stack", which is why I was pushing the
>> nitpick.
>>
>> For further amusement, take the static areas for the function variables,
>> and then sort them by variable name or hash of same, so the "stack frames"
>> themselves are discontiguous.
>
> Sure sure.

Yeah, yeah.

> You can imagine what you want.

I already knew that.

> It is worth noting that until
> now a *single* implementation has been documented that implements
> a software stack, for a very marginal processor that lacks a hardware one.

I thought we had at least two relevant examples -- the IBM 360 et seq
(which don't have a "hardware stack") and the ARM (which doesn't have a
hardware-distinguished stack pointer register and for which the C compiler
uses a mixed strategy where stack frames (managed using the conventional
stack pointer & multi-word load-store instrautions) are allocated out
of stack chunks, which in turn are allocated from the C heap.

--
"Is there a reason this is written in iambic pentameter?" Marten,
/Questionable Content/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Chris Dollin