subroutine stack and C machine model

[Frank]

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

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.


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

 

[Keith Thompson]

...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]

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.

 

[Frank]

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

In


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).


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.


I don't think the C Standard either allows or prohibits any
allegories. It is strangely silent on the matter.


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.


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]

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

 

[Nick Keighley]

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!


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.

 

[Chris Dollin]

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.

 

[jacob navia]

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.

 

[Nick Keighley]

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

poor mans exception handler

 

[Chris Dollin]

Chris Dollin a écrit :

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

 

[Dik T. Winter]

>
> I don't know what you mean here.

I think Frank is criticising your use of British spelling. Interesting though
that his sentence would have improved considerably when its advise had been
followed on itself.

 

[jacob navia]

Chris Dollin a écrit :

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.

Sure sure. Please read the ARM architecture description. You are talking
nonsense.

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...


http://www.arm.com/pdfs/ARMv6_Architecture.pdf page 9
That architecture supports even multiple stacks.

But I have had my dose of this. I will not reply to
further remarks of this style.

 

[Nick Keighley]

Chris Dollin a écrit :

[machines without dedictaed hardware stacks]

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...

with a bit of googling:-

"The zSeries line succeeded the System/390 line (S/390 for short),
maintaining
full backward compatibility. In effect, zSeries machines are the
direct, lineal
descendants of System/360, announced in 1964, and the System/370 from
1970s.
Applications written for these systems can still run, unmodified,
with only
few exceptions, on the newest System z over four decades later."

 

[bartc]

Chris Dollin a écrit :

[machines without dedictaed hardware stacks]

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...

with a bit of googling:-

"The zSeries line succeeded the System/390 line (S/390 for short),
maintaining
full backward compatibility. In effect, zSeries machines are the
direct, lineal
descendants of System/360, announced in 1964, and the System/370 from
1970s.
Applications written for these systems can still run, unmodified,
with only
few exceptions, on the newest System z over four decades later."

Without actually delving into the details, being backwards compatible
doesn't preclude the newer models from having hardware stacks.

 

[Dik T. Winter]

> Chris Dollin a écrit :
>
>
> Sure sure. Please read the ARM architecture description. You are talking
> nonsense.

What is the hardware-distinguished stack pointer register of the ARM?

> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...

What about the IBM 370, 390, Z-series?

 

[Dik T. Winter]

>
> Without actually delving into the details, being backwards compatible
> doesn't preclude the newer models from having hardware stacks.

S/390 certainly had no hardware stack the last time I looked in the
instruction set manual.

 

[Stefan Ram]

Nitpick: only if there's some recursion. Otherwise each function can
have its own static area for storing locals & return addresses.

There is another case, where this will not work:

When there are many functions with a huge size of
automatic storage, but during each run of the program
only one of them is being called.

With memory allocation at run-time only the memory
for the one function called will be allocated, which
might still fit into available memory.

When automatic memory is allocated statically once for
every function, the total amount of memory allocated
might exceed memory limitations.

~~

Otherwise, you always can allocate n copies of the
activation record of a function statically, an then
say that this will work, unless there is recursion
of a depth that is larger than n.

 

[Chris Dollin]

Chris Dollin a écrit :


Sure sure. Please read the ARM architecture description. You are talking
nonsense.

I see you're referring to newer ARMs here. I'm afraid I haven't kept up
with the updates to the instruction set; as I remarked in earlier (MUCH
earlier) messages, I'm speaking from my experiences of many years ago.
My bad for not supplying that particular piece of context.

(As far as I can tell, the stack-handling referred to in that document
is for /interupts/, not normal C function calls. Gosh, and it looks
like they've added a bunch of unconditional instructions. Well, they did
say that condition NEV was to be treated with caution ...)

--
"I'm far too ditzy to grasp the subtleties of mockery." Raven,
/Questionable Content/

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

 

[Chris Dollin]

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...

You ignored the "et seq" in my message; the 360 left descendents.

--
"Common concerns such as property damage and wholesale Pintsize
destruction are of no concern to the king!" /Questionable Content/

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

 

[Chris Dollin]

Chris Dollin a écrit :

[machines without dedictaed hardware stacks]

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...

with a bit of googling:-

"The zSeries line succeeded the System/390 line (S/390 for short),
maintaining
full backward compatibility. In effect, zSeries machines are the
direct, lineal
descendants of System/360, announced in 1964, and the System/370 from
1970s.
Applications written for these systems can still run, unmodified,
with only
few exceptions, on the newest System z over four decades later."

Without actually delving into the details, being backwards compatible
doesn't preclude the newer models from having hardware stacks.

While the new models might have acquired stacks, old code running on
them very likely doesn't use them, so they'd continue to be examples
of code that doesn't use hardware stacks.