Statement on Schildt submitted to wikipedia today

[spinoza1111]

You're feeding the troll.

"You're talking to the Jew."

"Troll" is used isomorphically to anti-Semitic usage and is a species
of Nordic racism. Furthermore, "trolls" post insincerely in order to
get a rise out of people, whereas I believe that Seebach and Feather
set out to destroy a person in order to defend the profits of vendors,
and thereby curry favor. Once again, I'll thank you to stop using that
ugly word, "troll".

It's not a logical stack, it's a logical linked list!
Each function's autos can certainly be thought of as being
clumped together, but there's no reason to think that one
functions autos are in any way spacially related to any
other function's.

Nothing, of course, is anything in particular: computer storage is
ultimately a nominalist ontology. But if a programmer makes progress
by crafting a "soft" stack, or by treating something as a stack, he's
smarter than you, or any person who goes around using Fascist
terminology, you dig me?

There are two types of people in this discussion. Meaning creators
like Navia, and meaning destroyers like you, and Seebach, who would
rather destroy meaning than see the profits of their employers reduced
by one iota.

Monsieur Navia, my language is extreme. But look what happens in
general politics to those who do NOT use extreme language: look what's
happening to Professor Obama. It's time to start fighting back.

 

[osmium]

I can say that in 30 years programming in C I never saw a machine
without a hardware stack or a dedicated register for that purpose.

We have discussed this stuff to death and regulars never came
with an example of a relevant architecture.

The Univac 1100 series of mainframes had no stack and it was most certainly
active and relevant 30 years ago. And yes, there was a C compiler for it.
I don't usually follow these interminable discussions so I don't know what
has already been said, and don't really care all that much.

I did notice a very nice post by Keith Thompson upstream regarding what a
"stack" is, he realizes that it is a Real Good Idea to decide what one is
talking about before starting an argument; that is logic 101. If I had
control of the FAQ, I would put his couple of very germane paragraphs in it.

 

[Chris Dollin]

Chris Dollin a écrit :
Excuse me but:

<quote>
3.2.1 The stack pointer, SP or R13
Register R13 is used as a stack pointer and is also known as the
SP register
<end quote>

ARM Architecture: Chapter 3. Page 26

Now you tell me that C doesn't use register R13?

Of /course/ I'm not telling you that; read the message I wrote.
I'm telling you that a particular ARM C implementation doesn't
blindly use R13 as a stack pointer in the usual sense as "there's
a contiguous region of store indexed by SP and that's the stack."

It /could/ use R7 instead, if it chose, and use SP to hold function
results. While such a choice might be ... questionable ..., the
fact that it's /possible/ suggests to me that strong assertions
about "SP" and "hardware stack" are ... also questionable.

Please, we have had this discussion a thousand times. You are confusing
passing arguments in some registers with absence of a stack.

No, I'm not. The two issues are of course /related/. /You/ are
confusing convention with hardware [there's nothing that
SP does that R1 cannot do, /apart from/ SP being shadowed; the
use of SP as a "stack pointer" is a software convention that
a user-space application is free not to follow at its own
[in]convenience.

The ARM C stack is /not contiguous/; it's a linked list of
stack chunks. Keith's message contrasted:

with

|> The other is a data structure with last-in first-out (LIFO) behavior.
|> This kind of stack can be implemented in a variety of ways: as a
|> contiguous array, as a linked list, or as organized flocks of carrier
|> pigeons.

Your

]> I would like that you provide an example. I strongly believe that
]> you have none, or some dead system decades ago.

I read as providing an example of a C implementation that doesn't
use Keith's first meaning. I provided one.

Are you saying that (a) that's not what you were asking or (b) that
my example satisfies Keith's /first/ meaning?

This is called "passing arguments in the registers".

Which is /not/ "passing arguments on the stack".

This is done
by lcc-win in all 64 bit x86 targets and in the power PC version.
You are confusing this calling convention with the absence of a
stack.

I note you haven't commented on the /stack-free/ definition of
`inc`. Not all C functions need the stack, hardware or otherwise.

System 360 was developed last century in the sixties. Great example of
a CURRENT architecture.

Wikipedia ... 360 ... 370 ... 390 ...

In 2000, the System/390 was replaced by the zSeries. The zSeries
mainframes introduced the 64-bit z/Architecture, the most significant
design improvement since the 31-bit transition. All have retained
essential backward compatibility with the original S/360 architecture
and instruction set.

I stress that last sentence. I'm /assuming/ that "essential backward
compatability" means that there isn't additional special support in
user-space for "a hardware stack".

And anyway, you are wrong. Mainframes also have a stack obviously.

There's nothing in the least obvious about it [1] if what you mean is
Keith's first meaning. If it's Keith's /second/ meaning, ie some
LIFO-organised store, well duh, for some applications I'm sure
they do: stacks are useful, especially for nested procedure calls.

But /special hardware support/ for a contiguous stack with a dedicated
register isn't a requirement, even if it would be useful.

[1] Independantly of whether it's true.

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

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

 

[Chris Dollin]

This in effect was a stack, because it is not necessary (it is per
accidens) that a stack be contiguous, and your interlocutors,
Monsieur, don't see a stack unless it is called a stack. This means
that they can't see a duck when it quacks if their story book doesn't
say its a duck.

Nonsense. Keith's message upthread says:

<<< begin quote

The word "stack" has two relevant meanings.

One is a hardware stack, which advances in a particular direction
through contiguous memory. This is a common, but not universal,
method used in C implementations.

The other is a data structure with last-in first-out (LIFO) behavior.
This kind of stack can be implemented in a variety of ways: as a
contiguous array, as a linked list, or as organized flocks of carrier
pigeons.

Quack.

--
"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

 

[Gus Gassmann]

You use language oddly. I'd always thought "vandalism" applied to
property not persons. Perhaps to you Schildt is an owned property.

Ahh! That's what the OP meant. I thought he called Schildt a vandal.
Minor difference.

 

[Keith Thompson]

I can say that in 30 years programming in C I never saw a machine
without a hardware stack or a dedicated register for that purpose.

Nor have I, but my experience is not universal. Well, actually I
probably have seen such machines, but I've never interacted with them
closely enough for the issue to come up.

We have discussed this stuff to death and regulars never came
with an example of a relevant architecture.

Concrete examples have been posted several times.

Some IBM mainframe implementations, as I understand it, do not
use a contiguous stack; instead, the activation record for each
function call is allocated from something like a heap, and the
"stack" is actually a linked list of activation records, with no
necessary relationship among their memory locations.

These systems are still in production use.

There must be a "stack" in the sense of a LIFO data structure;
this is necessary to support recursion. There needn't be something
commonly referred to as "*the* stack", a contiguous region of memory
with a specific direction of growth.

This has been mentioned here multiple times. (Perhaps you didn't
believe it because of who mentioned it.)

And even if all existing architectures used a classic hardware
stack, the fact remains that the C language doesn't require this,
and it's entirely possible (and IMHO clearer) to discuss C without
referring to "the stack". And it would still be possible for some
future conforming C implementation to use something other than a
classic hardware stack.

 

[Keith Thompson]

System 360 was developed last century in the sixties. Great example of
a CURRENT architecture. And anyway, you are wrong. Mainframes
also have a stack obviously.

In what sense is that obvious?

If you're saying that it's obvious that mainframes use a contiguous
hardware stack, I disagree, and I'll ask you to justify your
statement. If you mean something else, then what exactly do you mean?

 

[Dan Henry]

Keith Thompson a écrit :

I can say that in 30 years programming in C I never saw a machine
without a hardware stack or a dedicated register for that purpose.

We have discussed this stuff to death and regulars never came
with an example of a relevant architecture.

For example, many of the very popular Microchip PIC microcontroller
families in common use today have only a limited call/return stack and
no data stack.

 

[Flash Gordon]

The question was not whether or not a machine had a hardware stack or
a dedicated register for that purpose; it was whether a C implementation
/used/ such a hardware stack or stack pointer register. And not all
of them do, not all of the time. I'm pretty sure the IBM 360 didn't
(doesn't) have a dedicated stack or stack register /in hardware/
for function calls. (What it does with interrupts I have never had
to learn, or at elast if I learned it I have forgotten.)

There are also processors which have a dedicated hardware stack (which
is called a stack in the processor manual) on which the "standard" C
implementation deliberately avoids using the sack most of the time. The
simple reasons for this being that the stack is only 8 words deep and
there is no accessible stack pointer so *all* you can do is push values
on and pop values off (a call pushes the program counter and a return
pops it, in addition there are push and pop instructions, normally used
to pop return values off the stack before it overflows and push them
back again later). There is a convention of using AR7 as a software
stack pointer, and a convention on which direction it grows, but you
could equally well use any of the other indirect registers (you would
probably not use AR0 because it has other uses) and because of the way
the registers work you could have the stack grow either up or down with
no loss of performance.

I'm sure I've mentioned the processor I'm thinking of, the TMS320C25
(which is one of my favourite processors) in these discussions before,
but I could be wrong.

 

[Flash Gordon]

The question was not whether or not a machine had a hardware stack or
a dedicated register for that purpose; it was whether a C implementation
/used/ such a hardware stack or stack pointer register. And not all
of them do, not all of the time. I'm pretty sure the IBM 360 didn't
(doesn't) have a dedicated stack or stack register /in hardware/
for function calls. (What it does with interrupts I have never had
to learn, or at elast if I learned it I have forgotten.)

There are also processors which have a dedicated hardware stack (which
is called a stack in the processor manual) on which the "standard" C
implementation deliberately avoids using the sack most of the time. The
simple reasons for this being that the stack is only 8 words deep and
there is no accessible stack pointer so *all* you can do is push values
on and pop values off (a call pushes the program counter and a return
pops it, in addition there are push and pop instructions, normally used
to pop return values off the stack before it overflows and push them
back again later). There is a convention of using AR7 as a software
stack pointer, and a convention on which direction it grows, but you
could equally well use any of the other indirect registers (you would
probably not use AR0 because it has other uses) and because of the way
the registers work you could have the stack grow either up or down with
no loss of performance.

I'm sure I've mentioned the processor I'm thinking of, the TMS320C25
(which is one of my favourite processors) in these discussions before,
but I could be wrong.

 

[Ben Bacarisse]

jacob navia wrote:

Wikipedia ... 360 ... 370 ... 390 ...


I stress that last sentence. I'm /assuming/ that "essential backward
compatability" means that there isn't additional special support in
user-space for "a hardware stack".

I believe so. As I understand it, the zSeries has not added support
for a hardware stack. Of course, a compiler is free to pick a
register and use one of the indexed addressing modes to treat some
part of the address space like a stack, but most compilers won't do
that unless that are part of a project to implement an OS[1]. If you
have to interface with an IBM OS you would use the OS's method of
chaining memory blocks into a linked list. The hardware does have
support for this method of calling a function.

[1] I say that because I think that is what happens when you run
Linux + gcc on a zSeries machine.

<snip>

 

[luserXtrog]

I cannot believe that someone as knowledgeable as Seebach would claim
that the increment and decrement operators had no meaning. I suspect
your
poor knowledge of C and difficulty with technical language led you
astray.

I'm also sure he didn't say they "had no definite timing"
(whatever *that* means!)

Perhaps it's Kant/Heisenberg kinda thing. Time is an attribute of
one's perception of the world; not an attribute of the world itself.
Unless one establishes a timing framework, time itself has no meaning.
Because before a number can be incremented, it must be half-way
incremented, or else you'll end up with a Quantum Leap with
The Boy with Green Hair. And that won't do at all.

 

[luserXtrog]

You use language oddly. I'd always thought "vandalism" applied to
property not persons.

It's also racist against the Vandals. But what can one expect
from a Cretan Boeotian?

 

[spinoza1111]

jacob navia wrote:

Wikipedia ... 360 ... 370 ... 390 ...

I stress that last sentence. I'm /assuming/ that "essential backward
compatability" means that there isn't additional special support in
user-space for "a hardware stack".

I believe so.  As I understand it, the zSeries has not added support
for a hardware stack.  Of course, a compiler is free to pick a
register and use one of the indexed addressing modes to treat some
part of the address space like a stack, but most compilers won't do
that unless that are part of a project to implement an OS[1].  If you
have to interface with an IBM OS you would use the OS's method of
chaining memory blocks into a linked list.  The hardware does have
support for this method of calling a function.

A linked list accessed at one end only IS a stack. If it walks like a
duck and quacks like a duck it is a duck.

[1] I say that because I think that is what happens when you run
Linux + gcc on a zSeries machine.

<snip>

 

[spinoza1111]

For example, many of the very popular Microchip PIC microcontroller
families in common use today have only a limited call/return stack and
no data stack.

The stack as an Idea is independent of whether or not it is
implemented, or implemented correctly. Here is a paper by Dijsktra on
how the subroutine call/return facility on the old IBM 1620 was messed
up, by a company with a track record in the 1960s of ignoring the
stack:

http://www.cs.utexas.edu/~EWD/transcriptions/EWD00xx/EWD37.html

Schildt used the stack to explain things. Seebach seems to prefer
ignorance.

 

[spinoza1111]

[...]

System 360 was developed last century in the sixties. Great example of
a CURRENT architecture. And anyway, you are wrong. Mainframes
also have a stack obviously.

In what sense is that obvious?

If you're saying that it's obvious that mainframes use a contiguous
hardware stack, I disagree, and I'll ask you to justify your
statement.  If you mean something else, then what exactly do you mean?

Stop harassing (what you would call "trolling" him), like a creep
lawyer. A stack can be a set of contiguous memory locations. A stack
can be a linked list. A stack can be a linked list of contiguous
memory locations. A stack can be a set of contiguous memory locations
containing pointers to linked lists.

A stack can be a box of papers in a clerk's box with priority papers
at the top. A stack can be a set of punched cards. A stack can be a
set of cards in Vegas in some sort of game of chance in which the
playuh must take a card from the top.

Hor: Oh day and night: but this is wondrous strange.

Ham: And therefore as a stranger giue it welcome.
There are more things in Heauen and Earth, Horatio,
Then are dream't of in our Philosophy.

The only fact of interest (cf Knuth) is whether the stack is accessed
solely or mainly at one end.

You nag this individual with questions that make no gentle and
collegial assumption of his competence, starting from the null or zero
point of the hostile policeman or jagoff cop, although he's developed
a good compiler.

You pretend that this offensive prejudice is a scientific asceticism,
in order to start trouble, posing as a scientist and refusing to be a
decent human being although at best you are a techie. You then call
him a queen when he acts like a man because you can neither expose nor
defend yourself.

 

[spinoza1111]

[...]

I can say that in 30 years programming in C I never saw a machine
without a hardware stack or a dedicated register for that purpose.

Nor have I, but my experience is not universal.  Well, actually I
probably have seen such machines, but I've never interacted with them
closely enough for the issue to come up.

We have discussed this stuff to death and regulars never came
with an example of a relevant architecture.

Concrete examples have been posted several times.

Some IBM mainframe implementations, as I understand it, do not
use a contiguous stack; instead, the activation record for each
function call is allocated from something like a heap, and the
"stack" is actually a linked list of activation records, with no
necessary relationship among their memory locations.

This is true today, but in the early years of IBM's mainframe
operating systems OS/360 (along with a horrorshow called DOS/360 where
DOS stood for Disk Operating System, a disaster called TOS or Tape
Operating System, and a degringolade called TSO for Time Sharing
Option called by its own programmers Time Squandering Option), the BAL
(Basic Assembler Language) was himself or herself expected to allocate
space to save registers.

A lot of money was made by unprincipled and in Chicago, mobbed-up
computer "consultants" owing to IBM's corporate failure to understand
stacks until 1974.

These systems are still in production use.

There must be a "stack" in the sense of a LIFO data structure;
this is necessary to support recursion.  There needn't be something
commonly referred to as "*the* stack", a contiguous region of memory
with a specific direction of growth.

You understand this well enough.

This has been mentioned here multiple times.  (Perhaps you didn't
believe it because of who mentioned it.)

....but you remain a jerk of the first water.

And even if all existing architectures used a classic hardware
stack, the fact remains that the C language doesn't require this,
and it's entirely possible (and IMHO clearer) to discuss C without
referring to "the stack".  And it would still be possible for some
future conforming C implementation to use something other than a
classic hardware stack.

C OF THE FUTURE

"Golly, Professor Thompson, how did you develop a C compiler undt
seinem runtime without a runtime stack?"

"It was easy, Johnny, for I have a Master's Degree! In Science! And
with my stackless C compiler undt seinem runtime I shall RULE ZEE
VORLD! [cue evil laugh]"


You are wrong for the same reason IBM messed up the 1620 in Dijkstra's
paper at http://www.cs.utexas.edu/~EWD/transcriptions/EWD00xx/EWD37.html.
Subroutine call and return CANNOT be implemented without a stack where
a stack is a set (bounded or not, hopefully the latter) because
subroutine call and return IS a lifo process all the way down to the
bare metal.

Stop trolling Navia.

 

[spinoza1111]

spinoza1111wrote:

It might have been obvious in 1975 but quite a few processors
in the embedded systems world now only have subroutine return
stacks or no stacks at all. In 1975 the overhead for stack operations
was not as well understood as it now is. For most applications
compile time stack management is a much more efficient use
of RAM and code space.\

\
You still must emulate the stack in code. If the caller provides the
callee with a save area, the actions of the callers and callees form a
virtual stack which is also a real stack, since inside a computer,
everything is "virtual". The failure or decision to provide a stack in
hardware had to be addressed in the runtime. This is because you
cannot decide, except for a limited subset of programs (starting with
programs that don't call subroutines) how many levels of subroutine
call need to be anticipated: this is a consequence of the Halting
problem.

 

[spinoza1111]

I use the term deliberately since in my experience computer thugs and
computer creeps value artifacts and software too highly, and treat
PEOPLE like dirt.

 

[spinoza1111]

The Univac 1100 series of mainframes had no stack and it was most certainly
active and relevant 30 years ago.  And yes, there was a C compiler for it.
I don't usually follow these interminable discussions so I don't know what
has already been said, and don't really care all that much.

My recursive descent parser for subsetted quick basic in "Build Your
Own .Net Language and Compiler" passed the parser's state as
parameters, and did not have a stack for them. But the stack still
existed: I was in effect using the runtime stack of Visual Basic .Net.

Given the state of the art 30 years ago and the fact that Univac more
or less collapsed along with the "Seven Dwarfs" of the computer
industry in 1971, it is possible that the runtime of the compiler
allocated a large fixed array...but then treated this as a stack. It
may have limited the allowed depth of subroutine calls. But as such it
screwed up, rather than proving that you don't need a stack to do C,
or that Herb was wrong.